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!