Kravindsamling som mindmap: gratis skabelon til analytikere

Kravindsamling som mindmap: gratis skabelon til analytikere

The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

Sådan læser du mindmappet

• Begynd med »Interessenter« og »Forretningsbehov« for at se, hvem der er involveret, og hvorfor. »Brugerbehov« beskriver behovet set fra brugerens side, og »Funktionelle krav« og »Ikke-funktionelle krav« omsætter det til, hvad systemet skal kunne, og hvor godt.
• De stiplede pile følger ræsonnementet. For eksempel begrundes en funktion under »Prioritet« af succesmålet i »Ønsket resultat«, og et sikkerhedsbehov i »Sikkerhed og privatliv« kan støde sammen med en teknisk begrænsning i »Tekniske begrænsninger«.

Interessenter

»Interessenter« åbner kortet, fordi ethvert krav har en person bag sig. List under »Sponsorer«, hvem der betaler, under »Slutbrugere«, hvem der skal bruge resultatet, og under »Godkendere og støtte«, hvem der skal godkende eller bakke det op.

Interview alle i »Slutbrugere«, ikke kun deres leder. En hyppig fejl er at skrive krav ud fra sponsorens beskrivelse af arbejde, vedkommende ikke længere udfører.

Forretningsbehov

»Forretningsbehov« forklarer, hvorfor projektet findes. »Problem, der skal løses« er problemet eller muligheden, »Ønsket resultat« det resultat, der tæller som succes, og »Succesmål« det mål, der dokumenterer det.

Ethvert krav andre steder på kortet bør kunne føres tilbage til noget her. Kan et ikke, så spørg, hvilket behov det tjener, eller fjern det.

Brugerbehov

»Brugerbehov« noterer, hvad folk har brug for at få gjort. Skriv »Opgaver, der skal udføres« som opgaver set fra brugerens side, og saml smertepunkterne ved nutidens arbejdsgang under »Nuværende smertepunkter«.

»Brugssituation« rummer den situation, brugerne arbejder i, fx på en telefon, på støjende steder eller under tidspres. Sådanne detaljer afgør ofte designet mere end selve opgaverne.

Funktionelle krav

»Funktionelle krav« lister, hvad systemet skal kunne. »Kernefunktioner« er hovedfunktionerne, »Forretningsregler« er de regler, det skal anvende, og »Grænseflader« er grænsefladerne til andre systemer eller teams.

Formuler hvert krav, så det kan testes, fx: systemet sender en bekræftelse inden for et minut. Brug »Testbart udsagn« som model for, hvordan detaljen formuleres.

Ikke-funktionelle krav

»Ikke-funktionelle krav« dækker, hvor godt systemet skal fungere. »Ydeevne« fastsætter hastighed og kapacitet, »Sikkerhed og privatliv« dækker sikkerhed og privatliv, og »Brugervenlighed og adgang« dækker brugervenlighed og tilgængelighed.

Det er de krav, folk glemmer at spørge til og så skændes om efter lanceringen. Giv hvert krav et tal eller en standard, hvor det er muligt.

Begrænsninger

»Begrænsninger« lister de grænser, løsningen ikke kan overskride. »Budget og tid« er budget og tid, »Tekniske begrænsninger« er tekniske begrænsninger som eksisterende systemer, og »Jura og politikker« er juridiske eller politikmæssige forpligtelser.

Kontroller tidligt hvert krav mod »Tekniske begrænsninger«. Et krav i konflikt med en hård begrænsning er en beslutning for sponsoren, ikke en opgave for teamet.

Sådan hænger grenene sammen

Behov flyder nedad. »Forretningsbehov« giver begrundelsen, »Brugerbehov« giver brugerens perspektiv, og »Funktionelle krav« og »Ikke-funktionelle krav« er de krav, der udledes af dem. Et krav uden kilde i de første tre grene er en kandidat til at blive fjernet.

»Begrænsninger« skubber tilbage opad. En begrænsning kan gøre et behov uoverkommeligt, hvilket sender dig tilbage til »Forretningsbehov« for at spørge, om et mindre resultat er acceptabelt, og til »Interessenter« for at blive enige om det.

Hvor et mindmap stopper, og andre diagrammer tager over

Brug mindmappet til at indsamle og organisere. Skal du beskrive, hvordan arbejdet flyder i dag, og hvordan det bør flyde, så tegn et procesdiagram eller flowchart, og brug et swimlane-diagram, når krav afhænger af overdragelser mellem teams.

Et organisationsdiagram kan dokumentere interessenter og godkendelsesstruktur, og et Gantt-diagram tager over, når kravene bliver til en planlagt levering.

Key relationships and takeaways

• Ethvert krav bør kunne føres tilbage til et forretningsbehov og en interessent.
• Brugerbehov skrives som opgaver, og funktionelle krav som testbar adfærd.
• Ikke-funktionelle krav er dem, der oftest mangler i tidlige udkast.
• Begrænsninger afgøres af mennesker, så de optræder også under interessenter.
• Et krav uden prioritet bliver behandlet som lige så hastende som alle de andre.

When to use this visual

• Forberedelse til interview med interessenter og registrering af svarene på et fælles kort.
• Gennemgang af et udkast til kravdokument for manglende kategorier før godkendelse.
• Afgrænsning af et lille internt værktøj, hvor en fuld specifikation ville være mere end nødvendigt.

Sådan fungerer det

1. Identificér personerne

   Omdøb »Projektets krav«, og list interessenter under »Interessenter«, og markér dem, du endnu ikke har talt med. Interview, før du udfylder de andre grene.

2. Notér behov, som du hører dem

   Skriv begrundelser under »Forretningsbehov«, brugeropgaver under »Brugerbehov« og systemadfærd under »Funktionelle krav«. Notér kilden i hver node, så du kan gå tilbage og kontrollere.

3. Kontrollér grænser og konflikter

   Sammenlign hvert krav med »Ikke-funktionelle krav« og »Begrænsninger«, tegn forbindelser, hvor de er i konflikt, og tag de åbne konflikter med til de interessenter, der er listet i »Interessenter«.

Ofte stillede spørgsmål

Hvad er forskellen på funktionelle og ikke-funktionelle krav?

Funktionelle krav siger, hvad systemet gør, fx at oprette en faktura eller sende en alarm. Ikke-funktionelle krav siger, hvor godt det skal gøre det: hastighed, sikkerhed, tilgængelighed. Begge dele er nødvendige, og de ikke-funktionelle opdages som regel sent, medmindre du spørger direkte til dem.

Hvorfor begynde med interessenter frem for funktioner?

Fordi ethvert krav har en ejer, der kan forklare det og om nødvendigt ændre det. Begynder du med funktioner, får du en liste, ingen kan forsvare eller prioritere. Begynder du med mennesker, ved du, hvem du skal interviewe, og hvem der skal blive enige, når to krav støder sammen.

Hvor detaljerede bør krav på et mindmap være?

Detaljerede nok til at kunne genkendes og diskuteres, korte nok til at kunne overskues. Brug idéen til et kort udsagn og noten til kilden eller testbetingelsen. Når en gren bliver overfyldt, så flyt den over i en kravspecifikation eller et backlog af user stories.

Kan interessenter gennemgå kortet direkte?

Ja. Del diagrammet med reviewere, lad dem kommentere bestemte krav, og brug versionshistorikken til at bevare en oversigt over, hvad der ændrede sig mellem gennemgangsrunderne. Det gør godkendelsen mere pålidelig end at sende dokumenter frem og tilbage på mail.

Start fra dette kravkort

Åbn skabelonen som dit eget lærred, navngiv projektet, og begynd med at liste de interessenter, du skal tale med.

Start fra dette kravkort