Specificaties als fundament

Met belangstelling heb ik het artikel van Arie van Bennekum (Computable, 19 november) gelezen. De principes van dsdm onderschrijf ik van harte, maar waar het artikel naar mijn mening enigszins aan voorbij gaat, is het belang van heldere, eenduidige specificaties. Van Bennekum stelt zelfs dat de eindkwaliteit bepaald wordt door de werkelijke behoefte en de bestaande situatie, in plaats van op basis van algemene specificaties.
De auteur roert hier een belangrijk punt aan, zonder daar echter nader op in te gaan en dat is jammer. Goede specificaties (ik gebruik liever de Engelse term requirements ) vormen namelijk mijns inziens het fundament van een goed systeem.
Karl Wiegers (http://www.processimpact.com) onderscheidt drie niveaus met betrekking tot de 'requirements':
In business requirements wordt beschreven waarom een project überhaupt wordt uitgevoerd, in welke mate, en op welke wijze het bijdraagt aan de doelstellingen van de organisatie. Deze 'requirements' worden vastgelegd in een 'Vision and Scope'-document en bepalen de grenzen van het uit te voeren project; wat behoort wel tot het project en - vooral - wat niet.
In de user requirements wordt beschreven wat het op te leveren systeem moet doen. In het use case document, staat de taak of taken die de gebruiker(s) met behulp van het systeem willen of moeten uitvoeren, beschreven.
In de functional requirements wordt beschreven hoe het systeem de gewenste functionaliteit zal moeten gaan leveren; de 'software requirements specification' (srs).
Dit past prima binnen de dsdm-filosofie. Samen zijn alle betrokkenen (management, met name met betrekking tot de 'business requirements', gebruikers en ontwikkelteam) verantwoordelijk voor de kwaliteit van de 'requirements'. Het spreekt vanzelf, dat een goed beheer van de 'requirements' een vereiste is.
Voortschrijdend inzicht leidt gedurende het ontwikkelingstraject tot gewijzigde eisen en daarmee tot wijzigingen in de 'requirements'. Op het laagste niveau (de SRS) zijn - na een kosten/baten-analyse - zonder al te veel problemen wijzigingen in de 'requirements' aangebracht; gebruikersorganisatie en ontwikkelteam zijn hiervoor verantwoordelijk. Bij wijzigingsvoorstellen op het tweede niveau zal altijd eerst (bijvoorbeeld door de projectleider) moeten
worden vastgesteld of de voorgestelde wijzigingen in lijn zijn met de visie en binnen de scope vallen die op het hoogste niveau zijn vastgelegd. Valt een voorgestelde wijziging buiten de scope, maar wordt deze toch als noodzakelijk beschouwd, dan zullen de 'business requirements' moeten worden bijgesteld.
De betrokkenheid van het management wordt hierdoor gestimuleerd.
Door de verantwoordelijkheid voor de 'requirements' daar te leggen, waar ze horen, ontstaat betrokkenheid. De mensen in kwestie zullen ook beter in staat zijn prioriteiten te stellen: moet een wijziging in de eerstvolgende versie van de software zijn aangebracht, kan het in een volgende versie)? Als de gewenste afwijkende of nieuwe functionaliteit vervolgens door de verantwoordelijken (en dit zijn dus op niveau twee en drie onder andere de gebruikers) wordt afgezet tegen de kosten die ermee gemoeid gaan, zal alleen de essentiële functionaliteit in het systeem worden opgenomen. Dit draagt bij aan een kortere 'time-to-market' en lagere kosten, ofwel een hogere 'return-on-investment'.
 
Edwin de Nies, competence manager system development,
Randstad Automatiseringsdiensten.