Ställ lådan på bordet - prata om förmågor och egenskaper vid kravställning!

Efter snart 25 år inom kravingenjörsskap och verksamhetsanalys så har jag samlat på mig ett antal favorituttryck som funkar í de flesta situationer. Ett av dem är "draw the f…g map!", men idag kommer jag utveckla uttrycket "ställ lådan på bordet"

Att ställa lådan på bordet innebär att man tvingas hålla alla påståenden om egenskaper, funktioner och begränsningar till det man ser på bordet och inte vad som finns inuti lådan om man lyfter på locket. Detta sättet att tänka kallas ofta för Black box thinking. 
Vi pratar om vad lådan kan erbjuda i den existerande kontexten. Vilka andra lådor och mänskliga aktörer som kan interagera med den. Man uttrycker det som att lådan har ett antal förmågor eller capabilities.

Tankemodellen att ställa lådan på bordet kan användas i alla kontexter och för alla typer av krav. Du kan inte skriva ett bra formulerat krav utan att ha lagt något på bordet. Antingen ett konkret fysiskt systemelement eller något abstrakt som ett koncept eller en mjukvarukomponent. Det spelar därför ingen roll om vi pratar om ett hårdvarublock, en mjukvarukomponent, en mekanisk del, ett arkitekturelement, en abstrakt feature, epic eller liknande planeringsobjekt.

Tankemodellen fungerar oavsett vilken abstraktionsnivå man befinner sig på! Styrkan i tankemodellen är att man använder samma tänk på alla abstraktionslager och i olika kontext. Det ger dig nödvändig kunskap för att få en övergripande förståelse på respektive nivå och för respektive låda.

Ett krav ska alltid ha en tydligt utpekad subjekt nod

För att kunna gör ett påstående överhuvudtaget så måste man givetvis vara en intressent i den aktuella situationen. Så låt oss anta att vi har rätten att ha på oss hatten för ett specifikt område som är viktigt för det givna projektet, eller den mängd features som ska utvecklas. Om vi vill påstå något som påverkar hur projektet tänker och agerar så måste vi vara en riktig och viktig intressent. Vi måste också veta exakt vad själva påståendet syftar till med avseende kring vilken låda vi pratar om. Inom modelleringspråket SysML kallas lådan för subjektnod (Subject node).

Ett krav ska alltid ha en tydligt utpekad subjekt nod oavsett på vilken abstraktionsnivå man befinner sig. Att skriva "Systemet skall..." är extremt farligt! Eftersom man inte tydligt namnger subjektnoden.

Och som William Blake skrev:
To generalize is to be an idiot*

Det är i princip lika dumt som att skriva "Användaren skall..." utan att veta vilka olika typer av användare som finns och vilka behörighetsnivåer som de delas in i. 

Funktionella förmågor (Functional Capabilites)

Det är oftast lätt att prata om och identifiera funktionella förmågor. Det är dessa förmågor som man försökte fånga genom att rita ett användarfallsdiagram. I ett användarfallsdiagram visualiseras aktörer och deras inbördes beroenden och i vissa fall även externa intressenter som inte har direkt kontakt med subjektnoden. I användarfallsdiagrammet synliggör man funktioner som ellipser i subjektnoden och kopplar ihop dem med aktörer via så kallade kommunikationsassociationer (Communication path).

Det finns dock flera begränsningar med det klassiska use case-diagrammet. Man visar exempelvis inte portarna till subjektnoden och inte heller egenskaperna på subjekt noden som helhet. Det innebär att det var lätt att fastna i funktionsnedbrytning genom att använd så kallade includes och extends och lurades till att tänka "inuti lådan".

Egenskaper (Property capabilities)

Det finns egenskaper som inte handlar om hur bra en specifik funktion ska vara utan snarare slår på subjektnoden som helhet. Dessa kan vi kalla för egenskaps-förmågor.

I ett capability-diagram vill vi tydligt visa dessa. Och när vi ställer lådan på bordet kan vi ställa frågorna:

  • vad har lådan för egenskaper
  • vilken färg har den
  • hur tung är den
  • är den vattentät
  • hur snabbt kan man ersätta den med en ny
  • hur länge är det tänkt att den ska hålla…

Alla dessa egenskaper "ägs av lådan" och det som gör att vi antingen gillar lådan eller tycker den är dålig, utan att ha öppnat locket och kollat på vilka delar den består av och hur den har realiserats.

Gränssnitten (Port capabilities)

När kommunikationsassociationen korsar subjektnodens yttre gräns så indikerar man behovet av ett interface/port men gör inte detta tydligt i användarfallsdiagrammet. Faktum är att lådan på bordet måste ha tydliga knappar, spakar och skärmar så att en aktör kan interagera med den för att få nytta av de funktionella förmågorna som erbjuds.

Lådan har ju oftast flera ut-portar för att kunna presentera resultatet av funktionerna. Det kan vara mekaniska system, exempelvis ett auditivt eller visuellt larm, eller information som uppdaterats på en skärm. Skärmen är då porten ut ur lådan. På lägre abstraktionsnivåer pratar man med lådan genom både mjuka och hårda gränssnitt och aktörerna är sällan mänskliga. Men capability-tänket är fortfarande användbart och skapar tydlighet och får alla involverade att förstå vad man pratar om.

Frågorna blir nästan desamma:

  • vad kan du som mjukvarukomponent?
  • vad har du för egenskaper?
  • hur kan jag prata med dig?
  • hur pratar du med andra?

SysML har ett extremt utvecklat formellt språk för att tydligt beskriva portar och interface och hur kommunikationen ser ut. I capability-diagrammet använder vi oss av så kallade aktivets portar (action pin/activity parameter) och en tydlig markering på om det är ett inflöde eller utgående flöde vi pratar om. Det visuella språket används för att ange vilket typ av meddelande man skickar in utan att veta exakt vad det heter eftersom det bestäms i lägre abstraktionslager. Vad man kallar porten för, exempelvis en dip switch eller ett HMI, och om flödesriktningen är {in}, {out} eller {in/out}.

Sammanfattning

Vi måste tydligt beskriva vilka funktioner/features som subjektnoden erbjuder sin omgivning, vilka aktörer som kan interagera med den, vilka knappar, spakar och skärmar som finns tillgängliga för att prata med lådan och vilka skärmar, högtalare eller lampor som förmedlar den processade informationen ut ur lådan. Lådan har också specifika egenskaper som gör den attraktiv för de intressenter som agerar direkt med lådan eller de som har indirekt nytta av lådan.

Notera att capability-diagrammet kan ritas på alla abstraktionsnivåer. Låt oss avsluta med ett enkelt exempel som jag hoppas är mer eller mindre självförklarande 😉

Alarm clock - system capability diagram

Rita mer, rita smart och "ställ lådan på bordet"

Nästa gång kommer vi titta mer på abstraktionsnivåer och hur namnet på subjektnoden är helt avgörande för professionell kravskrivning (och kravmodellering).

*William Blake (28 november 1757 – 12 augusti 1827) var en engelsk målare, poet och grafiker. I stort sett okänd under sin livstid anses Blake nu vara en säregen figur i historien om poesi och bildkonst under den romantiska tidsåldern.

Alla blogginlägg

Vi rekommenderar också