Goede requirements opstellen

In dit artikel volgt een toelichting op de eigenschappen van goede requirements. In het artikel Requirementsmanagement is een beschrijving opgenomen waarvoor requirements worden opgesteld en welke type requirements er zijn. Dit artikel richt zich op de klassieke requirements, binnenkort volgt een vergelijkbaar artikel over User Stories (requirements voor Scrum/Agile ontwikkelproces).

De basis is dat goede requirements compleet, correct, realiseerbaar, waardevol, geprioriteerd, ondubbelzinnig en testbaar zijn. Daarbij moet de juiste inforamtie bij requirements vastgelegd zijn, in de taal van de gebruiker en met een detaillering die aansluit bij het project. Deze onderwerpen worden puntsgewijs toegelicht:

  1. De basis: compleet, correct, haalbaar, waardevol, geprioriteerd, eenduidig en testbaar
  2. Wat leg je vast van een requirement
  3. Hoe gedetailleerd leg je requirements vast
  4. Klant- of systeemperspectief/taal van de klant.
De inhoud van dit artikel is gebaseerd op eigen ervaring en het werk van Karl Wiegers (Software Requirements), Marin Arendsen et. al. (Succes met de requirements) en Mike Cohn (User stories applied for Agile software development).

1. De basis

Compleet: een requirement beschrijft alle informatie die nodig is om een goede wijziging door te voeren. Op het hoogste niveau betekent dit dat business requirements de juiste informatie bevat voor scoping en richting van de wijziging en op een lager niveau dat de gebruikersrequirements de juiste informatie bevatten voor de ontwerpers om de wijziging te specificeren.

Correct: Alle requirements dienen te beschrijven wat er gevraagd wordt. Daarbij worden gebruikersrequirements getoetst aan business requirements en functionele requirements aan gebruikersrequirements. Bij een conflict dienen de requirements op lager niveau aangepast te worden.

Realiseerbaar: Het dient mogelijk te zijn om requirements te implementeren binnen de beperkingen van de (systeem-)omgeving. Het is beter om onhaalbare requirements snel in het proces te identificeren om daarmee verspilling van capaciteit en onrealistische verwachtingen te voorkomen. Een middel is een nauwe samenwerking tussen business en ontwerpers gedurende het opstellen van requirements.

Waardevol: Ieder requirement dient bij te dragen aan de waarde van de wijziging voor de klant of eindgebruiker.

Geprioriteerd: Prioriteit bepaalt de volgorde waarin requirements geďmplementeerd worden. Prioriteren kan in twee vormen: 1) opnemen van een ´minimale´ set ("must haves"), waarbij minder belangrijke requirements worden geďmplementeerd op basis van beschikbare capaciteit of 2) opnemen van requirements, op basis van beschikbare tijd, gerangschikt in volgorde van wenselijkheid (bijv. iteratieve aanpak). Onafhankelijk van de keuze, is het handig om een eerste grove indeling te maken in wat voor de organisatie zeer belangrijk is en wat minder. De bekendste indeling is MoSCoW waarin de volgende vier categorien worden gebruikt:

  1. M - Must haves : dit betekent dat de wijziging niet zonder dit requirement geimplementeerd mag worden, bijv in geval van een auto "de chauffeur zal het vehicel kunnen afremmen".
  2. S - Should haves : betekent dat er zwaarwegende redenen zijn om dit requirement op te nemen in de wijziging, maar dat implementatie zonder dit requirement mogelijk is, bijv in geval van een auto "de chauffeur zal de spiegels af kunnen stellen op zijn lichaamshouding".
  3. C - Could haves: deze eisen komen aan bod als er (voldoende) tijd is, in geval van een auto "chauffeur zal de muziekverzameling van thuis af kunnen spelen in vehicel"
  4. W - Won't haves : houdt in dat de implementatie zonder dit requirement geimplementeerd moet worden. Uiteraard is het niet de bedoeling om een uitputtende lijst van Must not's te maken, wel is het goed om inzichtelijk te maken wat de wijziging nietinhoud.
'Should -'en 'Could haves' worden bij voorkeur geprioriteerd op basis van een kosten/opbrengsten analyse: wat kost het implementeren en wat levert het geïmplementeerde requirement op.

Ondubbelzinnig: Requirements dienen op één manier geďnterpreteerd te kunnen worden. Schrijf daarom requirements in een eenvoudige, precieze en eenduidige wijze, met een enkelvoudige betekenis. Indien veel gespecialiseerde woorden worden gebruikt, voorkom je misverstanden door het aanleggen van een woordenlijst. Een goede analist zorgt dat dit niet ten koste van de leesbaarheid gaat.

Testbaar (verifieerbaar): Analyseer vroeg in het proces of de requirements testbaar zijn, middels een peer review, storyboard, demo, pilot of testscenario. Ieder requirement dient eenduidig testbaar te zijn zodat er geen discussie plaats kan vinden over het resultaat. 'Heeft de kleur rood' is testbaar, 'heeft een mooie kleur' niet.

2. Wat leg je vast van een requirement

Het is een precair evenwicht het aantal requirements attributen dat door een organisatie vast worden gelegd: te weinig vastleggen betekent het missen van informatie in het proces en te veel vastleggen betekent onnodige informatie overhead en extra kans op fouten. De minimale set attributen staat in onderstaande overzicht:

In het boek "succes met de requirements" is een lijst van 23 attributen opgenomen; een organisatie dient zelf de afweging te maken welke requirements gewenst zijn.

3. Detaillering van requirements

Detaillering van requirements hangt af van de context van een wijziging:

Minder gedetailleerd Meer gedetailleerd
  • gebruikers blijven nauw betrokken bij ontwikkelproces (bijv Scrum)
  • ontwikkelaars hebben veel domeinkennis (bijv implementatie financieel systeem)
  • systeem is een (bijna) kopie van bestaande omgeving met vergelijkbare eisen (bijv vervanging van systeem)
  • nieuw systeem wordt in pakket ontwikkeld (bijv SAP of Oracle CRM)
  • testscenario´s worden met gebruikers opgesteld
  • vroeg in het ontwikkelproces
  • Ontwikkeling wordt geoutsourced
  • project/ontwikkelteam is geografisch verspreid, zonder dat er een gemeenschappelijk online platform is ingericht
  • testscenario´s zijn gebaseerd op requirements (acceptatie criteria)
  • zeer nauwkeurige kostenschatting is nodig van minimale gewenste functionaliteit
  • requirementstracebility is vereist (bijv bij gebruik van Use Cases/RUP)

4. Perspectief waaruit requirement is geschreven

Twee mogelijkheden: perspectief vanuit de klant of vanuit het systeem. De voorkeur is afhankelijk van de organisatie/situatie: een marketing organisatie heeft de voorkeur voor het klant perspectief, terwijl technische organisaties vaker de voorkeur voor het systeem perspectief hebben. Mijn voorkeur heeft het om business en gebruikers requirements vanuit het perspectief vanuit het klant (gebruiker)perspectief op te stellen omdat dit het dichtst aansluit bij de beleving van klanten. Klanten/gebruikers kunnen dan het beste toetsen of de set van eisen correct en juist is. Het opstellen van requirements vanuit het perspectief van het systeem heeft ook zijn voordeel: het systeem dient immers aangepast te worden op basis van de requirements en hoe meer de requirements zijn toegesneden op het aan te passen systeem, hoe beter ontwikkelaars weten wat van hen wordt verwacht. In lijn met meer/minder gedetailleerde requirements is het aan te raden om meer vanuit het systeem perspectief te schrijven wanneer zeer gedetailleerde requirements worden gevraagd.

De algemene opzet van gebruikersrequirements is als volgt (Alexander and Stevens 2002): een gebruiker (rol/type) wil (een resultaat/functie) met als voordeel (doel/waarde voor de rol/type) onder de voorwaarde (kwaliteit/acceptatie criteria).