Många gånger ute på uppdrag ser jag alla tappra försök att dokumentera krav som exempelvis listningar i Excel. Den stora utmaningen i kravarbetet är att förstå och kommunicera ett komplext sammanhang så enkelt som möjligt. Så att alla berörda i projektet (eller mellan flera projekt) får någorlunda likadan bild om behoven och vad som ska göras. Därför gillar jag att jobba med användningsfall, eller use cases som de också kallas.
De flesta människor börjar med att först förstå ett koncept på en övergripande nivå, och därefter dyka djupare ner i alla detaljer.
Låt säga att det är ett företag som ska utveckla en resebokningstjänst. Det är inte ovanligt att dessa listningar av krav görs på mer eller mindre detaljerad nivå och samtidigt förutsätts du och alla andra att förstå sammanhanget. Se exemplet nedan:
För egen del har jag haft stor nytta av användningsfall, genom att rita processflöden och beskriva dem som olika scenarios. På så sätt får jag sammanhanget som helhet, vem som gör något och i vilken ordning någon gör något.
Det kan vara kunden som bokar något, administratören som tar emot bokningen, men också bokningssystemet självt som gör något. Nu tänkte jag inte gå in på detta i detalj här, men jag ger gärna tips på bra kurser för att lära sig jobba med användningsfall.
Se följande exempel på användningsfall:
Lite lättare att få en snabb översikt på vad det handlar om med detta visualiserade diagram, eller hur? Om du dessutom ritar processflöden och kopplar korta beskrivningar av varje steg i processen, så blir det väldigt tydligt. Dessa kan du göra mer detaljerade sedan.
Det viktiga är att dela användningsfallen med olika personer för att få feedback, oavsett de är med i projektet eller inte. Utmärkt att dela det med utvecklare, testare, lösningsarkitekter, systemspecialister etc. När du kommit en bit framåt i arbetet går det faktiskt också att presentera användningsfallen till en kund med en designskiss eller prototyp för att samla in feedback.
Dessutom är användningsfallen en utmärkt grund för att ta fram testfall och användningsinstruktioner. Har du dessutom tagit fram dem med hjälp av testare och teknikinformatör, så är delar av jobbet redan gjort och informationen kan återanvändas.
Ställ dessa frågor när du tar fram krav
Följande frågor tycker jag är relevanta att ställa till sig själv för att skaffa en uppfattning om den sammanhängande ”kravbilden”:
- Är kravet formulerat som ett behov eller design? Tro mig, det är väldigt vanligt att personer blandar ihop behov och designlösning och kallar allt för krav.
- Är behovet gemensamt för flera produkter/tjänster eller specifikt för en viss produkt/tjänst? Gemensamma behov är ofta generiska krav som formar ramverket med regler och hamnar på en högre nivå än de specifika för en viss produkt/tjänst. Designlösningen av produkten/tjänsten ska alltså uppfylla de generiska kraven.
- Från vem kommer kravet? Kanske har enskild kund mejlat sin feedback, eller säljavdelningen som fångat upp ett behov i dialog med sina kunder, eller en ny lagstiftning som ska implementeras i verksamheten.
- Hur ska kravet kommuniceras? En del krav gäller förvisso utveckling av produkter/tjänster och ska kommuniceras till kunder och användare vid lansering. Medan en del andra krav gäller t ex designprinciper och guidelines som är viktiga internt i organisationen under själva utvecklingen av produkten/tjänsten.
Generiska krav passar utmärkt i en kunskapsbank. Läs gärna ett av mina tidigare blogginlägg:
> Återanvänd kraven
Eftersom det finns så mycket mer i detta ämne, har jag publicerat en serie artiklar som belyser generiska krav från olika perspektiv.
> Återanvänd krav del 1 – Bygg kunskapsbank och style guides – 9 tips
> Återanvänd krav del 2 – Håll ordning på kraven i kunskapsbanken
> Återanvänd krav del 3 – Bygg och kommunicera informationsmodell
Författare: Helén Alseby, agil produktägare samt krav- och verksamhetsanalytiker
Tyckte du om denna artikel? Dela gärna! > Läs fler artiklar
Vill du ställa en fråga eller tipsa om något du vill läsa om? > Välkommen att höra av dig