Morotsmaskinen

Publicerad den 2024-03-03
Patrik Hallén


Morotsmaskinen Ă€r en tankemodell som anvĂ€nds för att pĂ„ ett enkelt men kraftfullt sĂ€tt beskriva grunderna i effektiv kravstĂ€llning. För att lĂ€sa mer om bakgrunden till morotsmaskinen, lĂ€s gĂ€rna "Morotsmaskinen - ett mĂ„ste för alla typer av verksamhet".

Ett vanligt misstag i kravstĂ€llning som sker i samband med verksamhetsutveckling Ă€r att kravstĂ€llningen utgĂ„r frĂ„n en lösning istĂ€llet för att beskriva behovet. Artikeln "FramgĂ„ngsrikt kravarbete i fem punkter" ger ett bra exempel pĂ„ hur man i samband med definiering av krav pekar pĂ„ en lösning istĂ€llet för pĂ„ problemet.  

Ett vanligt annat misstag Ă€r att "fastna i nulĂ€get". I detta fall blir kraven alltför specifika dĂ„ de bygger pĂ„ hur arbetet sker i nulĂ€get. KravstĂ€llningen riskerar att baseras pĂ„ processen, och för att undvika detta problem bör fokus riktas mot funktionen. 



Som framgÄr av bilden ovan handlar processer om att beskriva hur verksamheten bedrivs utifrÄn olika perspektiv:

  • VAD Ă€r det som görs?
  • VEM Ă€r det som gör det?
  • HUR görs det? (i vilken ordning och med vilken metod)
  • NÄR görs det?
  • VAR görs det?
  • VILKET verktyg anvĂ€nds?

Verksamhetsfunktionen (F32), som tillhör förmĂ„gedimensionen, Ă€r en enklare konstruktion som fokuserar pĂ„ VAD. Den definieras i Prime Arch som en "gruppering av logiskt relaterade uppgifter som krĂ€vs för att producera ett resultat".

Genom att utgÄ frÄn verksamhetsfunktionen ska tre frÄgor besvaras:

  • VAD Ă€r det som ska produceras?
  • VAD behöver vi kunna göra för att producera resultatet?
  • VAD Ă€r det för input som krĂ€vs?

I exemplet med morotsmaskinen sÄ kan frÄgestÀllningen formuleras sÄ hÀr:


VAD Àr det vi behöver kunna göra för att förvandla en morot till en morotstallrik.

I Prime Arch anvÀnds ett förmÄgeflöde för att beskriva denna kravstÀllning i en enkel men kraftfull modell:



Input i form av morot och output i form av morotstallrik representeras av informationsobjektet (I31) och morotsmaskinen representeras av verksamhetsfunktionen (F32) samt fyra stycken funktionsförmÄgor (F41) som kan ses som de knappar man behöver kunna trycka pÄ för att förvandla moroten till en morotstallrik.

VĂ€rt att notera Ă€r valet av metaobjekt: Morot och morotstallrik Ă€r ju verkliga ting och borde dĂ€rmed kunna representeras av verksamhetsobjekt (I32) men det förutsĂ€tter att sjĂ€lva maskinen beskrivs som en process (P31) vilket var just det som skulle undvikas. Genom valet av information och funktion/förmĂ„ga fokuserar vi pĂ„ det som ofta Ă€r viktigare i verksamhetsutveckling, nĂ€mligen att kunna besvara frĂ„gan "vilken information och funktionalitet behövs". För en fördjupad analys pĂ„ detta tema, lĂ€s artikeln: "Verksamhetsobjekt, Informationsobjekt och Dataobjekt".

SÄ vad Àr det dÄ som behöver kunna göras för att förvandla en morot till en morotstallrik?

  • Skala morot
  • Skölja morot
  • SkĂ€ra morot
  • LĂ€gga upp pĂ„ tallrik

Dessa fyra funktionsförmĂ„gor utgör grunden för den funktionella kravstĂ€llningen. Vid en första anblick Ă€r det lĂ€tt att uppfatta dessa som processer dĂ„ de innehĂ„ller aktiva verb och substantiv. Men processer handlar om att göra nĂ„got, medan funktionen istĂ€llet handlar om möjligheten att göra nĂ„got. 



I modellen ovan Àr "knapparna" (funktionsförmÄgorna) placerade i ett 2x2-mönster. Förutom att det ger en geometriskt mer proportionelig form har detta mönster en viktig fördel: det finns ingen uppenbar ordningsföljd frÄn vÀnster till höger eller uppifrÄn och ner.

FrÄn ett processperspektiv inses lÀtt att det Àr smartare att skala moroten innan den skÀrs upp, men ur ett funktionellt perspektiv Àr det mindre intressant och rentav oönskat att alltför tidigt hamna i frÄgor som "HUR" (i vilken ordning) saker bör ske. Fokusera pÄ VAD som ska kunna göras.

Mönstret med 2x2-knappar minskar Ă€ven risken att bli alltför detaljerad. Genom att börja bakifrĂ„n, att producera morotstallriken, blir det tydligt att nĂ„gon form av funktion för att "lĂ€gga upp pĂ„ tallrik" behövs. Genom att studera innehĂ„llet pĂ„ tallriken ser man att moroten Ă€r skuren och det Ă€r rimligt att anta att den Ă€ven Ă€r sköljd och skalad.



NĂ€r nu funktionsförmĂ„gor samt input och output identifierats Ă€r det dags att verifiera att maskinen kommer att fungera (Ă„tminstone i teorin).

Morötter stoppas in i maskinen och knapparna "Skala", "SkĂ€ra" och "Skölja" trycks pĂ„ i lĂ€mplig ordning. SĂ„ lĂ„ngt fungerar det. Men nĂ€r vi ska trycka pĂ„ knappen "LĂ€gga upp pĂ„ tallrik" tar det stopp. I flödet ingĂ„r inte tallrik som input, och modellen mĂ„ste dĂ€rmed kompletteras: 



Nu fungerar flödet i teorin. Nu har vi formulerat den övergripande kravstÀllningen pÄ information och funktionalitet. DÀrefter kan arbetet med att detaljera kraven pÄbörjas. En lÀmplig inledning pÄ detta kan vara att lÀsa artikeln "Den röda knappen".

Slutligen ÄterstÄr att utforma en lÀmplig lösning i form av processer, applikation och data; men det Àr en helt annan sak!