Een van de belangrijkste redenen waarom projecten slagen, is het opstellen van goed gespecificeerde requirements. Juiste requirements vormen de basis voor een goed projectresultaat en bespaart de organisatie veel kosten en frustratie.
De omgeving van een organisatie is onderhevig aan continue verandering. Soms met impact op strategisch niveau maar altijd met impact op het tactisch- of operationeel-niveau. De verandering kan bestaan uit gewijzigde omstandigheden in de markt, nieuwe kansen of bedreigingen, technologische vooruitgang, veranderde wet- en regelgeving en/of interne knelpunten oplossen, zoals het verbeteren van onnodige fouten, zorgen voor een positieve werksfeer, collegialiteit verhogen, service gerichtheid verhogen en/of medewerkers tevreden houden.
In de afgelopen jaren is heel veel onderzoek verricht naar zogenaamde kritische succesfactoren voor het succes van it-projecten. Het formuleren van duidelijke requirements en specificaties staat bovenaan in de lijst.
In een ander onderzoek staat dat de meeste organisaties veel tijd en inspanning besteden aan de juiste uitvoering van het requirementsproces. De meeste organisaties erkennen dat goede requirements veel of zelfs heel veel bijdragen aan het succes van een project. De organisaties kennen een standaard requirementsproces, maar het kost ze nog veel moeite om dit proces in praktijk te hanteren. Daarom wordt de afstemming en uitvoering van een gemeenschappelijk requirementsproces door de hele organisatie heen als succesfactor voor het slagen van een project genoemd.
Wat zijn requirements?
Het begrip requirements is een van oorsprong Engels begrip. In het Nederlands betekent dit iets als behoeften, eisen, specificatie, specificatie van eisen, vereisten of wensen, maar geen van deze begrippen dekt de lading. Het begrip kan duiden op:
• een bepaalde vereiste van een systeem
• de activiteit van het opstellen van vereisten, de requirementsanalyse
• de documentatie van de vereisten in een formeel document
In de klassieke technische benadering wordt een set van requirements gebruikt als input in het ontwerpstadium van een productontwikkeling. De requirements beschrijven welke elementen en functies benodigd zijn voor een specifiek project.
Een requirementsanalyse-traject kan vooraf zijn gegaan door een haalbaarheidsstudie, of een fase van conceptuele analyse. De requirementsanalyse-fase kan worden opgedeeld in:
• requirement ontlokken (elicitatie, van het engels: elicitation): verzamelen van vereisten van stakeholders
• requirementsanalyse: controleren op consistentie en volledigheid
• specificatie: gedetailleerde documentatie, en
• verificatie: controleren of de verkregen requirements correct zijn.
Requirements geven aan welke toegevoegde waarden het product moet leveren aan de business. Een requirement is een enkelvoudig gedocumenteerde bepaling, wat een bepaald product zou moeten doen. In een requirement worden de benodigde attributen, capaciteiten, karakteristieken of kwaliteiten van een product geïdentificeerd, die bruikbaar zijn en meerwaarde bieden voor een gebruiker.
Voorbeelden van business requirements:
• Het track en trace-systeem informeert de klant per email wanneer de bestelling bij het door de klant opgegeven DHL-distributiepunt klaar ligt.
• De kassa berekent 25 procent korting bij een bestelling van drie zakken patat.
• 90 procent van de verkoopadviseurs maakt de standaard offertes na een één-daagse training probleemloos.
• De klant/burger wil eenvoudig en snel aangifte kunnen doen.
Veel organisaties vinden requirement-ontwikkeling één van de moeilijkere aspecten van het klantproces. Zij hebben problemen met het verzamelen, analyseren, documenteren en valideren van requirements. Dit blijkt uit het RE Compass 2012-rapport van ict-dienstverlener Devote in samenwerking met ict-leverancier IBM Nederland.
Opstellen van requirements
Het opstellen van requirements is belangrijk voor het op maat leveren van je product. Een product kan ook een systeem, idee of dienst zijn. Je wilt dat je dat maakt wat de klant nodig heeft. Een tevreden klant is goed voor je business. Je begint met het vragen aan de klant wat de wensen en behoeften zijn en vervolgens ga je aan de slag en maak je een eerste concept. De klant geeft een aantal wijzigingen of nieuwe specificaties aan en je maakt met nog een aantal iteraties het product. De klant ontvangt het product en is niet tevreden met wat je hebt geleverd. Dit proces is herkenbaar voor vele leveranciers en ontwikkelaars van producten en diensten.
De communicatie in het requirementsproces is soms anders verlopen dan verwacht. Kenmerkend voor communicatie tussen mensen is dat misverstanden en interpretatieverschillen onvermijdelijk zijn. Ook voor schriftelijke communicatie geldt immers dat er altijd ruis op de lijn zit tussen zender en ontvanger. Toch gaan we ervan uit dat de opdrachtnemer een product oplevert dat voldoet aan het Programma van Eisen. De onvermijdelijke verschillen tussen de behoeften van de opdrachtgevende organisatie en de interpretatie van de opdrachtnemer komen pas bij oplevering aan het licht.
Gebruikers weten niet welke requirements ze willen
Het is vrijwel onmogelijk om op voorhand alle ins en outs van de nieuwe situatie te overzien. Tot in detail aangeven wat je eisen en wensen zijn voor een product dat de nieuwe situatie gaat ondersteunen, is vrijwel ondoenlijk. Mensen hebben daar een concreet beeld van de nieuwe situatie voor nodig. Het is een bekend verschijnsel dat zodra het nieuwe systeem is ingevoerd de gebruikers veel beter kunnen aangeven wat ze precies hadden willen hebben. De uitdrukking ‘I know it when I see it’ komt daar vandaan.
In 1977 beschreef eigenaar van de Humpty-Dumpty-supermarkt Silvan Goldman hoe klanten zijn uitvinding afwezen: Een mandje op de zitting en daaronder nog een mandje, en onder de poten vier wielen en voilà, de klant kan ineens kilo’s meer boodschappen doen. Succes gegarandeerd, zou je zeggen. De meeste huisvrouwen zeiden beslist ‘nee, geen wagentjes meer voor mij. Ik heb genoeg baby’s vooruit geduwd’. De mannen zeiden: ‘Denk je dat ik geen mandje kan dragen’. En zij raakten hem niet aan. Het was een complete afgang.’ Niemand geloofde in het nut boodschappenwagentjes. Nu anno 2015 is de boodschappenwagen niet meer weg te denken uit de winkel van supermarktketens.
Het is voor gebruikers enorm lastig om aan te geven wat hun wensen en behoeften zijn. Vooral als zaken abstract beschreven worden, zoals in requirement-trajecten vaker voorkomt. We zullen het gebrek aan kennis moeten accepteren. Noch de gebruiker, noch de consultant weet precies wat er gebouwd moet worden. Begin met het maken van een schets en laat die aan de gebruiker zien. Ga samen door de schetsen heen en laat ook andere experts helpen bij het maken van de schets. Niets is te gek of vreemd in het begin, zelfs iets wat helemaal niet realiseerbaar of wenselijk is. Tijdens dit proces worden de eerste requirements vastgelegd en ontstaan de contouren van een eerste concept. Begin, bij voorkeur meteen met het ontwerpen en/of bouwen van een eenvoudig eerste prototype. Ga dit prototype testen met gebruiker en experts. In deze test wordt voor de gebruiker en de consultant al snel duidelijk wat écht niet realiseerbaar of wenselijk is en wat wel: Wat de gebruiker écht nodig heeft en wat de gebruiker nog aan wensen heeft. Maak een prioritering en maak keuzes (met bijvoorbeeld de MoSCoW methode) en zo ga je verder, stap voor stap en focus op wat ontstaat.
Herstelkosten van de requirements
Door problemen met ict-systemen lijdt de Nederlandse economie jaarlijks ongeveer 1,6 miljard euro schade. Eerder bleek al uit onderzoek dat de Nederlandse overheid jaarlijks miljarden verspilt aan ict-projecten.
Tom King en Joe Marco hebben een formule ontwikkeld voor software projecten (in een traditionele ontwikkelomgeving), waarmee de kosten van slechte requirements snel inzichtelijk gemaakt kunnen worden. Deze formule berekent wat het gemiddeld kost om één fout in de requirements te herstellen, die pas wordt ontdekt tijdens de systeemtest en/of acceptatietest. Deze formule berekent dat voor een project met een applicatie-ontwikkeling die bestaat uit 25 schermen en rapportages en waarvan de gemiddelde weekkosten van een ontwikkelaar 2500 euro bedragen de totale herstelkosten voor vijftig fouten in de requirements zo’n 56.250 euro bedragen (op een bedrag van circa 250.000 euro aan zuivere ontwikkelkosten. In dit rekenvoorbeeld zal elke fout in de requirements die je pas ontdekt tijdens de testfase 1125 euro kosten (en in een latere fase nog veel meer!).
Met deze formule kunnen managers per project uiteindelijk heel concreet maken wat bij benadering de kosten zullen zijn van fouten in de requirements die pas tijdens de testfase worden ontdekt. En dat dit dertig tot zeventig keer meer is dan wanneer je ze ontdekt voordat je begint met het bouwen van de applicatie.
Formele moderatie sessies
Moderatie sessies zijn dynamische workshops waarin groepen (stakeholders) worden gefaciliteerd bij het gezamenlijk uitwerken van resultaten en het nemen van beslissingen. Deze sessies zijn net even anders dan de workshops die je gewend bent. Ze dagen je uit om open en creatief te zijn en ‘out of the box’ te denken. Deze manier van werken zorgt voor het versnellen van het requirementsproces, een beter onderbouwd resultaat, meer betrokkenheid, breder draagvlak, nieuwe energie en een creatieve impuls. Hierdoor verbetert de kwaliteit van de business requirements. Andere verbeteringen zijn:
• Verbeterde samenwerking business en it;
• Verbeterde en onderbouwde besluitvorming;
• Meer draagvlak bij business voor resultaat.
Kortere doorlooptijd, minder kosten door:
• Meer focus bij betrokkenen (weg van werkplek en alle andere issues);
• Versnelling van het review en goedkeuringsproces;
• Minder beslag op kritische resources (proceskennis);
• Effectievere tijdsbesteding alle betrokkenen;
• Herhaalbaar proces voor nieuwe productontwikkelingen.
Moderatie is een methode voor het faciliteren van een gemeenschappelijk requirementsproces, gericht op het creëren van een gezamenlijk begrip, gemeenschappelijke doelstellingen en gedragen oplossingen. De moderatie methode is met name sterk in het betrekken van alle deelnemers en hun meningen, zodat de oplossingen die bepaald worden een groot draagvlak hebben. Visualisatie van onderwerpen speelt een belangrijke rol om de bijeenkomst te structureren en de snelheid erin te houden.
Stakeholders managen in het requirementsproces
Een stakeholder is een individu of een groep die een belang heeft in en invloed heeft op het requirementsproces, in de requirementresultaten en de baten. Het is vitaal voor het succes van een requirementsproces dat de stakeholders op een juiste wijze benaderd worden.
Om goed te begrijpen wat er speelt, is het raadzaam om de ‘vraag achter de vraag’ boven water te krijgen. Stel gerichte, open vragen aan stakeholders en gebruik daarbij het bruggetje van de 7 W-s: Wie, Wat, Welke, Waar, Waarom, Wanneer en Waarmee. De stelregel is dat bij de derde open vraag de echte motivatie boven water komt.
Deze fase is hét moment om al bestaande requirements kritisch door te nemen en waar nodig en mogelijk aan te passen. Wees vooral alert op requirements die worden omschreven als een oplossing. Dit zijn vaak requirements die ‘hoe’ beschrijven in plaats van ‘wat’.
Een aanpak voor het opstellen van requirements
Samenvattend zijn er een aantal belangrijke conclusies die het succes van het requirementsproces zullen verhogen. Deze zijn:
• Stel requirements op en betrek gebruikers/klant, expert en andere partijen bij de ontwikkeling van de requirements.
• Gebruik tests/reviews en inspecties om ervoor te zorgen dat de opgeschreven requirements van goede kwaliteit zijn.
• Weet wie je stakeholders zijn, verdiep je in de stakeholders en stel vragen om te achterhalen wat er werkelijk speelt.
• Hou naast informele gesprekken ook formele sessies.
• Maak de herstelkosten concreet voor de gebruiker.
• Klanten, maar ook de consultant, weten niet wat de requirements zijn, innoveren is een creatief proces. Wees creatief en ga met de gebruiker samen requirements opstellen.
• Investeer in de ontwikkeling van competenties en vaardigheden om requirements op te stellen.
Bedrijven streven naar een goede uitvoering van het proces en steeds vaker kijken ze naar competentieontwikkeling van mensen die requirements opstellen. Organisaties besteden veel tijd en inspanning aan de juiste uitvoering van het requirementsproces. Uit een onderzoek uit 2010 blijkt dat 84 procent van de ondervraagde organisaties erkent dat goede requirements veel of zelfs heel veel bijdragen aan het succes van een project.
64 procent van de organisaties heeft een standaard requirementsproces, maar het kost ze nog veel moeite om dit proces in praktijk te hanteren. Daarom wordt de afstemming en uitvoering van een gemeenschappelijk requirementsproces door de hele organisatie heen als verbeterpunt genoemd.
De ondervraagde bedrijven erkennen ook het belang van het definiëren van goede requirements. Zij gebruiken reviews en inspecties om ervoor te zorgen dat de opgeschreven requirements van goede kwaliteit zijn. De meeste reviews (57 procent) worden informeel gehouden. Bovendien blijkt uit het onderzoek dat de review-deelnemers naast de klanten voornamelijk uit de technische hoek komen.
Er zijn weinig reviews uitgevoerd met andere business analisten of requirements engineers (46 procent van de organisaties nodigt hen uit voor een review-sessie), die zouden kunnen bijdragen aan het verbeteren van de kwaliteit van de requirements. Het schrijven van goede requirements hangt dus sterk af van de vaardigheden van professionals die het werk verrichten. Het investeren in de ontwikkeling van deze vaardigheden wordt genoemd als een derde belangrijke verbeterpunt die organisaties erkennen.
