Veel ICT-projecten starten met vage doelstellingen. De eisen waaraan een te ontwikkelen systeem dient te voldoen, zijn vaak slecht of zelfs helemaal niet gespecificeerd. Hoe hoger de tijdsdruk, des te minder aandacht besteden we aan doelstellingen en eisen. Het gevolg: het project zweeft, loopt uit of er wordt uiteindelijk iets heel anders opgeleverd dan wat de opdrachtgever verwacht. Vooral de opstelling en de manier van communiceren van de kwaliteitsbewakers in een project kan een cruciale rol spelen bij het op een lijn krijgen van alle betrokkenen.
Het is overbekend dat foutherstel aan het einde van het ontwikkelingstraject aanzienlijk meer tijd en geld kost dan aan het begin van een traject. Uit diverse onderzoeken (Boehm, Software Engineering Economics, 1981; Weinberg, Quality Software Management, 1997) blijkt dat het merendeel van de fouten gemaakt wordt tijdens de ontwerpfase. Vage, niet meetbare eisen zijn veel voorkomende fouten. Het is dus van groot belang dat deze fouten zo vroeg mogelijk worden opgespoord. Toch zijn we erg slordig met het specificeren van eisen en als gevolg daarvan komen nog steeds veel gebreken pas aan het licht in de acceptatietestfase. Het is dan te laat om er nog iets aan te doen en het systeem gaat in productie. Het gevolg: veel beheerskosten, ergernis bij gebruikers, en de doelstellingen worden niet gehaald.
Veel in de praktijk voorkomende problemen met het formuleren van eisen zijn in één van de volgende categorieën in te delen:
» De eisen zijn niet voor iedereen 100 procent duidelijk
Een eis als ‘Het systeem moet aansluiten op de bestaande infrastructuur’ kan voor de opsteller ervan volkomen duidelijk zijn, maar bij de ontwikkelaar die dit moet realiseren een groot aantal vragen oproepen. Wat wordt precies bedoeld met de bestaande infrastructuur? Wat betekent aansluiten? In het gunstigste geval onderneemt de systeemontwikkelaar actie en probeert de onduidelijkheden alsnog op te helderen. Helaas neemt hij ook vaak iets aan (‘Het komt wel goed, we ontwikkelen immers onder Windows’) en komen de problemen pas veel later aan het licht.
Sommige eisen lijken duidelijk, maar blijken door verschillende personen anders geïnterpreteerd te worden. ‘Raadplegen van de status historie moet mogelijk zijn’. Dat de gebruiker hiervoor eerst een ander programma moet starten, was echter niet de bedoeling.
» Eisen worden vaak verward met ontwerp
Een voorbeeld: bij de bouw van een omvangrijke applicatie, die zou moeten draaien op diverse platforms, was één van de eisen dat alle programmatuur in ANSI-C moest worden ontwikkeld. Door deze beperking liep het project erg stroef. Toen duidelijk werd dat de achterliggende eis een bepaalde mate van portabiliteit was, kwamen ook andere oplossingen in beeld, waardoor uiteindelijk vele weken werk werd bespaard.
Ook in de dagelijkse praktijk zijn we voortdurend geneigd het doel en de middelen door elkaar te halen. In de showroom zegt een klant tegen de autoverkoper: ‘Er moet wel een trekhaak op’. Hij wil een fiets kunnen vervoeren en in gedachten stelt hij zich zo’n fietsenrekje voor dat op de trekhaak bevestigd kan worden. Door de trekhaak als eis te formuleren, wordt een heel scala aan alternatieve (misschien goedkopere of gemakkelijkere) oplossingen uitgesloten.
» Eisen zijn onrealistisch en moeilijk te testen
De eis ‘Het systeem moet tien miljoen transacties per dag kunnen verwerken’ is voor een eerste release waarschijnlijk veel te hoog gegrepen. Bovendien is het vaststellen of aan deze eis is voldaan in dit stadium een veel te dure aangelegenheid. Het gevaar is erg groot dat niemand serieus aandacht schenkt aan deze eis.
‘Schermwisselingen moeten binnen een seconde plaatsvinden’; dit is onrealistisch als de koppelingen naar aangeroepen systemen er minstens een paar seconden over doen om gegevens naar het systeem te transporteren. Ook hier kan het gevolg zijn dat de gebruiker pas in een laat stadium geconfronteerd wordt met lange wachttijden, waar moeilijk iets aan veranderd kan worden. Een betere formulering zou zijn: ‘Het systeem moet de afdeling X in staat stellen honderd nieuwe bankrekeningen per dag te openen.’
Het goed specificeren van eisen is nog steeds een sterk onderontwikkeld deel van het vakgebied en de bron van veel problemen en onnodige kosten in de ICT-industrie. Deze problemen kunnen worden geminimaliseerd als eisen worden gespecificeerd volgens vooraf vastgelegde normen en door deze structureel te controleren en expliciet te testen of het beeld bij alle betrokkenen gelijk is.
In een ICT-project worden vaak de functionele eisen geformuleerd in termen van ‘wat nodig is om een bepaald probleem op te lossen’ en ‘wat het systeem moet kunnen’. Ook worden in een project voorwaarden gesteld aan wat het systeem moet kosten aan geld, tijd en bemensing, de zogenaamde resource-eisen. Andere eisen in de vorm van beperkingen (de zogenaamde constraints) op functionaliteit, juridisch, cultureel en politiek gebied, worden meestal ook in het project onder de aandacht gebracht.
De kwalitatieve eisen die aan een systeem worden gesteld, blijven in het ontwikkelingstraject echter vaak onderbelicht. Dat wil zeggen, aan de vraag ‘Hoe goed moeten de oplossingen zijn?’ wordt relatief weinig aandacht geschonken. Toch bepalen deze eisen in hoge mate de tevredenheid van de gebruikers over het systeem.
Een bekend recept om eisen en wensen te formuleren, is deze te specificeren volgens de ‘smart-aspecten’. Deze aspecten ‘specifiek, meetbaar, acceptabel, realiseerbaar en tijdgebonden’ worden in de praktijk echter te vrijblijvend geïnterpreteerd om de eisen en wensen helder en duidelijk te kunnen specificeren. Daarom is er behoefte aan duidelijke, meetbare, vooraf opgestelde, criteria voor het opstellen van de eisen en wensen, in het bijzonder de kwalitatieve eisen.
De volgende criteria zijn een deelverzameling van Tom Gilbs regels (Principles of Software Engineering Management, 1988), waar men in de praktijk al aardig mee uit de voeten kan.
» Een eis is ondubbelzinnig en duidelijk voor de doelgroep beschreven.
» De eis mag geen ontwerpspecifi catie zijn.
» Een kwalitatieve eis is kwantificeerbaar en heeft een schaal met meetpunten met daarop gedefinieerd minimaal de volgende punten:
Vertrekpunt = de stand van de huidige situatie; Must = het doel dat minimaal moet worden gehaald voor acceptatie van het systeem op dit punt; Plan = het doel dat moet worden gehaald om het systeem – wat betreft deze eis – tot volle tevredenheid te laten werken. Stel dat een systeembeheerder bij een productieprobleem binnen een bepaalde tijd een diagnose moet kunnen stellen. Het ‘must’-niveau is 15 minuten, het ‘plan’-niveau is 10 minuten. Wordt nu bij een acceptatietest een waarde groter dan 15 minuten gemeten, dan wordt het systeem op dit punt niet geaccepteerd. Waarden tussen 10 en 15 minuten zijn prima. Bij waarden kleiner dan 10 minuten kan men zich afvragen of er niet onnodig veel kwaliteit is opgeleverd.
» De prioriteit van elke eis moet duidelijk zijn aangegeven.
Hoe belangrijk is een eis voor het slagen van het project? In plaats van aan alle eisen even veel belang te hechten, is het zinvol prioriteiten toe te kennen.
» Een eis is te herleiden tot een bron (wie is de ‘belanghebbende’, de steller van de eis) en heeft een beschreven historie.
Met een bronvermelding kan een eis gecontroleerd worden. De kans op controle zal er bovendien voor zorgen dat een auteur meer moeite zal doen om fouten te voorkomen.
Het kennen van deze criteria is geen garantie dat ze ook daadwerkelijk worden toegepast en leidt dus niet automatisch tot soepeler lopende projecten. Een aantal veel voorkomende oorzaken hiervoor zijn:
» De drang tot productiviteit
De tijd die we besteden aan voorbereidende en controlerende werkzaamheden, beschouwen we vooral als improductief. Zolang er geen pagina’s ontwerp en/of regels broncode worden opgeleverd, ontstaat er een soort schuldgevoel. Beginnen met programmeren geeft wel dat gevoel van productiviteit.
» De tijdsdruk
Onder hoge tijdsdruk is de verleiding groot om een (tussen)product gereed te verklaren. Het is gemakkelijker van een definitiestudiedocument te zeggen dat het af is, dan van een stuk programmatuur. Immers, van programmatuur kan de (niet)werking vrij gemakkelijk worden aangetoond. Dus te vroeg zeggen dat het klaar is, komt vrij snel aan het licht. De problemen die ontstaan nadat een definitiestudiedocument te vroeg is vrijgegeven, komen daarentegen pas later aan het licht, veelal bij de acceptatietesten.
» Negatieve ervaringen uit het verleden
Een aantal regelmatig terugkerende uitspraken zijn: ‘O, je wilt zeker inspecties gaan invoeren: veel te veel papierwerk en het levert niets op’, ‘Al die RAD-achtige methoden leiden alleen maar tot spaghetti-code zonder duidelijke ontwerpen’ en ‘Kwaliteit kun je niet meetbaar maken’. Dit zijn heel begrijpelijke reacties. Als in het verleden op een verkeerde manier ontwikkelingsmethoden en inspectietechnieken zijn toegepast, heeft dit desastreuze gevolgen voor het commitment van medewerkers.
» Belanghebbenden zijn vaak moeilijk in actie te krijgen
Meedraaien in een project is niet het dagelijks werk van eindgebruikers en applicatiebeheerders. De tijd die ze mogen besteden aan projectwerkzaamheden is vaak beperkt en ze worden vaak ook nog op onverwachte momenten teruggeroepen naar hun vaste werkplek om dagelijkse problemen op te lossen. Wanneer belanghebbenden binnen het project onvoldoende concrete taken hebben of het gevoel dat er niet naar hen geluisterd wordt, is de vlucht naar de dagelijkse werkzaamheden een hele natuurlijke en gemakkelijk te verdedigen reactie.
Projectmanagement alleen is niet voldoende voor het scheppen van de juiste voorwaarden voor het slagen van een project. Een belangrijke rol is ook weggelegd voor projectmedewerkers die taken met betrekking tot kwaliteitsbewaking uitvoeren. Zij moeten het projectteam en de belanghebbenden ertoe bewegen zich optimaal te motiveren voor, en te richten op het project. Een coachende rol is hierbij vele malen effectiever dan een rol als politieagent of waakhond.
Het verkrijgen van commitment bij de projectleider over de aanpak bij het opstellen van de eisen en wensen voor het systeem, is een voorwaarde voor het ontwikkelen van een kwalitatief hoogwaardig product. De aanpak ‘We moeten inspecties op de eisen uitvoeren en we hebben normen nodig’ zal veel weerstanden oproepen.
Met een coachende opstelling, bijvoorbeeld door het stellen van vragen (‘Vind jij ook dat de eisen ondubbelzinnig en duidelijk moeten zijn en dat gebruikers moeten begrijpen wat ze opgeleverd krijgen?), kan men bij projectleiders veel meer medewerking verkrijgen.
Soms helpt het om een mini-inspectie te organiseren, met als toetsingskader drie eenvoudige regels, waar geen zinnig denkend mens iets tegen kan hebben: de eis moet ondubbelzinnig en duidelijk zijn geformuleerd, de eis mag niet de oplossing bevatten, de eis moet te herleiden zijn tot de bron. Indien de betrokkenen vervolgens zelf naar aanleiding van deze regels een pagina met eisen controleren, brengt dat al veel problemen aan het licht. Ze ervaren dan aan den lijve dat ogenschijnlijk duidelijke eisen door een ander totaal verschillend geïnterpreteerd kunnen worden. In een groep aan elkaar laten uitleggen hoe verschillend een kreet door twee mensen kan worden geïnterpreteerd, kan echte ‘eye-openers’ opleveren. Inventarisatie van de risico’s van het niet ontdekken/niet oplossen van de fouten brengt vervolgens de kosten in kaart: hoe groot zou de schade zijn als het systeem zou worden opgeleverd met de verkeerd geïnterpreteerde eisen?
Het actief betrekken van belanghebbenden bij het gehele ontwikkelingstraject helpt enorm bij de acceptatie van de resultaten die gedurende het gehele traject worden opgeleverd. Door deze betrokkenheid wordt hen duidelijk dat, ondanks de drukke werkzaamheden, zij minder tijd kwijt zijn dan wanneer ze ad hoc moeten reageren op werkzaamheden gedurende het project.
Een gezamenlijke kick-off-workshop is een uitstekend middel om die betrokkenheid te stimuleren. Tijdens zo’n bijeenkomst kan men helder en duidelijk de afspraken doornemen die met de projectleider zijn gemaakt. In tegenstelling tot de ‘waakhond-rol’ werkt een houding als facilitator of coach bij het opstellen van de eisen positief. Hierbij worden geen welles/nietes-spelletjes gespeeld, er bestaat een meer uitdagende benadering, bijvoorbeeld: ‘mijn ervaring is dat als we er samen voor gaan zitten, iedere eis binnen een uur meetbaar is te maken’. Als uitgangspunt wordt dan genomen het met z’n allen werken aan een goed resultaat. Om geen verkeerde verwachtingen te wekken, is het heel belangrijk de belanghebbenden op de hoogte te brengen wanneer aan bepaalde eisen niet kan worden voldaan.
Lichtvaardig omspringen met expertise ten slotte moet worden vermeden. Het inrichten van bijvoorbeeld een inspectieproces vereist een grondige voorbereiding en kan men niet overlaten aan iemand die hierover eens een boekje heeft gelezen. Hetzelfde geldt voor de implementatie van de kwaliteitsbewakingsprocessen. Een goede opleiding vooraf is een essentiële voorwaarde.

AUTEUR: Gerlof Hoekstra en Jurjen Kamphuis

Gerlof Hoekstra (Gerlof.Hoekstra@atosorigin.com) en Jurjen Kamphuis (Jurjen.Kamphuis@atosorigin.com) zijn als consultants werkzaam bij Atos Origin, bij de groepen Testing Services en Requirements Engineering.