Innsamling av krav: Komplett veiledning & mal
Innsamling av krav er en prosess som lar deg fastsette og håndtere forventninger med interessenter, forhindre at prosjektets omfang gradvis utvides, og redusere uklarhet rundt hva prosjektet faktisk leverer.
Jo mer kravdokumentasjon du har, desto mindre rom er det for feil og antakelser. Kontrollene og avveiningene vil gi teamet en bedre felles forståelse av prosjektet og kundens forventninger til sluttproduktet.
Hva er innsamling av krav i prosjektstyring?
Innsamling av krav er prosessen med å fastslå hva prosjekteierne og de viktigste interessentene trenger fra prosjektet. Prosjektledere arbeider med å identifisere hva som etterspørres, og detaljene rundt forespørselen.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Disse forespørslene blir til prosjektets kravliste. Leveransen opp mot kravene avgjør om arbeidet regnes som et vellykket prosjekt eller ikke.
Prosjektledere bruker kravdokumenter og verktøy for kravhåndtering for å holde oversikt over disse kravtypene gjennom hele prosjektet:
- Funksjonelle krav
- Tekniske krav
- Ikke-funksjonelle krav
- Systemkrav
Hvorfor er innsamling av krav viktig?
Innsamling av krav er viktig av følgende grunner (det samme gjelder dokumentasjon av kravene):
- Det fungerer som et referansepunkt for å dokumentere utviklingen av et prosjekt, dets bevegelige deler og implementering
- Det fungerer som en plan for prosjektets interessenter, slik at de bedre kan forstå hva de kan forvente av prosjektet (hva, hvor, når og hvorfor prosjektet gjennomføres).
- Det reduserer rommet for feil og uklarhet, fordi kravene er tydelig dokumentert og avtalt før arbeidet starter.
- Det gir kontroller og avveininger gjennom hele prosjektgjennomføringen og kvalitetssikringen, slik at prosjektlederne og teammedlemmene kan se tilbake på det når det oppstår tvil om hvordan de skal gå videre.
I tillegg til å beskrive hva de kan forvente, bør effektiv planlegging av kravhåndtering beskrive hva de ikke kan forvente. Det er klokt å inkludere en del om «Antakelser» og/eller «Unntak» for å eliminere risikoen for den fryktede kundefantasien.
Et eksempel på en kravspesifikasjon for programvare
Her er et eksempel på en kravspesifikasjon for et netthandelsprosjekt:
- Hva: PayPal-integrasjon
- Hvor: Kassen
- Når: I trinn 3 av 4 i kasseprosessen (etter nettskjemaet for leveringsadresse, før bekreftelsen)
- Hvorfor: En etablert integrasjon (f.eks. PayPal) er i dette tilfellet en bedre løsning enn en omfattende spesialutviklet integrasjon for en betalingstjeneste, fordi den enkelt oppfyller virksomhetens krav.
- Antakelser
- Fast pris for all frakt og håndtering
- All frakt skjer innenfor USA (unntatt Alaska og Hawaii)
- Avgifter gjelder ikke
- Unntak
- Spesialberegninger av frakt- og håndteringskostnader
- Frakt internasjonalt, til Alaska eller til Hawaii
- Avgiftsregler
Husk: Jo mindre avstanden mellom kundens forventninger og virkeligheten med det digitale produktet deres er, desto mer fornøyd kommer kunden til å være med sluttresultatet. Kvaliteten på kravhåndteringen din samsvarer direkte med evnen din som prosjektleder til å redusere alle gråsoner når det gjelder kundens forventninger.
Som oftest vil en kunde være mottakelig for at du begrenser omfangsutvidelser hvis det betyr at du beskytter budsjettet deres. Hvis du gir kunden tilstrekkelig informasjon om hvorfor en funksjon vil bli håndtert (eller ikke håndtert), og deretter dokumenterer begrunnelsen for denne tilnærmingen i kravene, er det langt mer sannsynlig at kunden vil samarbeide.
Det er mer sannsynlig at de godkjenner løsningen, og senere, når de gjennomfører brukergodkjenningstesting (UAT), vil de ha et bedre utgangspunkt for å forstå «hvorfor» bak teamets løsning.
Prosess for innsamling av krav i 6 trinn
Selv om innsamling av krav bør starte så snart et oppdrag begynner, og fortsette gjennom hele prosjektets livssyklus, er det aldri for tidlig å begynne å samle inn og dokumentere krav. Faktisk burde du ha begynt i går.
Her er trinnene for hvordan du samler inn krav.
1. Ta notater
På hvert møte du deltar i – enten det er internt med prosjektteamet ditt eller eksternt med kunden – bør du alltid ta notater. Gå aldri ut fra at noen andre gjør det.
Der og da kan det være lett å anta at alt som diskuteres, vil bli husket, men tre måneder og 15 møter senere vil både teamet ditt og kunden takke deg for at du har en oversikt over diskusjonene å se tilbake på.
Se noen av mine anbefalte fremgangsmåter for å ta notater om krav her:
- Før møtet bør du klargjøre notatdokumentet slik at det gjenspeiler agendaen din. Da blir det enklere å organisere handlingspunkter og andre punkter. På denne måten husker du hva som trengs, samtidig som du fanger opp relatert informasjon på en organisert måte.
- Etter hvert møte bør du sette av 15–30 minutter til å gå gjennom notatene dine, bearbeide det som ble diskutert, prioritere handlingspunktene og identifisere utfordringer/varselsignaler eller behov for avklaringer eller flere møter.
- Send notatene til det interne prosjektteamet ditt. Be dem gå gjennom og bekrefte det du har identifisert som handlingspunkter, varselsignaler osv.
- Når teamet har gitt deg sin godkjenning, sender du notatene til kunden.
- Til slutt bør du bruke notatene som grunnlag for å opprette oppgaver ut fra hvert handlingspunkt. Legg til ny informasjon i kravdokumentasjonen, og planlegg eventuelle nødvendige møter for ytterligere kartlegging eller diskusjon.
2. Gå gjennom de kreative kravene
Ikke overlat beslutninger om design og stil til enkeltmedlemmer av teamet: formaliser kreative krav når det er mulig. Kreative retningslinjer er uvurderlige for utviklere. Sørg som et minimum for at du har en stilguide tilgjengelig – selv om den bare inneholder grunnleggende informasjon som skrifttyper og merkevarefarger.
Samle inn alle kreative ressurser, for eksempel merkevarelogoer eller merkefonter, og last dem opp til et felles område (for eksempel programvare for håndtering av digitale ressurser) slik at hele teamet får tilgang og oversikt.
3. Skriv kravdokumentet
Når du går i gang med dokumentasjonen, bør du huske at første forsøk på kravdokumentasjon vil være det vanskeligste. Hvorfor? Fordi du ikke har et tidligere dokument å bruke som utgangspunkt (eller rettere sagt: KOPIER OG LIM INN). Heldigvis inneholder denne artikkelen en mal for kravdokumentasjon som kan danne grunnlaget for arbeidet ditt.
Slik denne malen viser, organiserer jeg kravdokumentasjonen min i fire deler:
- Annotering: Inneholder numrene fra det annoterte designet ditt. Hvis sidedesignet ditt har 8 elementer, har du 8 annoteringer, og annoteringskolonnen din vil ha 8 rader
- Element: Inneholder elementtitler, slik de relaterer seg til hver annotering
- Funksjonelt krav: Inneholder en definisjon (kravene, spesifisert) for hvert element
- Administrasjons-/CMS-funksjonalitet: Definer eventuell administrasjons- og/eller CMS-funksjonalitet som er knyttet til det tilsvarende elementet
4. Gjennomfør en intern gjennomgang
I denne delen av prosessen for innsamling av krav bør du planlegge et nytt internt møte med prosjektteamet ditt for å gjennomgå kravdokumentasjonen. Dette er en siste intern kontroll for å sikre at dere har en felles forståelse av implementeringen.
Hvis mulig bør du la teamet gjennomgå kravdokumentasjonen før møtet, slik at de kan møte forberedt med spørsmål og/eller tilbakemeldinger. Bruk møtet til å diskutere eventuelle spørsmål eller tilbakemeldinger om kravene.
Gjør eventuelle nødvendige endringer i dokumentasjonen basert på den interne diskusjonen. Send til slutt den reviderte kravdokumentasjonen til teamet på nytt for en siste godkjenning. Når det interne prosjektteamet har gitt sin endelige godkjenning av kravdokumentasjonen, lagrer du dokumentet som PDF for å sikre at det forblir i sin ferdigstilte tilstand til neste trinn: utarbeiding av oppgaver.
5. Utarbeid oppgaver
Gi PDF-versjonen av kravdokumentasjonen til utviklingsteamet ditt. Ideelt sett vil utviklerne eller utviklingslederen din utarbeide oppgavene for leveransen.
Selv om noen organisasjoner kan ha en prosess der prosjektledere utarbeider alle oppgaver, foretrekker jeg at utviklerne utarbeider sine egne oppgaver. De få timene dette tar for dem, er verdt det.
Du kan fortsatt gi teamet nyttige retningslinjer mens de utarbeider utviklingsoppgavene og leveransene sine. Etter at oppgavene er utarbeidet, vil du kunne få et endelig timeestimat.
Sammenlign dette estimatet med prosjektplanen som tidligere er kommunisert til kunden, og håndter dette deretter hvis/når det er nødvendig. Hvis du vil vite mer om estimering av prosjekter, kan du se denne fullstendige veiledningen for prosjektestimering.
6. Gjennomfør en ekstern gjennomgang
Det er på tide å presentere kravdokumentasjonen for kunden. Lever den som PDF for å sikre at det ikke gjøres endringer. Dette (1) viser at du investerer i å sikre kundens forståelse av den digitale løsningen og (2) vil være en forsikring for deg, slik at du kan si «det sa jeg jo» (men langt mer velformulert) når ukontrollert utvidelse av prosjektomfanget uunngåelig dukker opp.
Lær opp kunden din. Gå gjennom denne verdifulle dokumentasjonen som du har satt sammen for dem med stor omhu. Husk: De er ekspertene på virksomheten sin. Du er eksperten på den digitale løsningen du tilbyr dem. De betaler deg for denne løsningen. Lær opp og styrk kunden din.
Når kunden har bekreftet at de forstår kravdokumentasjonen, er det på tide å innhente formell godkjenning. Send den signerte og godkjente kravdokumentasjonen til teamet ditt, og lagre den på et felles område ved hjelp av dokumenthåndteringsprogramvare, slik at det finnes en formell bekreftelse på at utviklingen kan begynne.
Teknikker for innsamling av krav
Her er noen teknikker som kan hjelpe deg med å sikre at du utfører det viktige arbeidet med å samle inn krav så godt som mulig:
1. Start med en gang
Kravdokumentasjonen bør begynne så snart samtalene starter, før du har fastsatt den nøyaktige prosjektplanen eller prosjektmålene. Noter alt du kan, og reduser deretter innholdet. Her er noen strategier du kan prøve med kunden:
- Send dem et spørreskjema om hva de ønsker å se i prosjektet
- Gjennomfør en idédugnad
- Gjennomfør en fokusgruppe
I stedet for å fjerne informasjon fra dokumentet bør du kategorisere den i hva som er inkludert, og hva som ikke er inkludert – dette unngår kundeantakelser senere i prosessen.
Du vil kunne hente frem WIP-kravdokumentasjonen din og påpeke hvor informasjonen ble dokumentert, hvorfor den kanskje ikke er tatt med, logikken bak beslutningen og datoen da dette ble dokumentert, slik at det kan spores.
2. Ta i bruk maler
Når du har utarbeidet noen kravdokumenter, bør du begynne å dra nytte av dem og lage maler av dem for fremtidig bruk i andre prosjekter. Særlig hvis du har et spesifikt fokus på netthandel eller prosjekter for læringsapplikasjoner, vil du begynne å se funksjonsmønstrene komme til syne. Identifiser hvor du kan gjenbruke dem.
3. Samarbeid får drømmen til å gå i oppfyllelse
Hvis det finnes ulike typer teammedlemmer i et prosjekt, kan kravene for hvert kompetanseområde utarbeides av de respektive ekspertene.
I mange tilfeller er samtalen om krav en kronglete sti av telefonsamtaler, ulike separate møter og samtaler osv. Derfor er det avgjørende at du fordeler ansvaret for kravdokumentasjonen til de respektive teammedlemmene mens du innhenter og sammenstiller kravene.
4. Ikke bare dokumenter kravene – lær
Gjør mer enn å ta notater. Forvent mer enn at ressurspersoner sender deg en vegg av tekst som utgjør deres del av kravene. Ta deg tid til å sette deg ned med utviklerteamet ditt og lære om løsningene teamet ser for seg å implementere. Diskuter hvorfor og hvordan. Still spørsmål.
Før du sier: "Men vi har bare så mye tid i løpet av dagen – og hva med budsjettet?", bør du forstå dette: Hvis en løsning du arbeider med kan brukes i mer enn ett prosjekt, trenger ikke denne ekstra tiden for å oppnå forståelse nødvendigvis å være fakturerbar. Du bygger opp fagkompetansen din, noe som forbedrer det daglige arbeidet ditt direkte.
5. Hold kunden orientert
Ha både et internt kravdokument og et WIP-kravdokument rettet mot kunden. I det interne dokumentet trenger du ikke å være like bekymret for å ta med mer transparente notater.
Hvis du ikke håndterer sensitiv informasjon, kan du opprette dette delte området i et Google-dokument, med tillatelser som gjør det mulig for kunden å kommentere. Hvis du håndterer sensitiv informasjon, kan du dele en versjon av kravdokumentet ukentlig for å gi kunden et øyeblikksbilde av det som er dokumentert.
6. Gå ut fra at kunden alltid vil vite mer
I stedet for å risikere å anta at kunden vet mer enn hen faktisk gjør (og senere måtte lide for det), bør du gå ut fra at kunden alltid vil vite mer. Still deg selv spørsmålet «Hvorfor?» fem ganger for hver merknad for å sikre at hvert krav er grundig behandlet.
Å stille deg selv spørsmålet «Hvorfor?» fem ganger for hvert krav utfordrer deg til å virkelig vurdere logikken bak hvert element og hver funksjon på hver sidetype. Du kan bli overrasket over hvor mye du lærer (eller innser at du trenger å lære).
3 eksperttips om å skrive et kravdokument for et prosjekt
1. Skriv krav for globale elementer separat
For å eliminere overflødighet bør du dekke alle globale elementer i en del av kravdokumentasjonen som heter «Globale elementer». Dette gjelder globale elementer som elementene i hovednavigasjonsmenyen, alt i det globale topptekstelementet og alt i bunnteksten.
Når du har skrevet krav for disse globale elementene, trenger du ikke å kommentere dem på de andre sidene. Kommenter bare elementer som er spesifikke for de aktuelle sidene.
2. Kopier og lim inn identisk funksjonalitet for å sikre konsistens
Dette er bare et tips du bør ha i mente for å bevare forstanden din (og kundens). Du vil se dette oftest med vanlige sideelementer som hoved-/bannerbilder, topptekster eller «tilbake»-ikoner – blant et stort antall gjentatte funksjoner på tvers av sidetyper (ikke å forveksle med globale elementer).
3. Ta høyde for administrasjon og CMS (eller mangel på dette)
Når vi er så fokuserte på funksjonaliteten til hvert sideelement, er det lett å overse administrativ funksjonalitet og/eller CMS-funksjonalitet. Hvis du implementerer en løsning som tilbyr administrativ funksjonalitet og/eller CMS-funksjonalitet, må du sørge for å inkludere dette som en egen kolonne i kravene dine. Se eksempelet nedenfor:
Mal for kravdokument [Last ned]
Detaljene i kravdefinisjonen din vil avhenge av forholdet ditt til kunden, teamets erfaring og andre faktorer.
Du vil imidlertid fortsatt trenge de grunnleggende delene av et kravdokument for prosjektet, som beskriver funksjonaliteten, plasseringen, utformingen osv. til en funksjon. Her er malen vår for kravdokumentet (du må være medlem for å få tilgang til den):
Jobb raskere med over 100 premium-maler
Bli DPM-medlem for å få tilgang til et uendelig antall ekspertutviklede maler som hjelper deg med å jobbe raskere og mer effektivt.
