Mall för dokument för verksamhetskrav + gratis PDF

Varje projekt har rörliga delar, och om du vill ha ett framgångsrikt projektresultat måste alla dessa delar komma samman 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å framsidan av lådan medan du arbetar dig igenom det.

Ett dokument för verksamhetskrav (BRD) är som bilden på pusselboxen. Det beskriver allt som ett projekt innebär och ger intressenterna klarhet om kraven för att projektet ska lyckas. I den här artikeln tar vi upp de viktigaste delarna i en mall för ett dokument för verksamhetskrav, förklarar skillnaden mellan verksamhetskrav och funktionella krav och visar dig hur du skriver ett effektivt BRD för ditt nästa projekt.

Vad är ett Business Requirements Document (BRD)?

Ett Business Requirements Document (BRD) är en formell rapport som beskriver ett projekts mål, omfattning och krav för att samordna intressenterna och leda till en framgångsrik leverans. Den beskriver projektmål, förväntningar under hela projektets livscykel och vad som krävs för att genomföra projektet.

De sju delarna i ett BRD är:

1. Sammanfattning

2. Projektavsikter

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 ditt dokument för verksamhetskrav tydligt förstå vad ditt projekt är, vad du vill uppnå och hur du planerar att uppnå det.

Varför använda en mall för dokument för verksamhetskrav?

En mall för dokument för verksamhetskrav ger dig en konsekvent struktur för varje projekt, så att du aldrig missar viktig information. Här är anledningen till att team förlitar sig på dem:

• Samordning med intressenter: Definiera projektets gränser och mål i förväg för att hålla alla fokuserade på samma mål.

• Omfattningskontroll: En tydlig mall hjälper till att förebygga omfattningskrypning genom att redan från början dokumentera vad som ingår i projektet och vad som inte ingår, och den stöder en formell process för förändringskontroll.

• Tidsbesparingar: I stället för att börja från början har du en beprövad struktur som vägleder dig genom processen.

• Snabbare godkännanden: När chefer och kunder granskar ett välstrukturerat dokument blir det lättare att få stöd för dina projektplaner.

Vad bör ett Business-kravdokument innehålla?

Din mall för Business Requirements Document bör vara detaljerad men ändå koncis. Målet är att ge läsarna den information de behöver utan onödig text.

Många personer kan läsa ett BRD, inklusive projektintressenter, chefer som du behöver godkännanden från och kunder som påverkas av slutresultaten. Läs mer om varje del som bör ingå i din mall nedan.

1. Sammanfattning

Sammanfattningen är en övergripande beskrivning av vad ditt projekt är och dess syfte. De som inte har tid att läsa hela BRD:n ska kunna förstå vad du planerar att uppnå genom att läsa din sammanfattning.

Även om din sammanfattning är det första i din BRD bör du egentligen 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 heltäckande inledning.

2. Projektavsikter

Dina projektavsikter är de Business-mål du vill uppnå genom att genomföra ditt projekt. Det är viktigt att ange projektmålen innan du påbörjar något arbete, så att du kan använda dem för att mäta förlopp.

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

• Specifika

• Mätbara

• Accepterat (uppnåeligt)

• Relevanta

• Tidsbestämda

Att mäta projektmålen hjälper dig att avgöra om du ska justera arbetsflödet. Om ditt mål till exempel var att öka din kundbas med 10 % i slutet av kvartalet, kan du tydligt se om du har uppnått det målet. Gå sedan igenom de åtgärder du vidtog för att förstå vad som fungerade och vad som inte fungerade.

3. Projektomfattning

Din projektomfattning anger gränserna för ditt projekt i ditt Business-kravdokument. Genom att definiera projektomfattningen i en omfattningshanteringsplan håller du alla informerade och förhindrar omfattningskrypning, vilket inträffar när projektet expanderar utanför de gränser du har satt för det och blir svårt att kontrollera.

Följande detaljer bör ingå i beskrivningen av projektomfattningen:

• Tidslinje

• Budget

• Leveranser

• Projektkrav

• Projektteam

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

4. Business-krav

Business-kraven är den viktigaste delen av 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 dina krav och beskriva dem ska du rangordna dem efter prioritet och tilldela varje punkt en prioritetsnivå baserat på hur kritisk den är. Det hjälper andra att förstå vilka krav de behöver slutföra först.

Om ett av dina krav är att koda en webbplats kan du göra det till din högsta prioritet. Du kan också märka den här uppgiften som mycket kritisk eftersom du, utan att koda din webbplats, inte har någon grund för att slutföra andra business-krav.

5. Viktiga intressenter

Projektets intressenter är alla personer som har ett intresse i projektet. Det är sannolikt de som kommer att läsa din BRD-mall 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 namn, roller och ansvarsområden för varje intressent i förhållande till projektet.

För formella samarbeten kan en mall för samarbetsavtal hjälpa till att dokumentera roller och förväntningar. Du kan också använda en plan för intressentengagemang för att säkerställa att alla intressenter är i linje med projektet.

När du väl har identifierat intressenterna är det lika viktigt att skapa en stark arbetsrelation. En mall för kundintroduktionsprocessen kan hjälpa dig att standardisera kickoff-stegen, klargöra ansvarsområden och stärka förtroendet i ett tidigt skede.

6. Projektbegränsningar

Du presenterade förmodligen en översikt över projektbegränsningarna i projektomfattningen, men här kommer du att förklara dessa begränsningar 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 omfatta följande:

• Projektets risker

• Teamets tillgänglighet

• Resurser

• Projektberoenden

• Deadliner

• Projektbudget

Projektbegränsningar hjälper intressenterna att visualisera projektets komplexitet och hur lätt det blir att uppnå projektmålen. Alla som är involverade i projektet bör först gå igenom projektbegränsningarna.

7. Kostnads-nyttoanalys

Att avsluta ditt Business Requirements Document med en kostnads-nyttoanalys är ett strategiskt drag. Om du använder ditt BRD 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öra vinst är allt förlorat.

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

• Beskriv alla kostnader som är förknippade med ditt projekt

• Förklara de tillhörande fördelarna

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

• Beräkna den förväntade avkastningen på investering genom att dra av dina beräknade kostnader från din beräknade inkomst

Vad är skillnaden mellan Business Requirements och Functional Requirements?

Du kommer ofta att höra funktionskrav nämnas när man diskuterar business-krav, men det är viktigt att veta skillnaden. Tänk på det som ett brädspel: BRD är lådan som förklarar vad spelet är, medan FRD är instruktionsboken som lär dig hur du spelar.

Förutom funktionskrav finns det:

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

• Produktkrav: Dessa krav är mer detaljerade än både Business- och användarkrav. Produktkraven förklarar det färdiga projektets syfte och funktioner.

• Icke-funktionella krav: Dessa krav är lika detaljerade som funktionella krav. De förklarar hur projektet ska fungera och den avsedda användarupplevelsen av det färdiga projektet.

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

Nedan följer ett exempel på en mall för ett dokument för verksamhetskrav för ett teknikföretag som lanserar en marknadsföringsblogg. Projektledaren förklarar projektets syfte, mål och omfattning för att förebygga omfattningskrypning.

I BRD listas även Business-kraven (de åtgärder som behövs för att slutföra projektet), de berörda intressenterna, projektbegränsningarna och kostnads-nyttoanalysen.

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

Så här skriver man ett Business Requirements-dokument

Att skriva ett Business Requirements-dokument är en enkel process när du delar upp den i steg. Det viktigaste är att vara tydlig och noggrann och se till att vem som helst kan förstå projektets syfte och krav.

Följ de här stegen för att skapa ditt BRD:

• Samla in synpunkter: Prata med alla viktiga intressenter för att förstå deras behov och förväntningar. Det säkerställer att alla perspektiv beaktas innan du börjar skriva.

• Skriv ett utkast till varje avsnitt: Använd din mall för att fylla i var och en av de sju delarna. Börja med det du vet och fyll i detaljerna under tiden. Kom ihåg att skriva sammanfattningen sist.

• Håll det tydligt och kortfattat: Skriv i klartext som alla kan förstå. Undvik fackjargong och fokusera på det som är viktigast för att projektet ska bli framgångsrikt.

• Granska och förfina: Dela utkastet med ditt team och intressenterna för att få feedback. Det hjälper till att upptäcka eventuella luckor eller oklara punkter och säkerställer att alla är överens.

• Få godkännanden: När alla är överens om dokumentet ska du få ett formellt godkännande från projektsponsorn eller ledande befattningshavare. Ditt BRD är nu den officiella guiden för projektet.

Hantera dina krav med projekthanteringsverktyg

Oavsett om du skapar ett Business Requirements-dokument eller något mer detaljerat är det bästa sättet att dela information med intressenter att använda ett enda effektivt verktyg.

Med projekthanteringsverktyg och effektiva metoder för kravhantering kan du prioritera affärsmål och se till att inget glöms bort. Använd Asana för att effektivisera kommunikationen i teamet, hålla dina krav organiserade och göra det lättare att nå projektets milstolpar. Kom igång med Asana i dag och skapa klarhet i ditt nästa projekt.

Vanliga frågor om Business Requirements Document