Marco Balvers

Kent u ze ook? De klassieke ‘functionele ontwerpen’ of ‘programma’s van eisen’? Lijvige documenten waarin de requirements van vaak complexe IT-systemen allesomvattend zijn beschreven? Documenten waarin alles door elkaar staat, van high level eisen tot de beschrijving van de werking van specifieke systeemonderdelen?

Een culinair diner bestaat vaak uit meerdere gangen van gerechten. Daarbij komen verschillende smaken bij elkaar op een mooi opgemaakte bord. Wanneer de chef alle ingrediënten van alle gerechten in één pan had bereid, dan zouden de meeste klanten het eten waarschijnlijk laten staan!

Zo is het ook met requirements! Een goede set bestaat uit verschillende soorten requirements. Wanneer alle requirements in één document bij elkaar staan ontstaat er een brij die geen van de stakeholders optimaal zal smaken. De oplossing voor dit probleem is gelukkig verrassend eenvoudig:

Benader uw requirements als een chef!

In het artikel Een goede analist moet keuzes durven maken schreven we over de analist als documentalist. Analisten krijgen steeds vaker de vraag om informatie vast te leggen omdat ze de juiste eigenschappen zouden hebben om informatie te ordenen en te modelleren.

Op zulke momenten is het als analist verleidelijk om alle informatie in één document vast te leggen. Requirements, user interface, technische oplossingen, architectuurkeuzes, alles bij elkaar. Net zoals bij een eenpansmaaltijd.

Dat lijkt op het eerste gezicht praktisch en makkelijk te beheren. Maar niet alle stakeholders hebben op hetzelfde moment behoefte aan dezelfde informatie. En de informatie die wel nodig is verdrinkt vaak in de massa en wordt niet meer gelezen.

De oplossing voor dit probleem is zoals gezegd verrassend eenvoudig: denk als een chef! Gasten in een restaurant willen ook niet altijd hetzelfde. Daarom maken chefs verschillende gerechten voor verschillende gasten. Logisch, toch?

Waarom zouden we onze requirements dan nog als eenpansmaaltijd serveren?

Scheiding van smaken

Als goede chef bied je je gasten meerdere gangen aan en per gang verschillende gerechten om uit te kiezen. Zo kan iedere gast kiezen waar hij of zij behoefte aan heeft. Hetzelfde kun je doen met je requirements.

Verschillende stakeholders of teamleden hebben in verschillende fases van een project vaak behoefte aan andere informatie. Zo zal een business vertegenwoordiger aan het begin van het project een overzicht willen zien van de high level requirements waar een oplossing voor wordt gevraagd. Later wil hij lezen hoe dit zich vertaalt naar flows die deze needs en features invullen. Een developer wil kunnen lezen welke flows, bedrijfsregels en andere eisen hij in een sprint moet realiseren. En een tester wil weten welke testscenario’s moeten slagen om een stuk functionaliteit goed te keuren.

Zorg er daarom voor dat je je requirements handig gestructureerd opsplitst en bundelt. Use Case 2.0 biedt daarvoor een handig raamwerk.

DiVetro heeft dit raamwerk verder ingevuld naar een standaard met templates voor de verschillende soorten requirements. Het gebruik van deze templates zorgt ervoor dat alle vastgelegde informatie geordend en makkelijk terug te vinden is.

Verschillende gangen met verschillende informatie

Wij serveren onze requirements in diverse gangen en bieden per gang diverse informatie aan. Alle stakeholders mogen vervolgens hun smaak bepalen en de juiste documenten kiezen.

Eerste gang

We serveren altijd eerst een high level beeld van wat gewenst is:

• Needs en Features beschrijven de high level wensen van de stakeholders
• Het Use Case Model vertaalt dit naar high level doelen van de actors

Tweede gang

We volgen het Agile gedachtegoed en beschrijven wat het team nodig heeft om het werk te kunnen doen. Daarvoor bieden we diverse smaken:

• Use Case beschrijving: deze beschrijft een systeem vanuit het gebruikersperspectief. Het beschrijft de actor, de initiator van de interactie en het systeem zelf als een opeenvolging van eenvoudige stappen.
• Supplementary Requirements: aanvullende requirements die vaak voor de gehele oplossing van toepassing zijn en niet bij één specifieke Use Case behoren. Vaak zijn dit non-functionals.
• Glossary: Een lijst met termen die in de diverse onderdelen worden gebruikt zodat een consistent vocabulaire kan worden toegepast.
• Business rules: bedrijfsregels / validaties.
• Domain model: een conceptueel model van het (business) domein van de klant. Vaak in de vorm van een UML klassendiagram.
• Testscenario’s: een set testcondities en verwachte resultaten waarmee we kunnen bepalen of het systeem al dan niet correct werkt.

Met behulp van deze smaken kunnen we nu middels het just-in-time en just-enough principe details toevoegen waar en wanneer het nodig is. Het wanneer zal vooral afhangen van het moment waarop een use case slice / story daadwerkelijk in een sprint geïmplementeerd zal worden.

De specifieke inhoud van een requirement bepaalt vaak de vorm van vastleggen:

• Wet- en regelgeving leent zicht bijvoorbeeld goed voor business rules
• Procesbeschrijvingen en interactie tussen gebruikers en systemen zijn goed vast te leggen binnen een Use Case beschrijving

Derde gang

High level (technische) oplossingen kunnen worden vastgelegd in Use Case Realisations. Use Case Realisations beschrijven op een hoog niveau hoe delen van het systeem samenwerken om de gewenste oplossing te realiseren. Use Case Realisations kunnen diverse verschijningsvormen hebben. Veelgebruikte vormen zijn een sequence diagram of interactie / scherm ontwerp.

In tegenstelling tot in een restaurant zijn ‘onze’ gangen niet sequentieel; ze komen iteratief tot stand. Bovendien beschrijven we alleen wat op dat moment nodig is voor het team en op het detailniveau dat het team nodig heeft. In ons artikel ‘Efficiënte analyse, Just in Time en Just Enough’ hebben we deze aanpak in detail beschreven.

Een voorbeeld van specificaties met bovenstaande structuur is terug te vinden binnen de “Burgerzaken module specificaties”. Deze specificaties beschrijven de burgerzakenprocessen zoals zij binnen 400+ gemeenten in Nederland gevolgd worden.

Conclusie: Requirements zijn geen eenpansmaaltijd

Iedere stakeholder heeft op elk moment in het project andere behoeften met betrekking tot de requirements in het project.

De diepgang en de vorm van de requirements is afhankelijk van de fase van het project en de stakeholder die ermee aan de slag gaat. Het is dan ook haast onmogelijk om één document te maken waarin de requirements voor alle stakeholders en teamleden optimaal beschreven zijn.

Daarom leggen we de requirements vast op de meest logische plaats en voegen we op een agile wijze fasegewijs details toe die nodig zijn om het werk te kunnen verrichten.

Door een vaste structuur als basis aan te houden vergroten we de “vindbaarheid” van de requirements op zowel hoog niveau als detailniveau. Door te kiezen voor een logische plaats en vorm in plaats van één dik document wordt de lezer niet langer afgeleid door zaken die op dat moment niet relevant voor hem zijn.

Hoe denkt u hierover?

Hoe denkt u over requirements? Kunt u zich vinden in onze aanpak? Waarom wel of waarom niet? Aarzel niet en deel uw mening via het contactformulier onderaan deze pagina.

Bent u ook op zoek naar het juiste recept of de juiste bereidingswijze voor uw requirements? Neem gerust contact met ons op via info@divetro.nl of +31 (0) 88 000 54 00.

Blijf op de hoogte

Wilt u meer van dit soort blog posts lezen? Meld u dan aan voor onze nieuwsbrief. U ontvangt onze blog posts dan automatisch in uw mailbox.

Meld u aan voor onze nieuwsbrief