Hoe u vereisten organiseert als bedrijfsanalist

Een bedrijfsvereiste is een formeel document dat ingaat op de behoefte van de belanghebbenden aan het project of product. Er bestaat geen standaardformaat of sjabloon om de zakelijke vereisten weer te geven. De product- of projectbeschrijving moet echter voldoende gedetailleerd zijn om te kunnen bespreken, analyseren, documenteren en valideren.

Een zakelijke vereiste kan in elk van de onderstaande documenten worden gepresenteerdwing manieren:

  • Een tabel of een spreadsheet
  • Een diagram (workflow)
  • Een grafiek
  • Een model (entiteit-relatiediagram)
  • Een prototype of simulatie
  • Een gestructureerde zin of tekstsjabloon

Hoe u een bedrijfsvereiste kunt organiseren en presenteren

Hieronder vindt u de stappen om vereisten te schrijven en te organiseren als een Bedrijfsanalist.

Stap 1) Categoriseer de vereisten.

  • Stel specifieke eisen aan de relevante categorieën.
  • Voor technische belanghebbenden moet er een technische vereistencategorie zijn, voor niet-technische belanghebbenden moet er een generieke vereistencategorie zijn.
  • Elke organisatie moet uitzoeken welke categorie bij hun normen past.
  • Categorisatie kan ook plaatsvinden op basis van hun typen (functioneel versus zakelijk). Hoewel dit niet in alle gevallen van toepassing is.

Stap 2) Regel eisen.
Verzamel en rangschik vereisten in een logische volgorde. Dus wanneer belanghebbenden de vereisten beoordelen, is het gemakkelijk om te navigeren en ook ontbrekende items te identificeren.

Stap 3) Maak een lijst.
Maak een lijst van de vereisten die door specifieke belanghebbenden moeten worden beoordeeld.

Als een stakeholder bijvoorbeeld een technische achtergrond heeft, wil hij alleen het technische aspect van het product weten.

Stap 4) Gebruik unieke identificatiegegevens.
Als het moeilijk is om de vereisten naar elkaar te traceren, gebruik dan unieke identificatiegegevens, wat de traceerbaarheid vergemakkelijkt.

Stap 5) Huidige vereiste in de voorkeursmethode van belanghebbenden
In bepaalde scenario's moet u mogelijk dezelfde eis op verschillende manieren presenteren aan verschillende belanghebbenden. Zo geeft de ene stakeholder de voorkeur aan een grafisch format, terwijl de ander de voorkeur geeft aan een gestructureerd zinsformat.

Stap 6) Maak een inhoudsopgave.
Maak een inhoudsopgave voor alle vereisten. Het helpt belanghebbenden om eenvoudig de vereisten te volgen.

Stap 7) Gebruik tools voor bedrijfsanalyse.
Hulpmiddelen voor bedrijfsanalyse die helpen bij het presenteren en categoriseren van de vereisten

Stap 8) Organiseer de vereiste documenten op processtroom.
Verwijder in uw vereistendocument alle onnodige vereisten en organiseer de vereistedocumenten op processtroom.

Stap 9) Breng de eisen in kaart.
Breng de vereisten die u heeft verzameld in kaart voor een bepaalde stap in een processtroom, en dit zal reviewers helpen om vereisten te relateren aan de processtroom.

Stap 10) Gebruik tabel- en opsommingstekens.
Gebruik een tabel voor het presenteren van complex vereisten. Gebruik opsommingstekens om het belangrijkste aspect van de vereiste te benadrukken.

Handige tips voor het schrijven en presenteren van een document met zakelijke vereisten

Voor een betere presentatie en tracking van de zakelijke vereisten voor belanghebbenden volgen hier enkele tips die nuttig kunnen zijn voor BA (Business Analyst).

  • Het categoriseren van vereisten is tijdrovend en het is mogelijk niet voor elke organisatie haalbaar om elke keer een nieuwe categorie te creëren. Voor beste praktijken wordt aanbevolen dat er een standaardreeks categorieën is die algemeen kunnen worden gebruikt door BA's, belanghebbenden, vakdeskundigen en technische teams.
  • Uw vereiste moet worden voorbereid in de context van uw publiek. Begrijp wie de belangrijkste spelers, beïnvloeders en besluitvormers zijn. (Belanghebbenden, technisch personeel, ontwikkelaars, etc.)
  • Definieer één vereiste tegelijk. Elke eis zou dat moeten zijn atomic.
  • Vermijd dubbelzinnigheid door acroniemen zoals etc., approx., enzovoort te vermijden.
  • Verwijs niet naar een vereiste die nog moet worden gedefinieerd.
  • Vermijd dubbele en tegenstrijdige verklaringen.
  • Breek complex vereiste in beheersbare en controleerbare punten.
  • Vermijd te beschrijven hoe het systeem iets zal doen. Vermeld alleen wat het systeem zal doen.