Kravindsamling: Komplet guide & skabelon

Disse anmodninger bliver til projektets kravliste. Leveringen i forhold til kravene afgør, om projektet betragtes som vellykket eller ej. 

Projektledere bruger kravdokumenter og værktøjer til kravstyring til at holde styr på disse typer krav gennem hele projektet:

• Funktionelle krav
• Tekniske krav
• Ikke-funktionelle krav
• Systemkrav

Sidebemærkning:

Kravindsamling er ikke begrænset til tidsrummet før produktionen. Dokumentation af ændringsordrer, garantidokumentation osv. er nyttige former for løbende kravdokumentation, der afslører nye krav gennem hele projektet – eller endda efter projektet!

 

Så længe du arbejder sammen med en kunde, vokser og udvikler dokumentationen sig hele tiden.



Hvorfor er kravindsamling vigtig?

Kravindsamling er vigtig af følgende årsager (ligesom dokumentationen af disse krav): 

1. Den fungerer som et referencepunkt til at dokumentere et projekts udvikling, dets bevægelige dele og dets implementering 
2. Den fungerer som en plan, der hjælper projektets interessenter med bedre at forstå, hvad de kan forvente af projektet (projektets hvad, hvor, hvornår og hvorfor).
3. Den reducerer risikoen for fejl og uklarhed, fordi kravene er tydeligt dokumenteret og godkendt, før arbejdet begynder.
4. Den giver kontroller og balancer gennem hele projektproduktionen og kvalitetssikringen, så projektlederne og teammedlemmerne kan vende tilbage til den, når der er tvivl om, hvordan man skal gå videre.

Ud over at beskrive, hvad de kan forvente, bør effektiv planlægning af kravstyringen beskrive, hvad de ikke skal forvente. Det er en god tilgang at inkludere et afsnit om “Antagelser” og/eller “Undtagelser” for at eliminere risikoen for den frygtede kundeforestillingsevne. 

Et eksempel på en kravspecifikation for software

Her er et eksempel på en kravspecifikation for et e-handelsprojekt:

• Hvad: PayPal-integration
• Hvor: Betaling
• Hvornår: I trin 3 ud af 4 i betalingsforløbet (efter webformularen med leveringsadresse og før bekræftelsen)
• Hvorfor: En etableret integration (f.eks. PayPal) er i dette tilfælde en bedre løsning end en robust specialbygget integration til en betalingstjeneste, fordi den nemt opfylder forretningskravene.

• Antagelser
  • Fast gebyr for al forsendelse og håndtering
  • Al forsendelse foregår inden for USA (Alaska og Hawaii er ikke inkluderet)
  • Der gælder ingen skatter
• Undtagelser 
  • Specialberegninger af gebyrer for forsendelse og håndtering
  • Forsendelse internationalt, til Alaska eller til Hawaii
  • Skatteregler

Husk: Jo mindre forskellen mellem kundens forventninger og virkeligheden med deres digitale produkt er, desto mere tilfreds bliver kunden med det endelige resultat. Kvaliteten af din kravstyring hænger direkte sammen med din evne som projektleder til at reducere ethvert gråområde, når det gælder kundens forventninger. 

Langt de fleste gange vil en kunde være positiv over for, at du begrænser omfangskryb, hvis det betyder, at du beskytter deres budget; hvis du i tilstrækkelig grad forklarer kunden, hvorfor en funktion vil blive håndteret (eller ikke håndteret), og derefter dokumenterer logikken bag denne tilgang i kravene, er kunden langt mere tilbøjelig til at samarbejde. 

De vil være mere tilbøjelige til at give deres godkendelse, og senere, når de gennemfører brugergodkendelsestest (UAT), vil de have et forspring i forståelsen af "hvorfor" bag dit teams løsning.

6-trinsproces til indsamling af krav

Selvom indsamlingen af krav bør begynde, så snart et samarbejde starter, og fortsætte gennem hele din projektlivscyklus, er det aldrig for tidligt at begynde at indsamle og dokumentere krav. Faktisk burde du være begyndt i går.

Her er trinene til, hvordan du indsamler krav.

1. Tag noter

Ved hvert møde, du deltager i – uanset om det er internt med dit projektteam eller eksternt med din kunde – skal du altid tage noter. Gå aldrig ud fra, at en anden tager dem.

Mens mødet foregår, kan det være nemt at antage, at alt det, der bliver drøftet, vil blive husket, men tre måneder og 15 møder senere vil dit team og din kunde takke dig for at have en optegnelse over disse drøftelser, som I kan se tilbage på.

Se nogle af mine anbefalede fremgangsmåder til at tage noter om krav her:

• Inden du går ind til mødet, skal du forberede dit notedokument, så det afspejler din dagsorden, så det bliver nemmere at organisere handlingspunkterne og de vigtigste punkter. På den måde husker du, hvad der er nødvendigt, samtidig med at du indsamler relaterede oplysninger på en organiseret måde. 
• Efter ethvert møde skal du afsætte 15-30 minutter til dig selv til at gennemgå dine noter, fordøje det, der blev drøftet, prioritere handlingspunkterne og identificere udfordringer/advarselslamper eller behov for afklaring eller yderligere møder.
• Send dine noter til dit interne projektteam. Få dem til at gennemgå og bekræfte det, du har identificeret som handlingspunkter, advarselslamper osv. 
• Når teamet har givet dig deres godkendelse, skal du sende dine noter til kunden. 
• Til sidst skal du bruge dine noter som reference til at oprette opgaver ud fra hvert handlingspunkt. Tilføj alle nye oplysninger til din kravdokumentation, og planlæg de nødvendige møder til yderligere afdækning eller drøftelse. 

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

2. Gennemgå de kreative krav

Overlad ikke beslutninger om design og stil til de enkelte teammedlemmer: fastlæg de kreative krav, når det er muligt. Kreativ vejledning er uvurderlig for udviklere. Som minimum skal du sørge for at have en designmanual ved hånden – selv hvis den kun indeholder de mest grundlæggende oplysninger som skrifttype og brandfarver.

Indsaml alle kreative ressourcer, såsom brandlogoer eller brandskrifttyper, og upload dem til et fælles område (f.eks. software til håndtering af digitale aktiver), så hele teamet har adgang til dem og kan se dem.

3. Skriv kravdokumentet

Når du går i gang med dokumentationen, skal du huske: Første gang, du udarbejder kravdokumentation, vil være den sværeste. Hvorfor? Fordi du ikke har et tidligere dokument, du kan tage udgangspunkt i (såkaldt KOPIÉR-INDSÆT). Heldigvis indeholder denne artikel en skabelon til kravdokumentation, som du kan bruge som fundament.

Som vist i denne skabelon opdeler jeg min kravdokumentation i fire dele:

1. Annotering: Indeholder numrene fra dit annoterede design. Hvis dit sidedesign har 8 elementer, vil du have 8 annoteringer, og din annoteringskolonne vil have 8 rækker
2. Element: Indeholder elementtitler, som de relaterer sig til hver annotering
3. Funktionelt krav: Indeholder en definition (kravene, udfoldet) for hvert element
4. Administrator-/CMS-funktionalitet: Definer enhver administrations- og/eller CMS-funktionalitet, der relaterer sig til det tilsvarende element

4. Gennemfør en intern gennemgang

I denne del af processen med indsamling af krav skal du planlægge endnu et internt møde med dit projektteam for at gennemgå din kravdokumentation. Dette er en sidste intern kontrol og afstemning for at sikre, at du har forstået implementeringen korrekt.

Hvis det er muligt, skal du få teamet til at gennemgå din kravdokumentation inden mødet, så de kan møde op klar med deres spørgsmål og/eller feedback. Brug mødet til at drøfte eventuelle spørgsmål eller feedback om kravene.

Foretag eventuelle nødvendige ændringer i dokumentationen baseret på jeres interne drøftelse. Send til sidst den reviderede kravdokumentation til teamet igen for en sidste godkendelse. Når det interne projektteam har givet deres endelige godkendelse af kravdokumentationen, skal du gemme dokumentet som en PDF for at sikre, at det forbliver i sin endelige form til næste trin: udarbejdelse af opgaver. 

5. Udarbejd opgaver

Giv dit udviklingsteam PDF-versionen af kravdokumentationen. Ideelt set vil dine udviklere eller din udviklingsansvarlige udarbejde opgaverne til leverancen. 

Selvom nogle organisationer arbejder efter en proces, hvor projektledere udarbejder alle opgaver, foretrækker jeg at lade udviklerne udarbejde deres egne opgaver; de få timer, det tager dem, er det værd.

Du kan stadig give dit team nyttige retningslinjer , mens de udarbejder deres udviklingsopgaver og leverancer. Efter udarbejdelsen af opgaverne vil du kunne få et endeligt estimat i timer.

Sammenlign denne fremskrivning med den projekttidsplan, der tidligere er blevet kommunikeret til din kunde, og tilpas styringen efter behov. Hvis du vil vide mere om estimering af projekter, kan du se denne komplette guide til projektestimering.

6. Gennemfør en ekstern gennemgang

Det er tid til at præsentere kravdokumentationen for din kunde. Giv den som en PDF for at sikre, at der ikke foretages ændringer. Dette (1) viser, at du investerer i at sikre kundens forståelse af den digitale løsning, og (2) fungerer som en forsikring for dig, så du kan sige “hvad sagde jeg” (men langt mere velformuleret), når projektets omfang uundgåeligt begynder at vokse.

Undervis din kunde. Gå dem igennem denne værdifulde dokumentation, som du har lagt så meget arbejde i at udarbejde til dem. Husk: De er eksperterne i deres virksomhed. Du er eksperten i den digitale løsning, du tilbyder dem. De betaler dig for denne løsning. Undervis og styrk din kunde. 

Når kunden har bekræftet sin forståelse af kravdokumentationen, er det tid til at modtage en formel godkendelse. Send den underskrevne og godkendte kravdokumentation til dit team, og gem den på et fælles sted, så der foreligger en formel indikation af, at udviklingen kan begynde.

Teknikker til indsamling af krav

Her er nogle teknikker, der kan hjælpe dig med at sikre, at du udfører det vigtige arbejde med indsamling af krav så godt som muligt:

1. Gå i gang med det samme

Kravdokumentationen bør begynde, så snart samtalerne starter, før du har fastlagt den præcise projektplan eller projektmål. Notér alt, hvad du kan, og begræns det derefter. Her er nogle strategier, du kan prøve med din kunde:

• Send dem et spørgeskema om, hvad de gerne vil se i projektet
• Gennemfør en brainstormingssession
• Afhold en fokusgruppe

I stedet for at fjerne oplysninger fra dokumentet skal du kategorisere dem som inkluderet eller ikke inkluderet – det forebygger kundeantagelser senere i forløbet.

Du vil kunne finde din WIP-kravdokumentation (igangværende arbejde) frem og påpege, hvor oplysningerne blev dokumenteret, hvorfor de muligvis ikke er inkluderet, logikken bag beslutningen samt datoen, hvor dette blev dokumenteret, så det kan spores.

2. Brug skabeloner

Når du først har nogle få kravdokumenter på bagen, kan du begynde at udnytte dem og bruge dem som skabeloner til fremtidig brug i andre projekter. Især hvis du har et specifikt fokus på e-handels- eller læringsapplikationsprojekter, vil du begynde at se funktionsmønstrene dukke op. Identificér, hvor du kan genbruge. 

3. Samarbejde får drømmen til at fungere

Hvis der er forskellige typer teammedlemmer på et projekt, kan kravene for hvert ekspertiseområde udarbejdes af de respektive eksperter.

I mange tilfælde er samtalen om krav en kringlet række af telefonopkald, forskellige separate møder og samtaler osv. Derfor er det afgørende, at du fordeler dokumentationen af krav til de respektive teammedlemmer, efterhånden som du indsamler og sammenstiller kravene.

4. Registrér ikke bare kravene—lær

Gør mere end blot at tage noter. Forvent mere end at ressourcer sender dig en mur af tekst på e-mail, som udgør deres del af kravene. Tag dig tid til at sætte dig sammen med dit team af udviklere og lære de løsninger, teamet har i tankerne til implementeringen. Tal om hvorfor og hvordan. Stil spørgsmål.

Før du siger: "Men vi har kun et begrænset antal timer i døgnet—og hvad med budgettet?", skal du forstå dette: Hvis en løsning, du arbejder på, kan bruges til mere end ét projekt, behøver denne ekstra tid til at opnå forståelse ikke nødvendigvis være fakturerbar. Du opbygger din fagekspertise, som direkte forbedrer dit daglige arbejde. 

5. Hold din kunde orienteret

Hav både et internt kravdokument og et kundeorienteret WIP-kravdokument. I det interne dokument behøver du ikke være lige så bekymret for at inkludere mere gennemsigtige noter.

Hvis du ikke håndterer følsomme oplysninger, kan du oprette dette fælles område via et Google-dokument med tilladelser, så kunden kan kommentere. Hvis du håndterer følsomme oplysninger, kan du dele en version af kravdokumentet hver uge for at give kunden et øjebliksbillede af, hvad der er blevet dokumenteret.

6. Gå ud fra, at din kunde altid vil vide mere

I stedet for at løbe risikoen ved at antage, at din kunde ved mere, end vedkommende gør (og senere blive straffet for det), skal du gå ud fra, at din kunde altid vil vide mere. Stil dig selv spørgsmålet “Hvorfor?” fem gange for hver annotering for at sikre, at hvert krav er grundigt. 

At spørge dig selv “Hvorfor?” fem gange for hvert krav udfordrer dig til virkelig at overveje logikken bag hvert element og hver funktion på hver sidetype. Du bliver måske overrasket over, hvor meget du lærer (eller indser, at du har brug for at lære).

3 eksperttips til at skrive et projektkravdokument

1. Skriv krav til globale elementer separat

For at eliminere overflødighed skal du samle alle globale elementer i et afsnit med titlen “Globale elementer” i din kravdokumentation. Det gælder for globale elementer som punkterne i din hovednavigation, alt i din globale sidehovedsektion og alt i din sidefod. 

Når du har skrevet kravene til disse globale elementer, behøver du ikke annotere dem på de øvrige sider; annotér kun elementer, der er specifikke for de pågældende sider.

More Articles

• 10 bedste værktøjer til kravstyring anmeldt for 2026
• Anmeldelse af de 10 bedste værktøjer til dokumentsamarbejde 2026
• 10 bedste værktøjer som alternativer til Mural til samarbejde i 2026
• 10 bedste værktøjer til kravstyring med åben kildekode gennemgået i 2026
• 10 bedste AI-værktøjer til kravstyring anmeldt i 2026

2. Kopiér og indsæt identisk funktionalitet for at sikre ensartethed

Dette er blot et tip, du bør have i tankerne for din egen (og din kundes) fornufts skyld. Du vil især se dette ved almindelige sideelementer som fremhævede billeder/bannerbilleder, sidehoveder eller “tilbage”-ikoner—blandt et stort antal gentagne funktioner på tværs af sidetyper (må ikke forveksles med globale elementer). 

3. Tag højde for administration og CMS (eller manglen på samme)

Når vi er så fokuserede på funktionaliteten af hvert sideelement, er det let at se bort fra administrativ funktionalitet og/eller CMS-funktionalitet. Hvis du implementerer en løsning, der tilbyder administrativ funktionalitet og/eller CMS-funktionalitet, skal du sørge for at inkludere dette som sin egen kolonne i dine krav. Eksempel nedenfor:

Skabelon til kravdokument [Hent]

Detaljerne i din kravdefinition afhænger af dit forhold til kunden, dit teams erfaring og andre faktorer.

Du får dog stadig brug for de grundlæggende dele af et kravdokument for et projekt, som beskriver en funktions funktionalitet, placering, design osv. Her er vores skabelon til kravdokumentet (du skal være medlem for at få adgang til den):

Få mere fart på med over 100 premiumskabeloner

Bliv DPM-medlem for at få adgang til endeløse skabeloner skabt af eksperter, som hjælper dig med at arbejde hurtigere og mere effektivt.