Requirementsmanagement

Het doel van requirementsmanagement is borgen dat een organisatie de wensen en verwachtingen van zijn interne en externe stakeholders vastlegt, ontwikkelt, toetst en implementeert. Als middel zet een organisatie requirementsmanagement in waarin de organisatie twee onderdelen inricht: 1) bestuur en aanpak voor requirementsmanagement en 2) operationele processen om requirements op te stellen, te evalueren en te beheren.

In onderstaande artikel worden zowel het organiseren van requirementsmanagement als de operationele processen toegelicht. In Bijlage I zijn de functies van requirementsmanagement opgenomen.

1) Organisatie requirementsmanagement

Hierin leggen we de context van het requirements management vast (zie onderstaande afbeelding):

1. Doel -Waarom een organisatie gekozen heeft voor requirementsmanagement en wat zij hiermee hoopt te bereiken. In het doel is vastgelegd hoe de organisatie requirementsmanagement invult:

  1. Missie - wat zijn de uiteindelijke doelen van de organisatie met requirementsmanagement
  2. Visie - de ambitie op middellange termijn
  3. Doelstellingen- korte termijn doelstellingen voor requirementsmanagement
  4. KPI - wat zijn de key performance indicators waarop requirementsmanagement wordt beoordeeld
2. Bestuur- verantwoordelijkheid van bestuur is het behalen van de doelstellingen zoals opgenomen in "1. Doel". Samengevat komt het neer op - a) welke beslissingen dienen gemaakt te worden en b) wie nemen deze beslissingen.

Met bestuur van requirementsmanagement wordt geborgd dat het proces en de organisatie ingericht is om te bepalen wie, wat, waar, wanneer, waarom en hoe doet in relatie tot het ontwikkelen, implementatie en beheer van requirements. Bijzondere taken zijn:

  1. Bestuurlijk kader: wie neemt welke beslissing op basis van welke criteria
  2. Bewaken implementatie requirementsmanagement: voortgang bewaken van de implementatie van requirementsmanagement in organisatie (-onderdeel).
  3. Operationele processen, inrichting en regie:
  4. Bewaken relatie met de omgeving: afstemming met andere organisatiebrede initiatieven zoals enterprise architecture, business process management, proces modellering en mogelijke kwaliteitsverbeteringsprogramma's
3. Opstellen, evaluatie en beheer- dit is het meest zichtbare deel van requirementsmanagement: de regie over de processen om requirements op te stellen, te evalueren (veranderingsmanagement) en te beheren. Deze processen dienen bij stakeholders bekend te zijn zodat zij weten hoe nieuwe requirements ingediend/ge´mplementeerd moeten worden. Vaste onderdelen:
  1. proces opstellen requirements
  2. evaluatie requirements (veranderingsmanagement proces)
  3. beheer van requirements
Ad 3.1) In opstellen van requirements zijn de fasen opgenomen die een organisatie definieert om te komen tot requirements. Onderstaand de fasen die binnen software ontwikkeling worden gebruikt (vrij naar Karl Wiegers 2003):

Requirements opstellen begint met het verzamelen van requirements. Vervolgens worden de requirements geanalyseerd op bijvoorbeeld eenduidigheid en dubbellingen. De toets door de stakeholders is hierin belangrijk. Dan worden de requirements geprioriteerd en ten slotte gerealiseerd. Doorlopende activiteit hierin is het documenteren, presenteren en wijzigen van de requirements in de requirements bibliotheek. Het opstellen van requirements vindt in een projectenorganisatie plaats. Een toelichting op de functies van Requirementsmanagement staat in bijlage I.

Ad 3.2) Goedkeuren van de wijzigingen is het verandermanagement proces dat loopt van idee tot implementatie: beschrijft 2.1 de fasen van een requirement, dit proces beschrijft de fasen van een gevraagde wijziging(op basis van requirements). Dit proces wordt binnen veranderingsmanagement uitgevoerd.

Ad 3.3) Het beheer van requirements is een nadere uitwerking van fase 5 uit paragraaf 2.1 "Documenteren, presenteren en wijzigen". Onderstaand is een voorbeelduitwerking van het beheer van requirements opgenomen:

Het beheer van requirements heeft als activiteit een relatie met projecten en veranderingsmanagement, maar wordt separaat uitgevoerd.

4. Bibliotheek- gedocumenteerde requirements

5. Methode & techniek - beschrijving welke methode en technieken worden gebruikt bij het opstellen en beheer van requirements. De methode en technieken dienen te zijn afgestemd met de omgeving en aan te sluiten bij veranderingsmanagement en de projectenorganisatie. Binnen dit onderdeel vallen de software en templates die nodig zijn in de ontwikkel-, veranderingsmanagement en beheerprocessen. Kwaliteitsmanagement is onderdeel van methode & techniek: hiermee dient de organisatie te borgen dat vastgelegde requirements en het beheer daarvan volgens vereiste standaarden plaatsvinden. Vanuit kwaliteitsmanagement kunnen ook eisen worden gesteld aan bijvoorbeeld het proces opstellen van requirements zoals peer review of een periodieke audit.

6. stakeholder management - mensen maken het verschil: met dit onderdeel borgt de organisatie het draagvlak voor requirementsmanagement binnen de organisatie door stakeholders bij requirementsmanagement te betrekken middels:

7. Training - Cruciaal onderdeel in het slagen van requirementsmanagement om te zorgen dat gebruikers betrokken zijn bij het initiatief en weten wat van hun wordt verwacht en wat zij van het inititief kunnen verwachten. Gebruikers krijgen training in methoden en technieken en uitleg hoe de processen verlopen om requirements te ontwikkelen, implementeren en te beheren. Training is afhankelijk van de doelgroep.

Bovenstaande is een algemeen model dat per bedrijf wordt ingericht.

Bijlage I de functies van requirementsmanagement

Requirements management ondersteunt met zeven functies bovenstaande processen. De functies zijn: 1) opstellen van requirements, 2) analyseren, 3) prioriteren, 4) documenteren, 5) presenteren, 6) wijzigen en 7) beheren. In onderstaande tekst worden de functies toegelicht.

Organisatie requirementsmanagement

1) Opstellen van requirements

Requirements worden verzameld bij de relevante stakeholders van het nieuw te ontwikkelen product/dienst. In de eerste iteratie worden de business requirements verzameld en in een volgende iteratie de gebruikers, functionele, proces en technische requirements. In de business requirements legt de organisatie vast wat het doel van het nieuwe product/dienst is. Met de gebruikers, functionele, proces en technische requirements hoe dit doel te realiseren of waaraan het product/dienst moet voldoen. Een goed voorbeeld van een business requirement is de bekende oproep van Kennedy in 1961 'om voor het eind van dit decennium een man op de maan te doen landen.' Hij specificeerde hier fijntjes bij dat de persoon ook weer levend terug op aarde werd verwacht. Maar of de raket nu kippenvet of een mengsel van kerosine en vloeibare zuurstof gebruikte was voor Kennedy minder belangrijk: hij zou en moest eerder dan de USSR een bemande vlucht op de maan doen landen. Ook de hoeveelheid zuurstof, voedsel en motorvermogen zal Kennedy minder belangrijk hebben gevonden, behalve dat het genoeg moest zijn om aan zijn doel te voldoen. Naast requirement verzamelt de organisatie in deze functie ook uitgangspunten, randvoorwaarden en principes die van toepassing zijn op het nieuw te ontwikkelen product/dienst. Deze uitgangspunten, randvoorwaarden en principes kunnen betrekking hebben op organisatie, processen en techniek.
Het is aan te raden om in deze fase een eenvoudig template te gebruiken om de requirements vast te leggen. Dat vergemakkelijkt het delen van de gewenste requirements met al de stakeholders (zie best practices). Details die in deze functie (minimaal) bij een requirements worden vastgelegd zijn beschrijving, eigenaar, indiener, doel (kwalitatief) en opbrengsten (kwantitatief).
Bronnen voor requirements zijn:

Een korte toelichting op requirements (volgens Karl Wiegers, 2006, Software Requirements). Er zijn drie niveaus requirements:
  1. Business requirements (BR) - zijn de doelen die een organisatie nastreeft met het nieuwe product/dienst/project. Deze requirements zijn richtinggevend: BR's geeft antwoord op de vraag wat de organisatie met het product denkt te bereiken. Andere requirements dienen aan de BR's te worden getoetst. Doelen zijn bijvoorbeeld "verhoog rendement", "vergroot marktaandeel", etc. Business Requirements geven antwoord op de vraag waarom de organisatie een wijziging door wil voeren.
  2. Gebruikers requirements (of: "user requirements")- doelen of taken die gebruikers van de wijziging verwachten zoals "kan bestelling wijzigen" en "voert order snel in". Gebruikersrequirements geven antwoord op de vraag wat (eind)gebruikers van de wijziging verwacht. Gebruikersrequirements hebben betrekking op ICT, proces of organisatie.
  3. Functionele requirements : hierin worden de specifieke functies van het nieuwe product/dienst gedefinieerd, zoals "verwerkt credit card betaling". Geeft antwoord op de vraag hoe de business en gebruikersrequirements worden gerealiseerd.
Daarnaast onderscheiden we nog (niet volgens Karl Wiegers, wel volgens niet-ICT bronnen): Karl Wiegers classificeert requirements als functioneel of niet-functioneel (het is verwarrend om niet-functionele functionele requirements te hebben, maar ik hoop dat de uitleg het helder maakt.): Ten slotte zijn acceptatiecriteria belangrijk in het kader van business en gebruikersrequirements: als een requirement aan de acceptatie criteria voldoet, dan is de eigenaar van het requirement tevreden over de implementatie van het requirement in het nieuwe product/dienst . Voorbeeld: het requirement is "toont historie van orders" en de acceptatie criteria zijn "toont historie van alle orders van afgelopen drie jaar" en "overzicht wordt in 3 seconden getoond na opvragen". Acceptatie criteria op hogere niveaus zijn input voor proces en (niet-)functionele requirments.

2) Opstellen van requirements
Na de eerste intake analyseert de organisatie de verzamelde requirements en stelt vast of requirements voldoende duidelijk (SMART) en consistent zijn. Indien dit niet het geval is worden requirements aangescherpt en, indien conflicterend, bij de stakeholders ter discussie neergelegd om tot de definitieve (niet-conflicterende) set requirements te komen.
In deze activiteit specificeert de organisatie eventueel de Acceptatie Criteria: de eigenaar van het requirement geeft precies aan wanneer hij accepteert dat een nieuw product/dienst voldoet aan een door hem gesteld requirement.

3) Prioriteren van requirments
De definitieve set van requirements wordt geprioriteerd met als resultaat een samenhangende set requirements waarbij een werkend product ontstaat en de belangrijkste eisen het eerst ontwikkeld worden. Het prioriteren van requirements en de toepassing ervan is afhankelijk van het ontwikkelproces bijv. scrum versus waterval maar is altijd gebaseerd op opbrengsten versus kosten.

4) Documenteren
Het documenteren betreft de vastlegging van requirements. De organisatie legt de requirements vast en registreert alle belangrijke eigenschappen van het requirement. Dat is een uitbreiding op de details die al in de functie ┤verzamelen┤ zijn vastgelegd: zoals datum, versie, wijzigingen t.o.v. vorige versie, gewenste realisatie requirement en de relatie tussen requirements en andere ontwikkel onderdelen. Met dit laatste wordt bedoeld: de relatie tussen bijvoorbeeld een business requirement met een functionele requirement, een use case, een test scenario en de release. Documenteren kan in een eenvoudig Excel sheet of in een ge´ntegreerd ontwikkelomgeving zoals Enterprise Architect van SParx of de Rational Suite van IBM.

5) Presenteren
Gedurende en na het project zullen stakeholders de inhoud en status van het requirement opvragen. Het presenteren van requirements houdt in: het op laagdrempelige manier toegankelijk maken van de requirementes voor stakeholders. De vorm en vertoonde details zijn afhankelijk van de doelgroep en het beoogde doel.

6) Wijzigen
Requirements kunnen wijzigen gedurende een project. Zeker in langdurige projecten, complexe omgevingen of innovatieve productontwikkeling zal dit gebeuren. Belangrijker dan vast te houden aan de oorspronkelijke requirements is vast te leggen wat de oude eis was, wat de nieuwe eis is, wie het besluit heeft genomen om de eis te wijzigen en met welk doel. Bijvoorbeeld: was eerst de behoefte om het nieuwe product snel op de markt te brengen, maar later de behoefte om het product goedkoop te maken, dan is het belangrijk te weten wie dit besluit heeft genomen en met welk doel/argument.

Burn down Chart registratie in Excel
7) Beheren
Met beheren zorgt een organisatie dat een requirement gevolgd wordt door een project zodat de organisatie grip houdt op de implementatie van het requirement: wie is de projectleider die het requirement realiseert, in welke use case is het opgenomen, welke ontwikkelaar ontwikkelt het, wie test het en wat is het resultaat van de testen. De relevante informatie die wordt vastgelegd is afhankelijk is van de behoeft van de organisatie: 'verwachte benodigde realisatie tijd' en 'werkelijk benodigde realisatie tijd' worden door sommige organisaties gebruikt ter evaluatie, terwijl andere organisaties uitsluitend op realisatie datum sturen. Beheren houdt ook in het volgen van een requirement door de levenscyclus.
Requirements management software beschikt over beheerinstrumenten, om bijvoorbeeld de realisatie snelheid van requirements in een project te volgen: bovenstaand voorbeeld toont het aantal requirements (in Agile 'user stories') dat nog gerealiseerd moet worden en de beschikbare hoeveelheid tijd. Het project van deze burn down chart heeft een probleemů