Antwoord.

Geschiedenis van de vraag:

Met de groei van de schaal en complexiteit van IT-projecten deed zich herhaaldelijk de situatie voor waarin de vereisten van de business klant binnenkwamen als abstracte wensen, die bij overdracht aan het ontwikkelingsteam veranderen in iets anders. De oorzaak is de kloof in terminologie, verwachtingen en abstractieniveau tussen business en IT.

Probleem:

Als de decompositie niet goed wordt doordacht, worden de vereisten ofwel onvolledig (kritische details ontbreken), ofwel overdreven vaag (niet te evalueren en te realiseren), of ze worden helemaal vervormd door lexicale valkuilen, ongebruikte terminologie en misverstanden.

Oplossing:

De systeemanalist decomprimeert systematisch elke vereiste: hij formaliseert business-termen, vertaalt business-doelen naar functies en taken, beschrijft gebruikersscenario's en systeemgedrag, en koppelt aan acceptatiecriteria/testcases. Het is belangrijk om modellen (UML, BPMN), glossaria, checklists en directe reviews tussen teams te gebruiken.

Kernkenmerken:

Het opstellen van een glossarium van termen samen met de klant
Het gebruik van diagrammen en atomische formuleringen van vereisten
Het vertalen van vereisten naar de taal van acceptatiecriteria en testcases

Vragen met een valkuil.

Kan het business wensformulier in vrije vorm worden gelaten met verdere aanpassing in de ontwikkelingsfase?

Nee, er is een hoog risico op miscommunicatie en uitvoeringsfouten.

Moet men tot de detail van de uitvoering (bijv. hoe gegevens worden opgeslagen) tijdens de analysetfase komen?

Nee, analyse gaat over "wat" en "waarom", en niet over "hoe". Technische details zijn de verantwoordelijkheid van architectuur en ontwikkeling.

Is één registratie van een vereiste altijd gelijk aan één module/functie?

Nee, vaak is decompositie nodig — grote vereisten worden opgesplitst in sub-functies en user stories met afzonderlijke acceptatiecriteria.

Typische fouten en anti-patronen

Vermenging van business-taal en technische termen zonder glossarium
Het beschrijven van vereisten in de vorm van "vage wensen"
Schending van atomariteit — één vereiste bevat veel verschillende entiteiten

Voorbeeld uit het leven

Negatieve case: De klant gaf een lijst met wensen door "De gebruiker moet alle verkoopanalyses kunnen zien", die onveranderd in de specificatie werd gekopieerd.

Voordelen:

Snelheid van documentatievoorbereiding

Nadelen:

Onzeker welke specifieke metrics en in welke opzicht deze nodig zijn
Voortdurende aanpassingen

Positieve case: De analist vroeg de klant, stelde een lijst op met noodzakelijke metrics, bepaalde de rollen van gebruikers, ontwikkelde prototypes van rapporten en stemde het glossarium van termen af.