Insamling av krav: Komplett guide & mall
Kravinsamling är en process som gör det möjligt för dig att fastställa och hantera förväntningar med intressenter, förhindra att projektets omfattning växer okontrollerat och minska oklarheter kring vad ditt projekt faktiskt levererar.
Ju mer kravdokumentation du har, desto mindre utrymme finns det för fel och antaganden. Kontrollerna och avstämningarna hjälper ditt team att få en gemensam förståelse av projektet och av kundens förväntningar på slutprodukten.
Vad är kravinsamling inom projektledning?
Kravinsamling är processen att fastställa vad projektsponsorerna och de viktigaste intressenterna behöver från projektet. Projektledare arbetar med att identifiera vad som efterfrågas och detaljerna kring det som efterfrågas.
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
Dessa önskemål blir projektets kravlista. Leveransen i förhållande till kraven avgör om arbetet betraktas som ett lyckat projekt eller inte.
Projektledare använder kravdokument och verktyg för kravhantering för att hålla reda på följande typer av krav under hela projektet:
- Funktionella krav
- Tekniska krav
- Icke-funktionella krav
- Systemkrav
Varför är kravinsamling viktigt?
Kravinsamling är viktigt av följande orsaker (liksom att dokumentera dessa krav):
- Det fungerar som en referenspunkt för att dokumentera ett projekts utveckling, dess olika delar och dess genomförande
- Det fungerar som en ritning som hjälper projektets intressenter att bättre förstå vad de kan förvänta sig av projektet (projektets vad, var, när och varför).
- Det minskar utrymmet för fel och oklarheter, eftersom kraven dokumenteras tydligt och godkänns innan arbetet börjar.
- Det ger kontroller och avstämningar under hela projektets produktion och kvalitetssäkring, så att projektledare och teammedlemmar kan gå tillbaka till det när det råder tvivel om hur de ska gå vidare.
Förutom att beskriva vad de kan förvänta sig bör en effektiv planering av kravhanteringen även beskriva vad de inte kan förvänta sig. Att inkludera ett avsnitt om ”Antaganden” och/eller ”Undantag” är ett klokt sätt att undanröja risken för den fruktade kundfantasin.
Exempel på en specifikation av programvarukrav
Här är ett exempel på en kravspecifikation för ett e-handelsprojekt:
- Vad: PayPal-integrering
- Var: Kassan
- När: I steg 3 av 4 i kassaprocessen (efter webbformuläret för leveransadress, före bekräftelsen)
- Varför: En etablerad integrering (t.ex. PayPal) är i det här fallet en bättre lösning än en omfattande specialbyggd integrering 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 (exklusive Alaska och Hawaii)
- Inga skatter tillkommer
- Undantag
- Specifika beräkningar av frakt- och hanteringsavgifter
- Frakt internationellt, till Alaska eller till Hawaii
- Skatteregler
Kom ihåg: ju mindre skillnaden är mellan kundens förväntningar och verkligheten för 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 kundens förväntningar.
För det mesta kommer en kund att vara positiv till att du begränsar omfattningsglidning om det innebär att du skyddar 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 samarbetar.
Det är mer sannolikt att de ger 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 din projektlivscykel, ä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 en dokumentation av diskussionerna att gå tillbaka till.
Ta del av några av mina rekommenderade rutiner för att anteckna krav här:
- Innan du går in i mötet ska du förbereda ditt anteckningsdokument så att det återspeglar din agenda, så att det blir 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 ditt interna projektteam. Be dem gå igenom och verifiera det du har identifierat som åtgärdspunkter, varningssignaler och så vidare.
- 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 din kravdokumentation och schemalägg de möten som behövs för ytterligare kartläggning eller diskussion.
2. Gå igenom de kreativa kraven
Överlåt inte design- och stilbeslut åt enskilda teammedlemmar: fastställ de kreativa kraven när det är möjligt. Kreativ vägledning är ovärderlig för utvecklare. Se åtminstone till att du har en stilguide till hands – även om den bara innehåller grundläggande information som typsnitt och varumärkesfärger.
Samla in alla kreativa tillgångar, till exempel varumärkeslogotyper och varumärkestypsnitt, och ladda upp dem till en gemensam plats (till exempel programvara för hantering av digitala tillgångar) 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? Därför att du inte har något tidigare dokument att utgå från (det vill säga KOPIERA-KLISTRA). Som tur är innehåller den här artikeln en mall för kravdokumentation som kan fungera som grund för dig.
Som visas i den här mallen delar jag in min kravdokumentation i fyra delar:
- 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
- Element: Innehåller elementrubriker som de relaterar till varje anteckning
- Funktionellt krav: Innehåller en definition (kraven, specificerade i detalj) för varje element
- Administrativ/CMS-funktionalitet: Definiera eventuell administrativ funktionalitet och/eller CMS-funktionalitet som är relaterad till motsvarande element
4. Genomför en intern granskning
I den här delen av processen för kravinsamling ska du planera in ytterligare ett internt möte med ditt projektteam 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 revideringar av dokumentationen utifrån er interna diskussion. 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 behåller sitt slutgiltiga skick inför nästa steg: att skapa uppgifter.
5. Skapa uppgifter
Ge PDF-versionen av kravdokumentationen till ditt utvecklingsteam. Idealt sett kommer dina utvecklare eller utvecklingsansvariga att skapa uppgifterna för utvecklingen.
Även om vissa organisationer kan arbeta enligt en process där projektledare skapar alla uppgifter föredrar jag att låta utvecklarna skapa sina egna uppgifter; de få timmar det tar är väl värda det.
Du kan fortfarande ge användbara riktlinjer till ditt team när de skapar sina utvecklingsuppgifter och leveranser. När uppgifterna har skapats kommer du att kunna få en slutlig uppskattning av antalet timmar.
Jämför den prognosen med projekttidsplanen som tidigare har kommunicerats till kunden och hantera projektet därefter om och när det behövs. Mer information om att uppskatta projekt finns i denna fullständiga guide 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 investerar i att säkerställa att kunden förstår 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 betydligt mer vältaligt) när projektets omfattning oundvikligen börjar växa.
Utbilda kunden. Gå igenom den värdefulla dokumentation som du så omsorgsfullt har sammanställt åt dem. Kom ihåg: de är experterna på sin verksamhet. Du är expert på den digitala lösning du erbjuder dem. De betalar dig för denna lösning. Utbilda och stärk din kund.
När kunden har bekräftat att de förstår kravdokumentationen är det dags att få ett formellt godkännande. Skicka den undertecknade och godkända kravdokumentationen till ditt team och spara den på en gemensam plats med hjälp av dokumenthanteringsprogramvara, så att det finns en formell indikation 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 genomför det viktiga arbetet med kravinsamling 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 begränsa det sedan. Här är några strategier 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 antaganden längre fram.
Du kommer att kunna plocka fram din WIP-dokumentation (dokumentation av pågående arbete) om kraven och ange var informationen dokumenterades, varför den eventuellt inte inkluderades, logiken bakom beslutet och datumet då detta dokumenterades, vilket gör den spårbar.
2. Använd mallar
När du har några kravdokument bakom dig kan du börja utnyttja dem och skapa mallar av dem för framtida användning i andra projekt. Särskilt om du har ett specifikt fokus på e-handelsprojekt eller projekt för utbildningsapplikationer kommer du att börja se funktionalitetsmönster träda fram. Identifiera var du kan återanvända.
3. Tillsammans når teamet längre
Om det finns olika typer av teammedlemmar i ett projekt kan kraven för varje expertområde formuleras av de respektive experterna.
I många fall är samtalet om krav en krokig väg av telefonsamtal, flera separata möten och samtal med mera. Därför är det avgörande att du tilldelar dokumentationen av kraven till berörda teammedlemmar allt eftersom du samlar in och sammanställer kraven.
4. Dokumentera inte bara kraven – lär dig
Gör mer än att anteckna. Förvänta dig mer än att resurspersoner mejlar dig en vägg av text som utgör deras del av kraven. Ta dig tid att sätta dig ner med ditt utvecklingsteam och lära 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 kan användas i mer än ett projekt behöver den extra tiden för att skapa förståelse inte nödvändigtvis vara debiterbar. 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 WIP-kravdokument för kunden. I det interna dokumentet behöver du inte vara lika återhållsam med att inkludera mer transparenta anteckningar.
Om du inte hanterar känslig information kan du skapa denna gemensamma yta via ett Google-dokument och aktivera behörigheter så att kunden kan kommentera. Om du hanterar känslig information kan du varje vecka dela en version av kravdokumentet för att ge kunden en ögonblicksbild av vad som har dokumenterats.
6. Utgå från att kunden alltid vill veta mer
Ta inte risken att utgå från att kunden vet mer än vad hen faktiskt gör (och sedan få betala priset för det senare), utan utgå från att kunden alltid vill veta mer. För varje notering 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å varje sidtyp. Du kan bli överraskad av hur mycket du lär dig (eller inser att du behöver lära dig).
3 experttips för att skriva ett projektkravdokument
1. Skriv krav för globala element separat
För att eliminera överflödig information kan du samla alla globala element i ett avsnitt med rubriken ”Globala element” i din kravdokumentation. 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 notera dem på de andra sidorna; notera endast element som är specifika för dessa sidor.
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 din egen (och kundens) sinnesfrids skull. Du kommer att se detta oftast med vanliga sidelement som toppbilder eller bannerbilder, sidhuvuden eller ”tillbaka”-ikoner – bland många återkommande funktioner på olika sidtyper (som inte ska förväxlas med globala element).
3. Ta hänsyn till administrationsgränssnitt och CMS (eller avsaknaden av sådana)
När vi är så fokuserade 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 ska du se till att inkludera detta som en egen kolumn i dina krav. 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 kravdokument för projektet som definierar en funktions funktionalitet, placering, design med mera. Här är vår mall för kravdokument (du måste vara medlem för att få tillgång till den):
Öka tempot med över 100 premiummallar
Bli DPM-medlem för att få tillgång till ändlösa mallar skapade av experter som hjälper dig att arbeta snabbare och effektivare.
