Waarom Requirementsmanagement

Requirements inventariseren, ontwikkelen, opstellen, Requirementsmanagement is al enige jaren een soort nieuwe ‘sport’ of ‘hype’. Maar waarvoor zijn die activiteiten eigenlijk nodig?
In de praktijk is vaak niet duidelijk waar een bepaalde requirement vandaan komt of wat er precies mee bedoeld wordt.

Onderstaand een korte uitzetting van…

• Wat zijn requirements?
• Wie is verantwoordelijk voor requirements?
• Hoe requirements ontwikkelen en beheren (het proces)?

Wat zijn requirements?

Wat requirements zijn is het gemakkelijkst uit te leggen door een vergelijking te maken met het bouwen van een huis. Daarvan krijg je meestal een bouwtekening van de architect en een bestek van de aannemer. De bouwtekening geeft via diverse tekeningen, plattegronden, voor- en zijaanzicht, snel een visueel beeld van het huis. Het bestek beschrijft de diverse onderdelen, zoals soort stenen, houtsoort kozijnen, CV-installatie, enzovoort. Het bestek is enerzijds een nadere specificatie van de bouwtekening (architectuur). Anderzijds is het ook een aanvulling van eisen/wensen die niet uit de bouwtekening vallen af te lezen.

Bedrijfsprocesarchitectuur

Verplaatsen we ons nu naar een bedrijfssituatie. Daar hebben we te maken met organisatie, processen en informatievoorziening. De bedrijfsprocesarchitectuur bevat schema’s van procesindeling, procesketens met trigger, processtappen en resultaat. De informatiearchitectuur bevat gegevensmodellen. De technische architectuur geeft de samenhang van hardware en software weer.
Ook hier zijn de schema’s onvoldoende om de requirements weer te geven. Daarom moeten aanvullend de requirements gespecificeerd worden.
De plaatjes geven dan snel inzicht en overzicht, terwijl de requirements de overige details weergeven.
Voor elke requirement is het van belang dat je weet op welke architectuur-component die betrekking heeft.

Wie is verantwoordelijk voor Requirementsmanagement?

Misschien moeten we eerst de vraag stellen: van wie zijn de requirements?
In veel gevallen worden requirements opgesteld en beheerd door een afdeling functioneel beheer en/of systeemontwikkeling. Zij moeten er natuurlijk voor zorgen dat de systemen aan de eisen voldoen. De echte eigenaar en verantwoordelijk is natuurlijk de ‘business’, ofwel de manager van een operationele afdeling. Een business-afdeling stelt business requirements op. Daarvan afgeleid worden user requirements en daarvan weer system requirements.

Requirements ontwikkelen

Requirements ontwikkelen doe je tijdens een informatieanalyse vooral MET de mensen die er belang bij hebben en die er verantwoordelijk voor zijn. In principe zijn dat de stakeholders. Zij moeten de requirements goedkeuren (valideren) en zij zijn verantwoordelijk voor aanpassingen.
Requirements ontwikkelen bestaat grofweg uit 4 stappen:

1. Inventariseren, ontdekken (eliciteren) van requirements: samen met stakeholders de requirements bepalen.
2. Analyseren: nagaan of de requirements eventueel al bestaan (zie Beheren hierna), bepalen bij welk onderwerp ze zullen worden opgenomen.
3. Specificeren (nieuwe requirements): elke requirement volledig beschrijven.
4. Goedkeuren (valideren): elke requirement met stakeholders definitief vaststellen.

Requirementsmanagement

Bij verandering en vernieuwing van bedrijfsprocessen en informatievoorziening moet er iets gebeuren met de bestaande requirements. We kunnen ze aanpassen of te verwijderen en nieuwe requirements toe te voegen.
Dit maakt requirementsmanagement, een continu proces aangezien de business ook continu verandert.

Discussieer mee op LinkedIn.