Wat wil de klant? Requirements made easy.

Maart 2008 - Elke developer kent het wel, je bouwt iets volgens de specificatie en dan blijkt het niet goed te zijn, terwijl het toch de beste oplossing was en je precies gebouwd hebt wat gevraagd werd. Maar blijkbaar wil de klant het toch anders en hebben de managers en analisten dat niet goed begrepen of wel goed begrepen maar niet verklapt.

Een manier om communicatieproblemen te verminderen is zicht te krijgen op de onderliggende processen en requirements die aan een nieuw of bestaand systeem ten grondslag liggen. Als deze goed onderzocht en gecommuniceerd zijn volgt daar vaak direct uit wat de bedoeling van een bepaalde feature is. De kans is dan veel groter dat je bouwt wat de klant wenst en dat willen we tenslotte allemaal: tevreden klanten.

In dit Whitebook gaan we a.h.v. het boek ‘Mastering the Requirements Process’ van Robertson & Robertson in op de vraag hoe deze processen en requirements na een goede analyse in het algemeen opgebouwd zijn en welke vragen daarbij beantwoord moeten zijn. We kijken daarvoor eerst naar het werk dat de business moet doen en de business use cases die daaruit voortkomen. Deze business use cases leiden tot product use cases die de basis zijn voor de requirements. Met de kennis van de proces- en requirementsstructuur in gedachten is deze informatie vaak makkelijk in je eigen organisatie terug te vinden, voor dat gedeelte waar jij mee te maken hebt. Als er tenminste al voldoende over nagedacht is in het project...

Business processen

The Work

De business waarvoor een bepaald systeem gemaakt wordt bestaat uit een hoeveelheid werk, door Robertson & Robertson ‘the Work’ genoemd. Het werk hoeft alleen maar uitgevoerd te worden als er iets of iemand (een opdrachtgever of een klant) van buiten het werk geïnteresseerd is in de uitkomst (‘Outcome’) van het werk. Een bakker hoeft tenslotte niet te bakken als niemand zijn brood wil kopen. De outcome (een verkocht brood) is overigens iets anders dan de output (bv. een brood) van het werk. Rond het werk liggen andere systemen (‘Adjacent Systems’), waarmee het werk informatie uitwisselt. Het werk en de aangrenzende systemen met hun informatiestromen zijn weergegeven in een zogenaamd context diagram (zie voor een eenvoudig voorbeeld fig. 1).

Figuur 1, Eenvoudig voorbeeld contextdiagram

Business Events

Het werk ontstaat op het moment dat er een Business event optreedt. Er komt bijvoorbeeld een klant binnen die een boek wil kopen. Op dat moment start het werk en begint de use case (‘Business Use Case’). De verkoper bepaalt de prijs van het boek, de klant betaalt daarna met de creditcard. De uitkomst is dat de klant met het ingepakte boek de winkel verlaat en de winkel zijn geld bijgeschreven gekregen heeft op de rekening.

Elk business event heeft een informatieflow naar het werk tot gevolg waarop het werk reageert. De Business events zijn dus makkelijk af te leiden uit het context diagram waarop deze flows weergegeven zijn. De Business Use Case bestaat uit een aantal processtappen om het werk uit te voeren. Een processtap kan door een medewerker, een machine, een computersysteem of iets anders uitgevoerd worden.

Product Use Cases en Requirements

Tijdens de analyse is bepaald welke processtappen geautomatiseerd uitgevoerd moeten worden. Dit is de Product Use Case, die dus meestal minder processtappen bevat dan de Business Use Case. Er is altijd een Actor die de Product Use Case uitvoert (zie fig. 2). De use case stappen zijn het uitgangspunt voor het opstellen van de requirements.

Figuur 2, Product use case met actor

Elke stap leidt meestal tot 3 tot 6 requirements die begrijpelijk zijn voor de business. Naast deze functionele requirements zijn er ook non-functionele requirements, zoals bv. performance-eisen en beveiligingseisen. Tenslotte zijn er nog beperkingen die vanuit de business of de techniek opgelegd zijn, waaraan het systeem moet voldoen.

Rationale

Een requirement an sich helpt je meestal nog niet het juiste product te bouwen. De business begrijpt best wat ze met ‘een mooie user interface’ bedoelen, maar daar kan je nog alle kanten mee op. Daarom wordt bij een requirement ook de beweegreden (‘Rationale’) bepaald. Zo kan een beweegreden zijn dat een mooie interface minder fouten oplevert maar ook dat een mooie interface snel te leren is. Dat geeft al een veel beter beeld van waar het naar toe moet.

Fit criterion

Maar om de requirement sluitend te krijgen is het ook nodig te weten wanneer de business de oplossing gaat accepteren. Hoeveel fouten zijn nog acceptabel en hoe snel is snel? Dit is het ‘Fit Criterion’. Het fit criterion bepaalt wanneer de oplossing volledig op de business wens ‘past’. De developer kan daarmee kiezen voor een extra datum controle of om extra tooltips toe te voegen. Bij een requirement heb je dus altijd een maatstaf nodig om te weten of de wens gerealiseerd is en te zorgen dat het juiste gerealiseerd kan worden.

Verschillende soorten softwareontwikkeling

Klassiek

In klassieke systeemontwikkeltrajecten zijn de business processen en requirements meestal uitgebreid beschreven en gemodelleerd. De meeste van boven beschreven concepten zijn in een bedrijfsspecifieke vorm met eigen templates en procedures aanwezig.

Rational Unified Process (RUP)

De iteratieve software ontwikkelmethode RUP hebben we in een vorig Whitebook besproken. Hier vindt je een beschrijving van de businessprocessen, projectomgeving, voorwaarden e.d. in het artifact ‘Vision’-document. Het artifact ‘System Requirements Specification’-document bevat de requirements op hoog niveau voor het algemene beeld. De requirements die uit de use cases afgeleid worden vindt je in Requisite Pro als het project met deze tool werkt, anders worden ze vaak in een andere tool vastgelegd. Ook de non-functional requirements en constraints worden daar opgeslagen. De requirements zijn in Requisite Pro gekoppeld aan de betreffende Product Use Case, die meestal in een Word-document beschreven is. Als er gewerkt wordt met Rationale’s en Fit Criterion’s zou je die in de attributen van de requirements terug moeten kunnen vinden in Requisite Pro. Het procesmodel kan als een activity diagram weergegeven zijn. In de ideale wereld zou je via de traceability rechtstreeks van je werk bij de betrokken requirements, use cases en processen moeten kunnen komen.

Scrum/Agile

Werk je in een SCRUM of ander agile project dan gebruik je over het algemeen User Stories die overeenkomen met de requirements. User stories zijn opgesteld in de vorm van ‘Als klant wil ik gemakkelijk boeken kunnen kopen, zodat ik ze snel tot mijn beschikking heb.’ Hierin is de klant de actor, wat de klant wil is de requirement en het zodat deel van de user story is de rationale. De maat voor de fit zou in dit geval de tijd zijn en het Fit Criterion dus bv. 1 week.

Conclusie

Vaak is het proces niet zo mooi uitgevoerd als hierboven beschreven maar de business ligt altijd ten grondslag aan de requirements en de bouwopdracht. Uit deze businessprocessen komt een automatiseringswens naar voren die tot een product use case leidt die geautomatiseerd gaat worden. Let bij het ontwikkelen op het betrokken proces en de product use case. Visualiseer de use case en houd in gedachten dat deze alleen het product beschrijft en niet alle businessstappen. Vraag je af wat er mee bereikt moet worden. Het belangrijkst is dat je in gesprekken met de analisten of gebruikers de in dit Whitebook beschreven analyseconcepten in gedachten houdt en vraag vooral door naar de rationale en het fit criterion. Een goed begrip hiervan maakt uiteindelijk het verschil tussen een teleurgestelde of een tevreden klant.

Links/Referenties

Dit Whitebook is gebaseerd op het boek ‘Mastering the Requirements Process’, 2e editie van Suzanne Robertson en James Robertson, ISBN: 978-0-321-41949-1, www.systemsguild.com, www.volere.co.uk.

Whitebook ‘Unified Process, what the RUP is that?’

Over de auteur
Arianne van den Berg is senior Oracle/Java consultant en heeft ruim 10 jaar ervaring in de IT. Ze heeft zich vanuit een Oracle developer achtergrond ontwikkeld richting Java technologie en is de afgelopen jaren werkzaam in J2EE ontwikkel- en ontwerptrajecten.