Dokument för verksamhetskrav: en mall som innehåller 7 viktiga delar, med exempel

Varje projekt har rörliga delar, och om du vill ha ett framgångsrikt projektresultat måste alla dessa delar sammanföras vid rätt tidpunkt och på rätt plats. Tänk på att lägga ett pussel. Hemligheten bakom att lösa det är att titta på bilden på pusselns framsida medan du navigerar dig igenom det. 

Ett dokument för verksamhetskrav (BRD) är som bilden på pussellådan. Den beskriver allt ett projekt innebär och hjälper intressenter att få klarhet i kraven för att projektet ska lyckas. I den här artikeln tar vi upp de viktigaste delarna i en mall för kravdokument. Du kommer också att lära dig om fördelarna med att dela ditt BRD-dokument med hjälp av en onlineprogramvara. 

Vad är ett dokument för verksamhetskrav (BRD)?

Ett dokument för verksamhetskrav är ett resultat som beskriver allt som krävs för att ett nytt projekt ska lyckas. Dokumentet beskriver projektets mål, vad som förväntas under projektets livscykel och vad som krävs för att genomföra projektet. 

De sju delarna i ett kravdokument är:

1. Sammanfattning

2. Projektmål

3. Projektomfattning

4. Business-krav

5. Viktiga intressenter

6. Projektbegränsningar 

7. Kostnads-nyttoanalys

Genom att beskriva vart och ett av de här avsnitten bör alla som läser dokumentet med affärskrav tydligt förstå vad projektet går ut på, vad du vill uppnå och hur du planerar att uppnå det. 

Vad bör ett dokument för verksamhetskrav innehålla?

Din mall för kravdokumentet bör innehålla information om projektet, men den bör också vara kortfattad. Målet med dokumentet är att ge läsarna så mycket information som möjligt med så få ord som möjligt. 

Många människor kan läsa ett kravdokument, inklusive intressenter som är involverade i projektet, chefer som du behöver godkännanden från och kunder som påverkas av slutresultatet. Läs mer om varje komponent som ska ingå i din mall nedan.

1. Sammanfattning

Sammanfattningen är en översikt som beskriver vad projektet är och vad det syftar till. De som inte har tid att läsa hela kravdokumentet bör förstå vad du planerar att åstadkomma genom att läsa din sammanfattning. 

Även om sammanfattningen är det första i din kravdokumentation bör du faktiskt bara skriva den efter att du har skrivit de andra avsnitten. På så sätt kan du granska allt och se till att du har skapat en omfattande öppningsredogörelse. 

2. Projektmål

Projektmålen är de affärsmål du vill uppnå genom att genomföra projektet. Det är viktigt att ange projektmålen innan arbetet påbörjas, så att du kan använda dem för att mäta förloppet.

Ange projektmålen som smarta mål för att säkerställa att de är:

• Specifika

• Mätbart

• Accepterat (uppnåeligt)

• Relevanta

• Tidsbestämda

Att mäta projektmål kan hjälpa dig att avgöra om du behöver justera ditt arbetsflöde för att bättre uppfylla dina mål. Om ett av dina mål till exempel var att öka din kundbas med 10 % i slutet av kvartalet kan du titta på siffrorna när kvartalet är slut och tydligt se om du har uppnått målet eller inte. Du kan sedan titta på de åtgärder du har vidtagit längs vägen och fastställa orsakerna till att du kanske inte har nått målet.

3. Projektomfattning

Projektomfattningen anger projektets gränser i dokumentet med företagskrav. Genom att definiera projektomfattningen håller du alla informerade och förhindrar omfattningskrypning, vilket inträffar när projektet expanderar utanför de gränser du har satt upp och blir svårt att kontrollera. 

Detaljer som ska beskrivas i projektomfattningen inkluderar:

• Tidslinje

• Budget

• leveranser

• Projektkrav

• Projektteam

Du kan också göra en lista över projektundantag, det vill säga saker som du specifikt vill utesluta från projektet, till exempel affärsprocesser eller riskfyllda strategier som du vill att andra ska undvika när de arbetar med projektet. 

4. Business-krav

Business-kraven är kärnan i din BRD-mall. I det här avsnittet listar du de åtgärder som krävs för att genomföra projektet. Beroende på projektets komplexitet kan listan bestå av bara några punkter eller vara omfattande. 

Förutom att lista och beskriva kraven bör du rangordna dem efter prioritet och tilldela varje punkt en betydelsenivå baserat på hur kritiska de är. Det hjälper andra att förstå vilka krav som behöver slutföras först. 

Om ett av kraven är att koda en webbplats kan du tilldela den här uppgiften högsta prioritet. Du kan också märka den här uppgiften som mycket kritisk eftersom du inte har någon grund för att slutföra andra Business-krav om du inte kodar din webbplats. 

5. Viktiga intressenter

Projektets intressenter är alla personer som är involverade i projektet. Det är troligen de som kommer att läsa din mall för kravdokumentation för att förstå vad projektet handlar om. Dina viktigaste intressenter kan vara:

• Teammedlemmar som arbetar med projektet.

• Projektledare som leder projektet.

• Chefer som godkänner projektet.

• Kunder som påverkas av det färdiga projektet.

I det här avsnittet listar du namnen och arbetsrollerna för varje intressent och beskriver deras roll i förhållande till projektet. Det här avsnittet ger alla klarhet om vem som är involverad och hur det kan förbättra teamkommunikationen. För formella samarbeten kan en mall för partnerskapsavtal hjälpa till att dokumentera roller, ansvar och förväntningar så att alla intressenter är på samma sida när de går med i projektet.

När du har identifierat intressenter är det lika viktigt att bygga en stark arbetsrelation. En mall för en introduktionsprocess för kunder kan hjälpa dig att standardisera stegen i en kickoff, förtydliga ansvarsområden och stärka förtroendet i ett tidigt skede.

6. Projektbegränsningar

Du har förmodligen redan presenterat en översikt över projektbegränsningarna i projektomfattningen, men här förklarar du gränserna mer i detalj. När läsaren granskar det här avsnittet bör hen se projektets form och dess begränsningar.

Projektbegränsningar kan vara:

• Projektrisker

• Teamets tillgänglighet

• resurser

• Projektberoenden.

• Deadliner

• Projektbudget

Projektbegränsningar hjälper intressenter att visualisera projektets komplexitet och hur lätt det kommer att bli att uppnå projektmålen. Alla som är involverade i projektet bör först granska projektbegränsningarna.

7. Kostnads-nyttoanalys

Att avsluta dokumentet för verksamhetskrav med en kostnads-nyttoanalys är ett strategiskt drag. Om du använder dokumentet för att få projektet godkänt kan det här avsnittet vara den avgörande faktorn. Kunder och chefer bryr sig om projektets mål, men om du inte kan bevisa att du kommer att gå med vinst är allt förlorat. 

Så här skapar du en kostnads-nyttoanalys:

• Beskriv alla kostnader som är förknippade med projektet.

• Förklara de fördelar som är förknippade med projektet.

• Skriv ner den totala förväntade kostnaden för projektet.

• Beräkna den förväntade avkastningen på investeringen (ROI) genom att dra av de beräknade kostnaderna från de beräknade intäkterna.

Dokument för verksamhetskrav: en mall (och exempel)

Här är ett exempel på en mall för ett dokument för verksamhetskrav. Det här exemplet är för ett teknikföretags initiativ att starta en marknadsföringsblogg. I dokumentet förklarar projektledaren vad projektet är och vad det syftar till. Hon beskriver också projektmålen och projektomfattningen för att undvika omfattningskrypning. 

I dokumentet listar projektledaren även verksamhetskraven – de åtgärder som behövs för att slutföra projektet. Andra punkter som listas är de intressenter som är involverade i projektet, projektbegränsningarna och kostnads-nyttoanalysen.

Om du vill använda en mall för kravdokument för ditt eget projekt kan du använda vår kostnadsfria mall nedan.

Vad är skillnaden mellan Business-krav och funktionella krav?

Funktionella krav dyker ofta upp när man diskuterar business-krav, men det är viktigt att veta skillnaden mellan de två. Ett dokument för verksamhetskrav beskriver vad dina projektkrav är. Det här dokumentet ger en översikt på hög nivå och ger intressenter en övergripande bild av projektet som helhet. 

Ett dokument för funktionskrav (FRD) ger en detaljerad beskrivning av hur specifika uppgifter ska utföras inom projektet. Tänk på de här dokumenten som ett brädspel: BRD är lådan som förklarar spelet och övertygar dig om att köpa det. FRD är å andra sidan instruktionerna som lär dig hur man spelar spelet. 

Förutom funktionella krav finns det:

• Användarkrav: De här kraven är mer detaljerade än BRD och förklarar vad användaren kan göra med de färdiga leveranserna.

• produktkrav: De här kraven är mer detaljerade än både Business- och användarkrav. Produktkrav förklarar det färdiga projektets syfte och funktioner. Det här dokumentet fungerar som en guide för team när de bygger och marknadsför sin produkt.

• Icke-funktionella krav: De här kraven är den mest detaljerade typen av krav, lika detaljerade som funktionella krav. De förklarar hur projektet ska fungera och det färdiga projektets avsedda användarupplevelse.

Dela krav med hjälp av projekthanteringsverktyg

Oavsett om du skapar ett dokument för verksamhetskrav eller något mer detaljerat, är det bästa sättet att dela information med intressenter genom ett effektivt verktyg. 

Med projekthanteringsverktyg kan du prioritera affärsmål och se till att inget glöms bort. Använd Asana för att effektivisera teamkommunikationen och göra det enklare att nå projektmilstolpar.