Kravinsamling: Komplett guide & mall

Dessa efterfrågade delar blir projektets kravlista. Leveransen i förhållande till kraven avgör om projektet anses vara framgångsrikt eller inte. 

Projektledare använder kravdokument och verktyg för kravhantering för att hålla reda på dessa typer av krav under projektets gång:

• Funktionella krav
• Tekniska krav
• Icke-funktionella krav
• Systemkrav

Sidonotering:

Insamling av krav är inte begränsad till tidsperioden före produktionen. Dokumentation av ändringsorder, garantidokumentation med mera är användbara former av fortlöpande kravdokumentation som avslöjar nya krav under hela projektet – eller till och med efter projektet!

 

Så länge du arbetar med en kund växer och utvecklas dokumentationen hela tiden.

Varför är insamling av krav viktigt?

Insamling av krav är viktigt av följande orsaker (liksom dokumentationen av dessa krav): 

1. Det fungerar som en referenspunkt för att dokumentera ett projekts utveckling, dess olika delar och dess implementering 
2. Det fungerar som en ritning för projektets intressenter, så att de bättre förstår vad de kan förvänta sig av projektet (projektets vad, var, när och varför).
3. Det minskar utrymmet för fel och tvetydighet, eftersom kraven dokumenteras tydligt och godkänns innan arbetet påbörjas.
4. Det tillhandahåller kontroller och avvägningar under hela projektets genomförande och kvalitetssäkring, så att projektledare och teammedlemmar kan gå tillbaka till det när det råder tvivel om hur man ska gå vidare.

Utöver att beskriva vad de kan förvänta sig bör en effektiv planering av kravhanteringen även beskriva vad de inte ska förvänta sig. Att inkludera ett avsnitt om ”Antaganden” och/eller ”Undantag” är ett klokt sätt att eliminera risken för den fruktade kundfantasin. 

Ett exempel på en kravspecifikation för programvara

Här är ett exempel på en kravspecifikation för ett e-handelsprojekt:

• Vad: PayPal-integration
• Var: Kassan
• När: I steg 3 av 4 i kassaupplevelsen (efter webbformuläret för leveransadress, före bekräftelsen)
• Varför: En etablerad integration (t.ex. PayPal) är i detta fall en bättre lösning än en omfattande specialbyggd integration för en betaltjänst, eftersom den enkelt uppfyller verksamhetens krav.

• Antaganden
  • Fast avgift för all frakt och hantering
  • All frakt sker inom USA (Alaska och Hawaii ingår inte)
  • Skatter tillämpas inte
• Undantag 
  • Specialberäkningar av frakt- och hanteringsavgifter
  • Frakt till andra länder, Alaska eller Hawaii
  • Skatteregler

Kom ihåg: ju mindre skillnaden är mellan kundens förväntningar och verkligheten med deras digitala produkt, desto nöjdare kommer kunden att vara med slutresultatet. Kvaliteten på din kravhantering korrelerar direkt med din förmåga som projektledare att minska alla gråzoner när det gäller kundförväntningar. 

För det mesta kommer en kund att vara positiv till att du begränsar omfattningsglidning om det innebär att du bevarar deras budget; om du utbildar kunden tillräckligt om varför en funktion kommer att hanteras (eller inte hanteras) och sedan dokumenterar logiken bakom det tillvägagångssättet i kraven, är det mycket mer sannolikt att kunden vill samarbeta. 

De kommer sannolikt att ge sitt godkännande, och längre fram när de genomför användaracceptanstestning (UAT) kommer de att ha ett försprång när det gäller att förstå "varför" bakom teamets lösning.

Process i 6 steg för kravinsamling

Även om kravinsamlingen bör börja så snart ett uppdrag inleds och fortsätta under hela projektets livscykel, är det aldrig för tidigt att börja samla in och dokumentera krav. Börja faktiskt redan i går.

Här är stegen för hur du samlar in krav.

1. Anteckna

På varje möte du deltar i – oavsett om det är internt med ditt projektteam eller externt med kunden – ska du alltid anteckna. Utgå aldrig från att någon annan gör det.

I stunden kan det vara lätt att anta att allt som diskuteras kommer att kommas ihåg, men tre månader och 15 möten senare kommer ditt team och din kund att tacka dig för att du har dokumenterat diskussionerna så att ni kan gå tillbaka till dem.

Här hittar du några av mina rekommenderade rutiner för att anteckna krav:

• Innan du går in i mötet ska du förbereda ditt anteckningsdokument så att det speglar dagordningen, så blir det enklare att organisera åtgärdspunkterna och diskussionspunkterna. På så sätt kommer du ihåg vad som behövs samtidigt som du fångar relaterad information på ett organiserat sätt. 
• Efter varje möte ska du avsätta 15–30 minuter för att gå igenom dina anteckningar, bearbeta det som diskuterades, prioritera åtgärdspunkterna och identifiera utmaningar/varningssignaler eller behov av förtydliganden eller ytterligare möten.
• Skicka dina anteckningar till det interna projektteamet. Be dem granska och verifiera det du har identifierat som åtgärdspunkter, varningssignaler osv. 
• När teamet har gett dig sitt godkännande ska du skicka dina anteckningar till kunden. 
• Slutligen ska du använda dina anteckningar som referens när du skapar uppgifter utifrån varje åtgärdspunkt. Lägg till all ny information i kravdokumentationen och schemalägg eventuella möten som behövs för ytterligare kartläggning eller diskussion. 

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.

Create Free Account

Have an account? Log In

2. Gå igenom de kreativa kraven

Överlåt inte beslut om design och utformning till enskilda teammedlemmar: dokumentera de kreativa kraven så ofta det är möjligt. Kreativ vägledning är ovärderlig för utvecklare. Se åtminstone till att du har en grafisk manual till hands – även om den bara innehåller grundläggande information om typsnitt och varumärkesfärger.

Samla in alla kreativa resurser, till exempel varumärkeslogotyper eller varumärkestypsnitt, och ladda upp dem till en gemensam plats (till exempel programvara för hantering av digitala resurser) så att hela teamet får åtkomst och insyn.

3. Skriv kravdokumentet

När du börjar med dokumentationen ska du komma ihåg att ditt första försök med kravdokumentation kommer att vara det svåraste. Varför? Eftersom du inte har något tidigare dokument att utgå från (dvs. KOPIERA-KLISTRA). Som tur är innehåller den här artikeln en mall för kravdokumentation som du kan använda som grund.

Som visas i den här mallen delar jag upp min kravdokumentation i fyra delar:

1. Anteckning: Innehåller numren från din annoterade design. Om din siddesign har 8 element kommer du att ha 8 anteckningar, och din anteckningskolumn kommer att ha 8 rader
2. Element: Innehåller elementrubriker som de relaterar till varje anteckning
3. Funktionellt krav: Innehåller en definition (kraven, specificerade i detalj) för varje element
4. Administrativ funktionalitet/CMS-funktionalitet: Definiera all administrativ funktionalitet och/eller CMS-funktionalitet som är relaterad till motsvarande element

4. Genomför en intern granskning

I den här delen av kravinsamlingsprocessen ska du planera in ännu ett internt möte med projektgruppen för att granska kravdokumentationen. Detta är en sista intern kontroll för att säkerställa att ni har samma förståelse av implementeringen.

Om möjligt bör du låta teamet granska kravdokumentationen före mötet så att de kan komma förberedda med sina frågor och/eller synpunkter. Använd mötet till att diskutera eventuella frågor eller synpunkter på kraven.

Gör alla nödvändiga ändringar i dokumentationen utifrån den interna diskussionen. Skicka slutligen den reviderade kravdokumentationen till teamet igen för ett sista godkännande. När det interna projektteamet har gett sitt slutliga godkännande av kravdokumentationen ska du spara dokumentet som PDF för att säkerställa att det förblir i sitt slutgiltiga skick inför nästa steg: att bygga upp uppgifterna. 

5. Bygg upp uppgifterna

Ge utvecklingsteamet PDF-versionen av kravdokumentationen. Helst bör dina utvecklare eller utvecklingsansvariga bygga upp uppgifterna för projektet. 

Vissa organisationer kan arbeta enligt en process där projektledare bygger upp alla uppgifter, men jag föredrar att utvecklarna bygger upp sina egna uppgifter; de få timmar det tar är väl värda det.

Du kan fortfarande ge teamet användbara riktlinjer när de bygger upp sina utvecklingsuppgifter och leverabler. När uppgifterna har byggts upp kommer du att kunna få en slutlig uppskattning av antalet timmar.

Jämför den prognosen med den projekttidsplan som tidigare har kommunicerats till kunden och hantera projektet därefter vid behov. Mer information om projektuppskattningar finns i den här fullständiga guiden till projektuppskattning.

6. Genomför en extern granskning

Det är dags att presentera kravdokumentationen för kunden. Tillhandahåll den som PDF för att säkerställa att inga ändringar görs. Detta (1) visar att du har gjort en insats för att säkerställa kundens förståelse av den digitala lösningen och (2) fungerar som en försäkring för dig, så att du kan säga ”vad var det jag sa” (men på ett betydligt mer vältaligt sätt) när den oundvikliga scopeglidningen i projektet dyker upp.

Utbilda kunden. Gå igenom den här värdefulla dokumentationen som du har lagt ner så mycket arbete på att sammanställa åt dem. Kom ihåg: de är experterna på sin verksamhet. Du är experten på den digitala lösning du erbjuder dem. De betalar dig för den här lösningen. Utbilda och stärk kunden. 

När kunden har bekräftat sin förståelse av kravdokumentationen är det dags att få ett formellt godkännande. Skicka den undertecknade och godkända kravdokumentationen till teamet och spara den på en gemensam plats, så att det finns en formell bekräftelse på att utvecklingen kan börja.

Tekniker för kravinsamling

Här är några tekniker som hjälper dig att säkerställa att du utför det viktiga kravinsamlingsarbetet så bra som möjligt:

1. Börja direkt

Kravdokumentationen bör påbörjas så snart samtalen börjar, innan du har fastställt den exakta projektplanen eller projektmålen. Fånga allt du kan och sålla sedan bort det som inte behövs. Här är några strategier som du kan prova med kunden:

• Skicka dem ett frågeformulär om vad de vill se i projektet
• Genomför en brainstorming-session
• Håll en fokusgrupp

I stället för att ta bort information från dokumentet kan du kategorisera den i vad som ingår och vad som inte ingår – på så sätt undviker du att kunden gör egna antaganden längre fram.

Du kommer att kunna ta fram din kravdokumentation för WIP (arbete som pågår) och visa var informationen fångades upp, varför den kanske inte ingår, resonemanget bakom beslutet och datumet då detta fångades upp, vilket gör den spårbar.

2. Använd mallar

När du har några kravdokument bakom dig kan du börja dra nytta av dem och använda dem som mallar för framtida bruk i andra projekt. Särskilt om du har ett specifikt fokus på e-handels- eller utbildningsapplikationsprojekt kommer du att börja se funktionsmönster träda fram. Identifiera var du kan återanvända. 

3. Tillsammans kan vi förverkliga drömmen

Om det finns olika typer av teammedlemmar i ett projekt kan kraven för varje expertområde formuleras av respektive expert.

I många fall är samtalet om krav en slingrande väg av telefonsamtal, olika separata möten och samtal med mera. Därför är det viktigt att du tilldelar dokumentationen av kraven till respektive teammedlem medan du arbetar med att samla in och sammanställa kraven.

4. Dokumentera inte bara kraven – lär dig

Gör mer än att bara anteckna. Förvänta dig mer än att personer skickar ett textblock via e-post som består av deras del av kraven. Ta dig tid att sätta dig ner med ditt utvecklarteam och lär dig vilka lösningar teamet har i åtanke för implementeringen. Diskutera varför och hur. Ställ frågor.

Innan du säger: ”Men vi har bara så mycket tid på dagen – och hur är det med budgeten?”, bör du förstå detta: om en lösning du arbetar med är tillämplig på mer än ett projekt behöver den extra tiden för att skapa förståelse inte nödvändigtvis vara fakturerbar. Du bygger upp din ämneskompetens, vilket direkt förbättrar ditt dagliga arbete. 

5. Håll kunden informerad

Ha både ett internt kravdokument och ett arbetsdokument med krav som är riktat till kunden. I det interna dokumentet behöver du inte vara lika försiktig med att inkludera mer transparenta anteckningar.

Om du inte hanterar känslig information kan du skapa denna gemensamma yta i ett Google-dokument, med behörigheter som gör det möjligt för kunden att kommentera. Om du hanterar känslig information kan du dela en version av kravdokumentet varje vecka för att ge kunden en ögonblicksbild av vad som har dokumenterats.

6. Utgå från att kunden alltid vill veta mer

I stället för att riskera att anta att kunden vet mer än vad hen gör och sedan få problem på grund av det, bör du utgå från att kunden alltid vill veta mer. För varje anteckning kan du ställa frågan ”Varför?” fem gånger för att säkerställa att varje krav är grundligt genomarbetat. 

Att ställa frågan ”Varför?” fem gånger för varje krav utmanar dig att verkligen överväga logiken bakom varje element och varje funktion på respektive sidtyp. Du kan bli förvånad över hur mycket du lär dig (eller inser att du behöver lära dig).

3 experttips för att skriva ett kravdokument för projekt

1. Skriv kraven för globala element separat

För att eliminera upprepningar bör du samla alla globala element i ett avsnitt med namnet ”Globala element” i kravdokumentationen. Detta gäller globala element som objekt i huvudnavigeringsmenyn, allt i det globala sidhuvudet och allt i sidfoten. 

När du har skrivit kraven för dessa globala element behöver du inte anteckna dem på de övriga sidorna; anteckna endast element som är specifika för respektive sida.

More Articles

• Så bemästrar du resurshantering i projektledning

2. Kopiera och klistra in identisk funktionalitet för att säkerställa konsekvens

Detta är helt enkelt ett tips att ha i åtanke för ditt (och din kunds) förstånds skull. Du kommer att se detta oftast med vanliga sidelement som herobilder eller bannerbilder, sidhuvuden eller ikoner för ”tillbaka” – bland en mängd upprepad funktionalitet mellan olika sidtyper (vilket inte ska förväxlas med globala element). 

3. Ta hänsyn till administration och CMS (eller avsaknaden av detta)

När vi fokuserar så mycket på funktionaliteten hos varje sidelement är det lätt att bortse från administrativ funktionalitet och/eller CMS-funktionalitet. Om du implementerar en lösning som erbjuder administrativ funktionalitet och/eller CMS-funktionalitet bör du se till att inkludera detta som en egen kolumn i kravdokumentet. Exempel nedan:

Mall för kravdokument [Ladda ner]

Detaljerna i din kravdefinition beror på din relation till kunden, ditt teams erfarenhet och andra faktorer.

Du behöver dock fortfarande de grundläggande delarna i ett projektkravdokument som definierar en funktions funktionalitet, placering, design och så vidare. Här är vår mall för kravdokument (du måste vara medlem för att få tillgång till den):

Öka hastigheten med över 100 premiummallar

Bli DPM-medlem för att få tillgång till ett obegränsat antal expertframtagna mallar som hjälper dig att arbeta snabbare och effektivare.