Requirements management is vooruit denken

17 November 2014
Categorie:
1051

Bij het implementeren van informatiesystemen zijn goede requirements essentieel. Of je nu zelf software gaat bouwen of dat je standaard software koopt, zonder goede requirements die zijn afgestemd met de business weet je nooit of de software bijdraagt aan de doelen van de organisatie. Het is dan ook onontbeerlijk om een goed requirements management proces in te richten, van waaruit eisen en richtlijnen worden gesteld aan projecten die de informatiesystemen bouwen en implementeren. 

 

Toch komt het in de praktijk vaak voor dat requirements over het hoofd worden gezien, of dat requirements niet of verkeerd worden geïmplementeerd. In het ergste geval leidt dat tot een informatiesysteem dat niet het probleem oplost waarvoor het oorspronkelijk geïmplementeerd werd. 

 

De oorzaak hiervan ligt vaak in het feit dat er geen formeel proces is om requirements te verzamelen, documenteren, prioriteren, beheren en traceren gedurende hun levenscyclus. Soms wordt er aan het begin van een project nog wel een lijstje met requirements opgesteld, maar daar wordt dan pas weer naar gekeken als de testers komen vragen naar de requirements op basis waarvan ze het informatiesysteem moeten testen. Men wil vaak te snel aan het bouwen en implementeren, waardoor requirements management onderbelicht wordt. 

 

Eigenlijk is dat vreemd. Als we een huis gaan bouwen, denken we ook eerst na over de locatie, over het bouwmateriaal, over de grootte van het huis, over de indeling van het huis en hoeveel kamers we willen, of we een tuin willen of niet, enzovoorts. Dit levert allemaal requirements op, waarmee de architect aan de slag kan voor het ontwerp.

 

Bij het ontwikkelen en implementeren van informatiesystemen moeten we eigenlijk net zo te werk gaan. Er zijn een aantal randvoorwaardelijke zaken waar goed over nagedacht moet worden en waarover dingen afgesproken moeten worden. Om er een aantal te noemen:

 

  • Stakeholders. Het is belangrijk om vooraf te bepalen wie de stakeholders zijn van het project en het te implementeren informatiesysteem. Zij vormen de voornaamste bron voor requirements en prioritering van requirements en bepalen uiteindelijk of het informatiesysteem in productie genomen kan worden.
     
  • Proces. Het is goed om vooraf na te denken over het proces om tot requirements te komen en daarover afspraken te maken. Begin bijvoorbeeld met het verzamelen van high-level business en stakeholder requirements. Die kan je vervolgens vertalen naar functionele en non-functionele requirements, die je kan prioriteren met de betrokken stakeholders. Tijdens de bouwfase moeten de requirements bijgehouden worden zodat inzichtelijk is wanneer aan welke requirement gewerkt wordt en in welke release ze meegenomen worden.
     
  • (Centrale) opslag. Requirements moeten op een eenduidige wijze worden gedocumenteerd, op een plek waar ze door iedere betrokkene gevonden kunnen worden. Bij voorkeur in een tool met centrale database, waar de status van requirements bijgehouden kan worden en van waaruit requirements geïmporteerd en geëxporteerd kunnen worden. 
     
  • Traceerbaarheid. Traceerbaarheid heeft te maken met de relaties tussen requirements en zorgt voor minder werk bij het analyseren en doorvoeren van wijzigingen op requirements. Het traceren van requirements kan voorwaarts (van business requirement naar software requirement naar test case) en achterwaarts (van testcase terug naar business requirement) gebeuren. Gezien het grote aantal relaties tussen requirements is het verstandig om alle relaties tussen requirements direct aan te leggen bij het vastleggen van de requirements.
     
  • Acceptatiecriteria. Acceptatiecriteria zijn meetbare condities waaraan een informatiesysteem moet voldoen om in productie genomen te worden. Van elke requirement moet dus beschreven worden op welke wijze getoetst kan worden of de requirement door het informatiesysteem wordt ingevuld.
     
  • Prioritering. Sommige requirements dragen meer bij aan de uiteindelijke oplossing dan anderen. Deze must-have's zullen dus eerst moeten worden geïmplementeerd, voor alle andere requirements. Requirements moeten dus geprioriteerd worden. Omdat prioritering geschiedt op basis van de toegevoegde waarde van een requirement voor de business, is het belangrijk dat de (business) stakeholders betrokken zijn bij de prioritering. 
     
  • Impact. Van elke requirement moet bepaald worden wat de impact op de business is als de requirement wordt geïmplementeerd, maar ook wat de impact is als de requirement níet geïmplementeerd wordt. Naast dat dit helpt in het bepalen van de prioritering, zorgt het er ook voor dat er passende maatregelen getroffen kunnen worden als een requirements uiteindelijk niet door het informatiesysteem ingevuld kan worden. 
     
  • Er zijn uiteraard nog tal van zaken waarover men moet nadenken voordat begonnen kan worden aan het ontwerpen van een nieuw informatiesysteem. Bovenstaande punten vormen echter de basis voor veel andere beslissingen die genomen moeten worden en geven projecten handvatten om een goed requirements management proces in te richten. 

Auteur

Michail Theuns