Sådan organiserer du krav som forretningsanalytiker

Af: Charles Moore Charles Moore
Hours Opdateret

⚡ Smart opsummering

Organisering af forretningskrav som forretningsanalytiker forvandler rå interessentinput til en struktureret, prioriteret og tracEt brugbart dokument, som udviklere, testere og ledere hver især kan bruge i deres eget foretrukne format uden at miste fokus.

  • 📚 Definition: Et forretningskrav er et formelt dokument, der indfanger interessenternes behov for et projekt eller produkt i tilstrækkelig detaljer til at kunne diskuteres, analyseres og valideres.
  • ???? Ti-trins metode: Kategoriser, arranger, list, identificer, præsenter, brug indholdsfortegnelse, værktøj, fjern støj, tilknyt til proces og formater med tabeller og punkttegn.
  • 📈 Formater du kan bruge: Tabeller, regneark, arbejdsgangsdiagrammer, grafer, ER-modeller, prototyper og strukturerede sætningsskabeloner tæller alle som gyldige præsentationer.
  • 🛠️ Værktøjer BAs rækker ud efter: Jira med Confluence, Jama Connect, DØRE, Modern Requirements forum Azure DevOps, Miro, Lucidchart, Balsamiq, og Figma.
  • 🎯 Målgruppe først: Præsenter det samme krav forskelligt for ledere, udviklere og slutbrugere, så alle interessenter kan handle hurtigt på det.
  • ⚠️ Undgå fælderne: Blanding af hvad med hvordan, vag formulering, manglende tracevne, ingen prioritering og spring overping godkendelse forårsager det meste BRD-omarbejde.
Læs mere

Organiser krav som forretningsanalytiker

Et forretningskrav er et formelt dokument, der indfanger interessenternes behov for et projekt eller produkt. Der findes ikke et enkelt standardformat til præsentation af forretningskrav, men hver version bør dække produktet eller projektet i tilstrækkelig detaljer til at kunne diskuteres, analyseres, dokumenteres og valideres.

Et forretningskrav kan præsenteres på en af ​​følgende måder:

  • En tabel eller et regneark
  • Et diagram (arbejdsgang)
  • En graf
  • En model (entity-relationship diagram)
  • En prototype eller simulering
  • En struktureret sætning eller tekstskabelon

Hvordan man organiserer og præsenterer et forretningskrav

Nedenfor er trinnene til at skrive og organisere krav som en Business Analyst.

Trin 1) Kategoriser kravene.

  • Placer hvert krav i den kategori, det tilhører.
  • Tekniske interessenter bør se en kategori for tekniske krav, og ikke-tekniske interessenter bør se en kategori for forretningsmæssige eller generiske krav.
  • Hver organisation bør beslutte, hvilke kategorier der passer til dens egne standarder.
  • Kategorisering kan også være baseret på kravtype — funktionel versus forretningsmæssig — selvom denne opdeling ikke passer til alle projekter.

Trin 2) Arranger krav.
Saml og arranger krav i en logisk rækkefølge, så interessenter nemt kan navigere i dokumentet og finde manglende elementer.

Trin 3) Forbered en liste.
Udarbejd en gennemgangsliste over krav grupperet efter de interessenter, der skal godkende dem.

For eksempel vil en interessent med en teknisk baggrund kun interessere sig for det tekniske aspekt af produktet.

Trin 4) Brug unikke identifikatorer.
If trackrav til hinanden er vanskelige, brug unikke identifikatorer til at lave tracmuligheden lettere.

Trin 5) Præsenter kravene i interessentens foretrukne metode.
Du skal muligvis præsentere det samme krav i forskellige formater for forskellige interessenter – én foretrækker en grafisk visning, mens en anden foretrækker strukturerede sætninger.

Trin 6) Udarbejd en indholdsfortegnelse.
Lav en indholdsfortegnelse for alle krav. Det hjælper interessenterne track og find dem hurtigt.

Trin 7) Brug værktøjer til forretningsanalyse.
Brug Værktøjer til forretningsanalyse der hjælper med at præsentere og kategorisere krav ensartet på tværs af udgivelser.

Trin 8) Organiser kravdokumenter efter procesflow.
Fjern unødvendige krav fra dokumentet, og organiser de overlevende efter det procesflow, de understøtter.

Trin 9) Kortlæg kravene.
Knyt hvert krav, du indsamler, til et specifikt trin i procesflowet, så korrekturlæsere kan relatere kravet til den arbejdsgang, det understøtter.

Trin 10) Brug tabel- og punkttegn.
Brug tabeller til at præsentere komplekse krav og punktopstillinger til at fremhæve de vigtigste aspekter af hver enkelt.

Nyttige tips til at skrive og præsentere et forretningskravsdokument

For bedre præsentation og trackonge af forretningskrav, er følgende tips nyttige for enhver forretningsanalytiker (BA).

  • Kategorisering af krav er tidskrævende, så definer et standardsæt af kategorier, som forretningsudviklingsafdelinger, interessenter, fageksperter og tekniske teams kan genbruge på tværs af projekter i stedet for at opfinde nye hver gang.
  • Forbered hvert krav i konteksten af ​​dets målgruppe. Forstå de vigtigste aktører, influencers og beslutningstagere (interessenter, teknisk personale, udviklere osv.).
  • Definer et krav ad gangen. Hvert krav bør være atomare.
  • Undgå tvetydighed – brug ikke vage kvalifikationsord som "osv." eller "ca." i en kravformulering.
  • Referer ikke til et krav, der endnu ikke er defineret.
  • Fjern dubletter og modstridende udsagn fra dokumentet.
  • Opdel komplekse krav i mindre, håndterbare og gennemgåelige punkter.
  • Beskriv det systemet vil gøre det, ikke hvordan det vil gøre det — implementeringen hører hjemme i designfasen.

RELATEREDE ARTIKLER

Populære teknikker til at visualisere forretningskrav

En mur af prosa er den hurtigste måde at miste en interessent på. Forretningsanalytikere kombinerer alle tekstbaserede krav med en visuel fremstilling, så intentionen er klar med et enkelt blik. Følgende teknikker findes i BABOK-guiden og på tværs af de fleste forretningsanalytikerpraksisser.

  • Forretningsprocesmodel og -notation (BPMN): Diagrammerer forretningsprocesser fra start til slut med pools, baner, gateways og events. BPMN er ideel til at vise, hvem der gør hvad og hvornår.
  • Brugsscenariediagrammer og Descriptioner: Registrer interaktioner mellem aktører og systemer og de resultater, som hver aktør forventer. God til funktionsdrevne efterslæb.
  • Brugerhistorier med acceptkriterier: Korte "Som en ... Jeg ønsker ... så ..."-udsagn parret med Givet-Hvornår-Så-kriterier. Standardformatet i agile teams.
  • Wireframes og mockups: Lav- eller mediumkvalitetsskærme produceret i Figma, Balsamiq, eller Axure der gør UI-krav håndgribelige for ikke-tekniske interessenter.
  • Enhedsrelationsdiagrammer (ERD): Vis de dataenheder, som løsningen skal gemme, og relationerne mellem dem – afgørende for rapporterings- og integrationskrav.
  • Dataflowdiagrammer (DFD): Trachvordan data bevæger sig gennem processer, lagre og eksterne aktører, især i analyse- eller integrationsprojekter.

Tilpas teknikken til målgruppen: Ledere reagerer på proceskort og rejsediagrammer, udviklere reagerer på ERD'er og brugerhistorier, og slutbrugere reagerer på wireframes og prototyper.

Almindelige værktøjer til organisering af forretningskravsdokumenter

Når antallet af krav vokser over et par dusin, stopper et Word-dokument med at skalere. Forretningsanalytikere skifter til specialbyggede værktøjer, der understøtter baselinering, gennemgang, traceffektivitet og forandringskontrol. Følgende er de mest anvendte på tværs af branchen.

  • Jira med Confluence: Standardkombinationen for agile teams. Krav findes som episke historier og historier i Jira, bakket op af Confluence-sider, der indeholder BRD-fortællingen og diagrammerne.
  • Jama Connect: Virksomhedsplatform med fokus på kravstyring, baselining og live tractilgængelighed for regulerede industrier såsom medicinsk udstyr og luftfart.
  • IBM Engineering Requirements Ledelsens DØRE: Et veletableret værktøj, der anvendes i forsvar, bilindustrien og sikkerhedskritiske systemer, hvor alle krav skal opfyldes tracmulig.
  • Modern Requirements forum Azure DevOps: udvider Azure DevOps med gennemgang, godkendelse, baselining og BRD-eksport i Word-stil direkte fra arbejdselementer.
  • Miro or Lucidchart: Whiteboard- og diagramværktøjer, der bruges til at udarbejde BPMN, ERD'er, brugerrejser og workshopnotater, der senere indgår i det formelle BRD.
  • Balsamiq og Figma: Wireframe- og prototypeværktøjer, der holder UI-krav visuelle i stedet for tekstuelle.

Vælg værktøjssættet til projektets skala og revisionsbehov. Mindre projekter kan starte med Confluence og Jira, mens regulerede programmer normalt har brug for Jama eller DOORS for at opfylde traceffektivitetsrevisioner.

Almindelige fejl ved præsentation af forretningskrav

Selv et velunderbygget krav kan afvises, hvis det præsenteres dårligt. Følgende fejl optræder i de fleste BA-efterforskninger, og det er dem, man skal være på vagt over for under gennemgangen.

  • Bland hvad og hvordan: Slipping Implementeringsdetaljer i kravbeskrivelsen låser designteamet fast i en løsning, før analysen er færdig.
  • Tvetydig formulering: Ord som "hurtig", "brugervenlig" eller "fleksibel" kan ikke testes. Erstat dem med målbare acceptkriterier.
  • Ét format for alle interessenter: At præsentere det samme synspunkt for ledere, udviklere og slutbrugere behager normalt ingen af ​​dem. Tilpas formatet til målgruppen.
  • Manglende tracevne: Krav, der ikke er knyttet til forretningsmål, designelementer og testcases, kan ikke forsvares, når en ændringsanmodning modtages.
  • Ingen prioritering: At præsentere hundredvis af krav uden MoSCoW, vægtet scoring eller en lignende ramme tvinger interessenter til at diskutere omfang i stedet for værdi.
  • Overbelastede dokumenter: Ved at proppe alle diagrammer, logfiler og begrundelser ind i en enkelt PDF på 200 sider skjules de vigtige krav. Opdel BRD'en i logiske sektioner med en tydelig indholdsfortegnelse.
  • Springping afmelding: Præsentation af BRD'et uden et formelt godkendelsestrin åbner døren for scope creep og fingerpegning senere i leveringen.

RevVed at sammenligne BRD'en med denne liste før hver interessentmøde afdækkes de fleste af de problemer, der forårsager omarbejde i senere faser.

Ofte Stillede Spørgsmål

AI-værktøjer grupperer krav i grupper, markerer dubletter og modsigelser, genererer udkast til acceptkriterier og omsætter interessentinterviews til strukturerede brugerhistorier. Forretningsanalytikere validerer stadig alle genererede udsagn i forhold til forretningsmålet før godkendelse.

Copilot og GPT kan udarbejde et BRD-skelet, udvide brugerhistorier og generere førstegangsacceptkriterier ud fra mødenotater. RevIagttagere bekræfter stadig, at alle krav er testbare, utvetydige og kortlagt til en interessents behov, før dokumentet lægges som baseline.

En BRD (Broadway Reporting Report) indfanger forretningsbehov og mål, en FRD (Free Reporting Report) beskriver den funktionelle adfærd, som løsningen skal levere, og en SRS (Supply Reporting Report) er den udviklerrettede specifikation, der dækker funktionelle og ikke-funktionelle krav. Hvert dokument er rettet mod en forskellig målgruppe og et forskelligt detaljeringsniveau.

Almindelige rammer er MoSCoW (Must, Should, Could, Won't), vægtet scoring, Kano-analyse, forsinkelsesomkostninger og værdi versus indsatsmatricer. Interessenter og produktejere rangerer krav, så leveringsteamet altid arbejder på det element med den højeste værdi som det næste.

En RTM er et dokument, der forbinder hvert krav til dets oprindelse, designelement, kodekomponent og testcase. Det understøtter både fremadrettet og bagudrettet databehandling. tracbæredygtighed, beskyttelse af omfang under ændringsanmodninger og fremlæggelse af dokumentation under revisioner.

Der findes ikke ét værktøj, der er bedst. Agile teams bruger Jira med Confluence, regulerede programmer bruger Jama Connect eller IBM DØRE, og Microsoft butikker bruger Modern Requirements forum Azure DevOps. Vælg det værktøj, der matcher teamets størrelse, revisionsbehov og integrationskrav.

Agile teams præsenterer krav som episke historier, brugerhistorier og acceptkriterier i produktbackloggen. Produktafdelingen støtter produktejeren med forberedelse, forfining og Definition of Ready-gennemgange, så hver historie er lille, testbar og uafhængig, før sprintet starter.

Et velskrevet krav er atomært, testbart, tracanvendelig, utvetydig og prioriteret. Den angiver, hvad systemet skal gøre, ikke hvordan, og inkluderer målbare acceptkriterier, så udviklere og testere kan bekræfte levering uden tvetydighed.

Opsummer dette indlæg med: