Illustrera kravleverablerna i kravpyramiden

Kravanalytiker strävar ständigt efter att skilja behov från lösningar. Syftet är att inte låsa sig till en felaktig specifik lösning innan behovet bakom har tydliggjorts. En klassisk, enkel och användbar konceptuell modell för att beskriva hur krav hör hemma på olika abstraktionsnivåer kallas för kravpyramiden.

Den traditionella kravpyramiden

Kravpyramiden används traditionellt för att strukturera sin kravmängd genom att skapa en hierarkisk trädstruktur. På så vis kan man identifiera saknade eller överflödiga krav på en viss nivå. I 2-dimensionell form ser den klassiskt ut så här:

Längst upp har vi intressentönskemålen. Detta är egentligen aldrig riktiga krav. Många av dem kommer att uttryckas av intressenterna som krav men i sin ursprungliga form är de inte det. De bevaras på den här nivån för att dess ursprung (källa) och sammanhang ska kunna härledas.

Krav blir det först när analysen kommer fram till att det ska formuleras som ett eller flera kundkrav (kund hänvisar till mottagaren för systemet, vem det vara månde). Kundkraven bryts sedan ner i systemkrav vilket i sin tur kan, men inte måste bli, designkrav i olika former.

Analogin med pyramiden kan härledas till att varje önskemål högt upp i pyramiden ger upphov till flera krav på nivån nedanför som i sin tur leder till en nedbrytning i ännu fler krav på lägre nivå.

Med hjälp av spårbarheten till krav på högre och lägre nivåer kan man underlätta prioritering, ändringshantering och planering. Modellen är endast konceptuell och den har naturligtvis vissa begränsningar. Det finns risk för att man överdriver dess användning och hamnar i fel typer av diskussioner. Dessutom är det inte alltid meningsfullt att koppla ihop alla unika krav med varandra. Hur långt man vill applicera modellen är upp till varje organisation. Det är trots allt bara ett konceptuellt hjälpmedel.

Ett annat användningsområde

Själv använder jag den oftast för att identifiera och illustrera vilka kravartefakter (modeller, dokument, etc.) som ska eller har producerats inom ett projekt eller en verksamhet. Modellen som jag använder ser då typiskt ut så här:

Till höger betonas att en mycket stor del av kraven är lösningsorienterade och att ju längre ner vi kommer i kravpyramiden desto närmare har vi definierat lösningen. Spårbarhet mellan nivåerna ska helst framgå på något sätt i artefakterna och hur det görs beror på kravstilarna som används och vilka kravhanteringsverktyg som finns att tillgå. Finns det inga artefakter på högsta nivån så kan det innebära ett problem. Men det beror naturligtvis på organisationen.

Ett exempel

Om jag i ett projekt använder processmodellering, informationsmodellering och systemanvändningsfall kan jag placera in dessa för att illustrera hur de förhåller sig till varandra:

Det saknas kanske något

Att det inte finns kravartefakter på en viss nivå måste inte innebära ett problem men nog kan det indikera att det kanske saknas något? Vi lägger till ”Övergripande krav” som samlar just övergripande funktionella krav och kvalitetskrav som inte hör hemma i de detaljerade systemanvändningsfallen. Det visar sig att vi också ska göra en intressentmodell och en effektmålsanalys. De kommer kanske inte att ligga i egna dokument men det är artefakter så vi stoppar in dem också!

Djupare ner i lösningen

Kravanlytikerns arbete kan ibland gå ganska djupt och omfatta visst designarbete. Användargränssnitt kan till exempel illustreras i dialogflöden. Någon kanske säger att det ska tas fram en datamodell och vi kan stoppa in den också för att visa att den hör hemma långt ner i lösningen och kanske inte ens är en kravartefakt. Vi spårar den över flera nivåer ända upp till informationsmodellen.

Kravpyramiden erbjuder ett enkelt och tydligt sätt att kommunicera relationen mellan kravartefakter och mellan kravartefakter och andra artefakter i utvecklingsarbetet. Med stöd av bilden kan man ställa frågor som ”Hur påverkar en ändring i informationsmodellen andra artefakter och hur kommuniceras det?” och ”Hur upprätthålls konsistens mellan informationsmodell och datamodell – om alls?”.

Kravpyramiden kan också fungera som diskussionsunderlag för hur var och en förhåller sig till och förstår artefakterna. Just gränsdragningen mellan lösning och behov/problem kan ge upphov till många nyttiga diskussioner. Systemanvändningsfallen beskriver lösningen på en detaljerad nivå. Kanske finns det behov att arbeta på en något högre nivå?

Kravpyramiden är i det här fallet endast är ett verktyg för att identifiera och illustrera kravartefakterna och hur de förhåller sig till varandra. Du kan naturligtvis själv forma om den för att passa dina behov!