Waarom Requirementsmanagement

Requirements inventariseren, ontwikkelen, opstellen is al enige jaren een soort nieuwe ‘sport’ of ‘hype’, maar waarvoor zijn die 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, enz. Het bestek is enerzijds een nadere specificatie van de bouwtekening (architectuur), maar anderzijds ook een aanvulling van eisen/wensen die niet uit de bouwtekening vallen af te lezen.
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 requirements?

Misschien moeten we eerst de vraag stellen: van wie zijn de requirements?
In veel gevallen worden requirements opgesteld en beheerd door een afdeling funtioneel 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 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

Requirements beheren

Bij verandering en vernieuwing van bedrijfsprocessen en informatievoorziening zal het nodig zijn bestaande requirements aan te passen of te verwijderen en nieuwe requirements toe te voegen.
Dit is een continu proces aangezien de business ook continu verandert.

Boeken over dit onderwerp

Exam Ref 70-346 Managing Office 365 Identities and Requirements

Auteur: Orin Thomas
Prepare for Microsoft Exam 70-346-and demonstrate your real-world mastery of the skills needed to provision, manage, monitor, and troubleshoot Microsoft Office 365 identities and cloud services.
Europrijs: 38,95
Bestellen

Grip op Requirements

Auteur: Jan Jaap Cannegieter
In dit boek lees je welke best practices en internationale standaarden je daarbijkunnen helpen. De afgelopen decennia is requirementsengineering uitgegroeid tot een volwassen vakgebied.
Europrijs: 39,5
Bestellen

Meer boeken over requirements vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Functionele systeemeisen 13 vragen.
Systeemeisen interne controle 17 vragen.
Systeemeisen beveiliging 8 vragen.
Systeemeisen hardware 4 vragen.
Systeemeisen performance 6 vragen.
Systeemeisen onderhoudbaarheid 1 vragen.
Algemene systeemeisen 28 vragen.
Beveiligingseisen personeel 39 vragen.
Sidebar