In hoeverre zijn requirements en specificaties nuttig?

Tijdens model-driven ontwikkel projecten wordt vaak de vraag gesteld waarom we de requirements en specificaties nog zouden moeten documenteren. Immers, omdat product-owners het “model” dat wordt gebruikt tijdens de ontwikkeling van modeldriven software gemakkelijk begrijpen wordt de kans op miscommunicatie tussen business- en IT-professionals enorm verlaagd.

Daarom lijkt het misschien voldoende dat de product-owner en ontwikkelaar even bij elkaar gaan zitten om een snelle POC te bouwen die later door het projectteam kan worden uitgebreid.

Daarom zijn requirements nuttig

Maar requirements en specificaties zijn meer zijn dan alleen maar instructies voor de ontwikkelaars. Ze beschrijven immers de relatie met de bedrijfsdoelstellingen, geven inzicht in de vraag waarom de applicatie überhaupt is ontwikkeld, welke functionaliteit deze wel (en niet) moet ondersteunen en waaraan deze moet voldoen.

Dit is zeer nuttig, want:

1. Dit draagt bij aan een gemeenschappelijk begrip.
   Een gemeenschappelijke basis is belangrijk voor het projectteam, zodat iedereen begrijpt waar gezamenlijk aan wordt gewerkt en waarom. Dit begrip betreft niet alleen het technisch perspectief, maar geeft ook goede handvatten wanneer keuzes moeten worden gemaakt tussen kwaliteit, functionaliteit en snelheid van levering.
2. Ze geven richting in geval van wijzigingen.
   De requirements en specificaties bieden belangrijke achtergrondinformatie. Deze bepaalt mede wanneer en hoe een wijziging moet worden geïmplementeerd. Als een wijziging wordt geaccepteerd, moeten de specificaties daarom zo snel mogelijk worden bijgewerkt om alle aanpassingen duidelijk te beschrijven, maar ook om eventuele hieruit resulterende conflicten te analyseren en te bespreken.
3. Ze zijn de basis voor het testen.
   Testen zonder requirements en specificaties kan (zal!) leiden tot veel gemiste defects en heeft vaak tijdrovende discussies tussen testers en ontwikkelaars tot gevolg. Eventuele tijdswinst als gevolg van niet opstellen van requirements en specificaties wordt in dit geval ruimschoots teniet gedaan.

Betekent dit dat, met betrekking tot requirements en specificaties, een project pas kan starten als alle eisen en specificaties formeel door de stuurgroep zijn aanvaard? Met antwoord daarop is “Nee”. Ze moeten niet gezien worden als proces belemmerende bureaucratische hobbel. Naar mijn mening moeten de requirements en specificaties in een project van een zodanige kwaliteit zijn dat de volgende formule wordt geoptimaliseerd:

(De kosten om meer tijd te besteden aan het schrijven van betere eisen en specificaties)
MINUS
(Het risico van verliezen als gevolg van “waste” in de 3 bovenstaande scenario’s)

Zinvol tijd benutten

Met andere woorden, requirements en specificaties moeten steeds verder worden uitgewerkt tot de kosten van het verbeteren ervan hoger zijn dan de resulterende “waste”, uitgedrukt in onnodige kosten, die ze kunnen voorkomen. Besef je hierbij dat een uurtje overleg met een team van 8 personen om functionaliteit achteraf te verduidelijken evenveel kost als een dag langer werken aan het vooraf goed beschrijven van de functionaliteit. Een team prima kan starten met conceptversies van requirements en specificaties wanneer alle betrokkenen de risico’s die samenhangen met niet volledige informatie accepteren. De definitieve versie van de specificaties kan dan worden geleverd samen met alle andere projectdeliverables zoals overeengekomen in een Definition of Done, om klaar te zijn voor de eerstkomende wijziging die zeker zal komen.