Achtergrond van de vraag:
Complexe vereisten worden vaak geformuleerd op een hoog abstractieniveau of bevatten meerdere verborgen voorwaarden en uitzonderingen. Als dergelijke vereisten niet worden gedecomprimeerd en verduidelijkt, kunnen er misinterpretaties ontstaan tussen de klant, ontwikkelaars en testers.
Probleem:
Ambigue of onvoldoende gedetailleerde vereisten leiden ertoe dat het team zelf details moet invullen. Als gevolg hiervan wordt de bedrijfswaarde mogelijk niet gerealiseerd of vervormd, en wordt het veel moeilijker en kostbaarder om dit te corrigeren.
Oplossing:
De systeemanalist voert een gedetailleerde analyse van de vereisten uit met behulp van decompositie technieken (Use Case Diagram, Activiteit Diagram, User Stories volgens INVEST, Event Storming, decomposition tree). Het is belangrijk om scenario's te vormen (basis/alternatieve/exclusieve stromen), beslissings tabellen en overgangsmatrices te bouwen, en uiteindelijk elk "knoop" te verifiëren met voorbeelden van edge cases samen met de klant. Na de decompositie verzamelt de analist alle delen, analyseert de integratiepunten en zorgt voor consistentie.
Belangrijke kenmerken:
Is een tekstuele beschrijving van een User Story voldoende?
Nee, alleen user stories zijn niet genoeg: diagrammen van sequenties (sequence diagrams), voorbeelden van edge cases, UI mockups en beslissings tabellen zijn nodig voor complexe bedrijfslogica.
Zorgt decompositie automatisch voor gebrek aan tegenstrijdigheden tussen de vereisten?
Nee, decompositie moet gepaard gaan met de consolidatie van conflicterende vereisten, regelmatige review-sessies en analyse van afhankelijkheden.
Kan de decompositie uitsluitend worden toevertrouwd aan ontwikkelaars of testers?
Nee, de analist is verantwoordelijk voor de volledigheid van de detailering. Als dit aan andere rollen wordt gegeven, ontstaan er verschillende interpretaties en inconsistenties.
Negatieve case:
De zakelijke klant schreef "Het systeem moet de korting voor elke klant individueel berekenen". In de ontwikkeling werd er een rigide kortingssysteem gerealiseerd. Tijdens de tests bleek dat er meer dan een dozijn verborgen parameters waren, die niet tijdens de formalisatiefase waren vastgesteld.
Voordelen:
Nadelen:
Positieve case:
De analist organiseerde een workshop over Event Storming, ontdekte alle parameters en voorwaarden voor de berekening. Hij bouwde een decision table en sequence diagrams, en stemde voorbeelden van edge cases af met het bedrijf. De vereiste werd duidelijk en verifieerbaar, fouten werden ontdekt voordat de ontwikkeling begon.
Voordelen:
Nadelen: