Indsamling af krav: Komplet guide & skabelon

Disse anmodninger bliver til projektets kravliste. Leveringen i henhold til kravene afgør, om indsatsen betragtes som et vellykket projekt eller ej. 

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

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

Bemærkning:

Indsamling af krav er ikke begrænset til perioden før produktionen. Dokumentation af ændringsordrer, garantidokumentation osv. er nyttige former for løbende kravdokumentation, som 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 indsamling af krav vigtig?

Indsamling af krav er vigtig af følgende årsager (ligesom dokumentation af disse krav): 

1. Det fungerer som et referencepunkt til at dokumentere et projekts udvikling, dets bevægelige dele og dets implementering 
2. Det fungerer som en plan for projektets interessenter, så de bedre kan forstå, hvad de kan forvente af projektet (projektets hvad, hvor, hvornår og hvorfor).
3. Det reducerer risikoen for fejl og uklarhed, fordi kravene er tydeligt dokumenteret og aftalt, før arbejdet begynder.
4. Det giver kontroller og balancer gennem hele projektproduktionen og QA, så projektlederne og teammedlemmerne kan vende tilbage til det, 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 kravhåndtering beskrive, hvad de ikke skal forvente. Det er en klog tilgang at inkludere et afsnit om “Antagelser” og/eller “Udeladelser” for at eliminere risikoen for den frygtede kundefantasi. 

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 af 4 i betalingsforløbet (efter webformularen med leveringsadresse, før bekræftelse)
• 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)
  • Skatter gælder ikke
• Udeladelser 
  • Tilpassede beregninger 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åt område, når det gælder kundens forventninger. 

Det meste af tiden vil en kunde være positiv over for, at du begrænser udvidelse af projektets omfang, 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, vil kunden være langt mere tilbøjelig til at samarbejde. 

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

Proces i 6 trin 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.

I øjeblikket kan det være nemt at gå ud fra, 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 handlingspunkter og andre punkter. På den måde husker du, hvad der er nødvendigt, samtidig med at du indfanger 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. Bed dem 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 eventuelle 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 du har en stilguide ved hånden – også selvom den kun indeholder de mest grundlæggende oplysninger om skrifttyper og brandfarver.

Indsaml alle kreative aktiver, f.eks. brandlogoer eller brandskrifttyper, og upload dem til et fælles område (f.eks. software til administration 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 dokumenterer krav, bliver den vanskeligste. Hvorfor? Fordi du ikke har et tidligere dokument, du kan bruge (også kendt som KOPIÉR-OG-INDSÆT). Heldigvis indeholder denne artikel en skabelon til kravdokumentation, som kan fungere som et fundament for dig.

Som det fremgår af denne skabelon, opdeler jeg min kravdokumentation i fire dele:

1. Anmærkning: Indeholder numrene fra dit annoterede design. Hvis dit sidedesign har 8 elementer, har du 8 anmærkninger, og din anmærkningskolonne vil have 8 rækker
2. Element: Indeholder elementtitler, som de relaterer sig til hver anmærkning
3. Funktionelt krav: Indeholder en definition (kravene, skrevet ud) for hvert element
4. Administrations-/CMS-funktionalitet: Definér 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 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 med deres spørgsmål og/eller feedback klar. Brug mødet til at drøfte eventuelle spørgsmål eller feedback om kravene.

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

5. Opbyg opgaverne

Giv dit udviklingsteam PDF-versionen af kravdokumentationen. Ideelt set vil dine udviklere eller udviklingsansvarlige stå for opbygningen af opgaverne til udviklingen. 

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

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

Sammenlign denne beregning med den projekttidsplan, der tidligere er blevet kommunikeret til din kunde, og administrer projektet derefter, hvis og når det er nødvendigt. 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 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) vil fungere som en forsikring for dig, så du kan sige "Hvad sagde jeg" (men langt mere velformuleret), når det uundgåelige omfangsskred i projektet viser sig.

Uddan 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. Uddan 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 ved hjælp af software til dokumenthåndtering, 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. Kom i gang med det samme

Kravdokumentationen bør begynde, så snart samtalerne går i gang, 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
• Afhold en brainstormingssession
• Afhold en fokusgruppe

I stedet for at fjerne oplysninger fra dokumentet skal du kategorisere dem i, hvad der er inkluderet, og hvad der ikke er inkluderet—det undgår kundens antagelser senere i forløbet.

Du vil kunne trække din dokumentation af WIP-krav (igangværende arbejde) frem og påpege, hvor oplysningerne blev registreret, hvorfor de muligvis ikke er inkluderet, logikken bag beslutningen og datoen, hvor dette blev registreret, så det kan spores.

2. Gør brug af skabeloner

Når du har udarbejdet nogle få kravdokumenter, 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. Identificer, hvor du kan genbruge dem. 

3. Samarbejde får drømmen til at gå i opfyldelse

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

I mange tilfælde er samtalen om krav et kringlet spor 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. Du skal ikke bare registrere kravene – lær

Gør mere end blot at tage noter. Forvent mere end at ressourcer sender dig en mur af tekst, der udgør deres del af kravene. Tag dig tid til at sætte dig sammen med dit udviklerteam 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 så meget tid på dagen – og hvad med budgettet?", skal du forstå dette: Hvis en løsning, du arbejder på, kan anvendes til mere end ét projekt, behøver den ekstra tid til at opnå en forståelse ikke nødvendigvis være fakturerbar. Du opbygger din fagekspertise, hvilket direkte forbedrer dit daglige arbejde. 

5. Hold din kunde orienteret

Hav både et internt kravdokument og et WIP-kravdokument, der er rettet mod kunden. 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 delte område via et Google-dokument, hvor kunden har tilladelse til at 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 registreret.

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 brændt af det), skal du gå ud fra, at din kunde altid vil vide mere. Stil dig selv spørgsmålet “Hvorfor?” fem gange for hver annotation for at sikre, at hvert krav er grundigt beskrevet. 

Når du stiller dig selv spørgsmålet “Hvorfor?” fem gange for hvert krav, bliver du udfordret til virkelig at overveje logikken bag hvert element og hver funktionalitet 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 projektkravsdokument

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. Dette gælder for globale elementer såsom punkterne i din hovednavigationsmenu, alt i din globale sidehovedsektion og alt i din sidefod. 

Når du har skrevet kravene til disse globale elementer, behøver du ikke at 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 oftest se dette ved almindelige sideelementer såsom hero-/bannerbilleder, sidehoveder eller “tilbage”-ikoner – blandt et stort antal gentagne funktionaliteter 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 nemt at se bort fra administrativ og/eller CMS-funktionalitet. Hvis du implementerer en løsning, der tilbyder administrativ 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]

De specifikke detaljer 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 definerer en funktions funktionalitet, placering, design osv. Her er vores skabelon til kravdokumenter (du skal være medlem for at få adgang til den):

Arbejd hurtigere med over 100 premiumskabeloner

Bliv DPM-medlem for at få adgang til et uendeligt antal ekspertudviklede skabeloner, der hjælper dig med at arbejde hurtigere og mere effektivt.