Hur man organiserar krav som affärsanalytiker

Ett affärskrav är ett formellt dokument som fångar intressenternas behov för ett projekt eller en produkt. Det finns inget enda standardformat för att presentera affärskrav, men varje version bör täcka produkten eller projektet tillräckligt detaljerat för att kunna diskuteras, analyseras, dokumenteras och valideras.

Ett affärskrav kan presenteras på något av följande sätt:

• En tabell eller ett kalkylblad
• Ett diagram (arbetsflöde)
• En graf
• En modell (entity-relationship diagram)
• En prototyp eller simulering
• En strukturerad mening eller textmall

Hur man organiserar och presenterar ett affärsbehov

Nedan följer stegen för att skriva och organisera krav som en Affärsanalytiker.

Steg 1) Kategorisera kraven.

• Placera varje krav i den kategori det tillhör.
• Tekniska intressenter bör se en kategori för tekniska krav, och icke-tekniska intressenter bör se en kategori för affärskrav eller generella krav.
• Varje organisation bör avgöra vilka kategorier som passar deras egna standarder.
• Kategorisering kan också baseras på kravtyp – funktionell kontra affärsmässig – även om denna uppdelning inte passar alla projekt.

Steg 2) Ordna krav.
Samla och ordna krav i en logisk ordning så att intressenter enkelt kan navigera i dokumentet och upptäcka saknade punkter.

Steg 3) Förbered en lista.
Förbered en lista över översiktliga krav grupperade efter de intressenter som behöver godkänna dem.

Till exempel kommer en intressent med teknisk bakgrund bara att bry sig om den tekniska aspekten av produkten.

Steg 4) Använd unika identifierare.
If trackrav till varandra är svårt, använd unika identifierare för att göra tracförmågan enklare.

Steg 5) Presentera kraven med intressentens föredragna metod.
Du kan behöva presentera samma krav i olika format för olika intressenter – en föredrar en grafisk vy, medan en annan föredrar strukturerade meningar.

Steg 6) Förbered en innehållsförteckning.
Skapa en innehållsförteckning för alla krav. Det hjälper intressenterna track och hitta dem snabbt.

Steg 7) Använd verktyg för affärsanalys.
Använda Verktyg för affärsanalys som hjälper till att presentera och kategorisera krav konsekvent över olika versioner.

Steg 8) Organisera kravdokument efter processflöde.
Ta bort onödiga krav från dokumentet och organisera de överlevande efter det processflöde de stöder.

Steg 9) Kartlägg kraven.
Mappa varje krav du samlar in till ett specifikt steg i processflödet så att granskare kan relatera kravet till det arbetsflöde det stöder.

Steg 10) Använd tabell och punktpunkter.
Använd tabeller för att presentera komplexa krav och punktlistor för att lyfta fram de viktigaste aspekterna av varje krav.

Användbara tips för att skriva och presentera ett affärskravdokument

För bättre presentation och trackungen av affärskrav, följande tips är användbara för alla affärsanalytiker (BA).

• Att kategorisera krav är tidskrävande, så definiera en standarduppsättning kategorier som affärsområdesansvariga, intressenter, ämnesexperter och tekniska team kan återanvända i olika projekt istället för att uppfinna nya varje gång.
• Förbered varje krav i kontexten för dess målgrupp. Förstå de viktigaste aktörerna, påverkarna och beslutsfattarna (intressenter, teknisk personal, utvecklare och så vidare).
• Definiera ett krav i taget. Varje krav bör vara atomärt.
• Undvik tvetydighet – använd inte vaga villkor som ”etc.” eller ”ungefär” i en kravspecifikation.
• Referera inte till ett krav som ännu inte har definierats.
• Ta bort dubbletter och motsägelsefulla påståenden från dokumentet.
• Dela upp komplexa krav i mindre, hanterbara och granskningsbara punkter.
• Beskriv vad systemet kommer att göra det, inte hur det kommer att göra det — implementeringen hör hemma i designfasen.

Populära tekniker för att visualisera affärskrav

En vägg av prosa är det snabbaste sättet att förlora en intressent. Affärsanalytiker parar ihop varje textbaserat krav med en visuell text så att avsikten är tydlig vid en överblick. Följande tekniker finns i BABOK-guiden och i de flesta affärsanalysmetoder för företag.

• Affärsprocessmodell och notation (BPMN): Diagrammerar heltäckande affärsprocesser med pooler, lanes, gateways och händelser. BPMN är idealiskt för att visa vem som gör vad och när.
• Användningsfallsdiagram och Descriptjoner: Registrera interaktioner mellan aktörer och system och de resultat som varje aktör förväntar sig. Bra för funktionsdrivna eftersläpningar.
• Användarberättelser med acceptanskriterier: Korta ”Som en … jag vill … så att …”-satser parade med Givet-När-Sedan-kriterier. Standardformatet i agila team.
• Trådramar och mockups: Skärmar med låg eller medelhög kvalitet producerade i Figma, Balsamiq, eller Axure som gör UI-krav konkreta för icke-tekniska intressenter.
• Entitetsrelationsdiagram (ERD): Visa de dataenheter som lösningen måste lagra och relationerna mellan dem – avgörande för rapporterings- och integrationskrav.
• Dataflödesdiagram (DFD): Trachur data rör sig genom processer, butiker och externa aktörer, särskilt i analys- eller integrationsprojekt.

Matcha tekniken med målgruppen: chefer svarar på processkartor och resediagram, utvecklare svarar på ERD:er och användarberättelser, och slutanvändare svarar på wireframes och prototyper.

Vanliga verktyg för att organisera affärskravdokument

När antalet krav överstiger ett par dussin slutar ett Word-dokument att skalas. Affärsanalytiker går över till specialbyggda verktyg som stöder baslinjeberäkning, granskning, traceffektivitet och förändringskontroll. Följande är de mest använda inom branschen.

• Jira med konfluens: Standardkombinationen för agila team. Kraven finns som episka berättelser och berättelser i Jira, med stöd av Confluence-sidor som innehåller BRD-berättelsen och diagrammen.
• Jama Connect: Företagsplattform fokuserad på kravhantering, baseline och live tracförmåga för reglerade industrier som medicinteknik och flyg- och rymdteknik.
• IBM Engineering Requirements Ledningsdörrar: Långt etablerat verktyg som används inom försvar, fordon och säkerhetskritiska system där alla krav måste uppfyllas tracmöjlig.
• Modern Requirements för Azure DevOps: förlänger Azure DevOps med granskning, signering, baselining och BRD-export i Word-stil direkt från arbetsuppgifter.
• Miro or Lucidchart: Whiteboard- och diagramverktyg som används för att utarbeta BPMN, ERD:er, användarresor och workshopanteckningar som senare ligger till grund för det formella BRD:et.
• Balsamiq och Figma: Wireframe- och prototypverktyg som håller UI-kraven visuella istället för textuella.

Välj verktygsuppsättningen för projektets skala och revisionsbehov. Mindre projekt kan börja med Confluence och Jira, medan reglerade program vanligtvis behöver Jama eller DOORS för att uppfylla kraven. trachållbarhetsrevisioner.

Vanliga misstag vid presentation av affärskrav

Även ett väl underbyggt krav kan avvisas om det presenteras dåligt. Följande misstag förekommer i de flesta eftergranskningar av BA och är de man bör vara försiktig med vid granskning.

• Blanda vad och hur: Slipping Implementeringsdetaljer i kravbeskrivningen låser designteamet till en lösning innan analysen är klar.
• Tvetydig formulering: Ord som ”snabb”, ”användarvänlig” eller ”flexibel” är inte testbara. Ersätt dem med mätbara acceptanskriterier.
• Ett format för alla intressenter: Att presentera samma synsätt för chefer, utvecklare och slutanvändare brukar vanligtvis inte tilltala någon av dem. Anpassa formatet efter målgruppen.
• Saknas tracförmåga: Krav som inte är kopplade till affärsmål, designelement och testfall kan inte försvaras när en ändringsförfrågan kommer in.
• Ingen prioritering: Att presentera hundratals krav utan MoSCoW, viktad poängsättning eller liknande ramverk tvingar intressenter att diskutera omfattning istället för värde.
• Överbelastade dokument: Att klämma in varje diagram, logg och motivering i en enda 200-sidig PDF döljer de viktiga kraven. Dela upp BRD:en i logiska avsnitt med en tydlig innehållsförteckning.
• Hoppaping avregistrering: Att presentera BRD utan ett formellt godkännandesteg öppnar dörren för krypande av omfattningen och fingerpekning senare i leveransen.

RevAtt jämföra BRD mot denna lista före varje intressentmöte fångar upp de flesta problem som orsakar omarbete i senare faser.

Vanliga frågor