Requirement Management

Requirements management wordt vaak “te zwaar” gemaakt. Zware tools, strak proces … dit werkt niet prettig.

Wij zien requirements management niet als doel, maar als een middel om het beoogde projectresultaat te realiseren.

De RCP is een platform waarin requirements kunnen worden beheerd. Een belangrijk aspect van dit tool is manier waarop de betrokkenheid van Stakeholders wordt bewerkstelligd.

De betrokkenheid kan worden versterkt door mensen overzicht en inzicht te geven. Requirements specificaties lijken altijd zeer droge stof, en zijn nogal uitgebreid. Mensen haken af.
Hoe krijg je ze toch betrokken bij het proces?
Door duidelijkheid, laagdrempeligheid, overzicht, context te bieden. Als dit goed is geregeld, krijg je er betrokkenheid door terug. Die betrokkenheid betaalt zich uit in requirements die beter weergeven wat de bedoeling is, en een specificatie die completer is.
“Better requirements by collaboration”

Daarnaast willen wij van Pyramid-Logic iets uit de wereld helpen: goede requirements zijn geen droge stof! Het is ook niet “technisch, IT” zoals we vaker horen!
De requirements specificatie geeft juist (in daadkrachtige bewoordingen) weer wat het projectteam gaat realiseren en om welke redenen (doelen). Elke stakeholder ziet hierin zijn aandeel terug; elke stakeholder ziet zijn eigen eisen en wensen weerspiegeld staan.
Sterker nog: wat er niet in staat, wordt niet gebouwd. Een belangrijke reden om betrokken te zijn!

Een van de lastige punten bij een requirementsanalyse is de moeilijkheid overzicht te hebben voor elke Stakeholder.
We kennen het wel: een lijvig document (bijvoorbeeld een Excel sheet) wordt aan de stakeholder voorgeschoteld:

De Opdrachtgever vraagt zich het volgende af: “Is de totale specificatie compleet? Worden alle onderdelen van de opdracht/project genoemd?”

Een representant van de Uitvoering (“de business”) vraagt zich af of zijn specifieke eisen en wensen er wel allemaal in staan. De specificatie is vaak zo groot dat het lastig is het overzicht te behouden.

Een Ontwikkelaar vraagt zich bij sommige requirements af waarom dit is gespecificeerd zoals het er staat. Wat is de reden van deze eis? Deze persoon mist context.

Een Ontwerper vraagt zich af wat de achterliggende gedachte is van bepaalde requirements. Zijn vraag zal vaak zijn of er geen conflicterende eisen zijn. Voor deze persoon zijn compleetheid en context van belang.


Stel dat er een manier is om genoemde wens van overzicht te realiseren, en alle stakeholders hebben een goed overzicht op de requirements.
Wat is dan het gevolg? Juist, de stakeholders zullen input willen geven op de requirements specificatie: Men zal requirements willen wijzigen, of nieuwe requirements willen toevoegen. Deze betrokkenheid is droom van iedere requirements engineer!
Onze visie is dat wanneer het voldoende laagdrempelig is om input te leveren, dit meer zal gebeuren.

Nu naar de oplossingen die Pyramid-Logic biedt:
- Overzicht en context in requirements
- Laagdrempelige methode om input te leveren op requirements

Overzicht en context
De twee manieren van Pyramid-Logic om in de voorbeelden genoemde vragen en onzekerheden van Stakeholders tegemoet te komen zijn:
1) groeperen van requirements door lagen model:

Pyramide van goals – business requirements – solution requirements, en zorgen voor relaties tussen requirements. Stelregel: elk requirement in een laag, moet 1 parent requirements in een hogere laag hebben.


2) categoriseren van requirements door ze een karakteristiek mee te geven:

Gebaseerd op ISO 9126, maar dan met een aantal aanpassingen (* zie verderop). Daarnaast dienen requirements SMART te zijn, en niet teveel eigenschappen te hebben. Pyramid-Logic stelt dat het doel van de requirements is: bereiken van overeenstemming over de scope van een project en de specificaties voor realisatie te verkrijgen.


Requirements moeten naast SMART zijn, niet teveel eigenschappen hebben. Dit komt de overzichtelijkheid weer ten goede. Er moet worden nagedacht welke eigenschappen van de requirements van belang zijn in welke fase van ontwikkeling. Zaken als bijvoorbeeld prioriteit zijn voor een goede en complete requirements specificatie minder van belang en dat moet je dus vermijden. (later in de realisatie fase van het project is prioriteit wel degelijk van belang, maar tijdens de analysefase werkt deze eigenschap verstorend in de discussies en leesbaarheid)

Laagdrempelige methode voor input: WIKI
De manier om via samenwerking tussen mensen overeenstemming te krijgen op een tekst, is gebruikmaken van WIKI technologie. Hierin is het voor iedere lezer van een stuk tekst mogelijk om wijzigingen door te voeren. Deze krachtige manier van tekstbeheer heeft zich bewezen op verschillende manieren, waarvan Wikipedia de meest bekende is.
Pyramid-Logic stelt voor de kwaliteit van een requirements specificatie te verbeteren door gebruik te maken van WIKI technieken.

Omdat requirements analyse een vak is wat niet door iedereen kan worden beoefend, is het van belang wat striktere regels toe te passen bij de WIKI techniek in vergelijking met de WIKI’s op het Internet. Pyramid-Logic stelt dat requirements engineers de beheerders van de requirements zijn, en dat de overige stakeholders van het project middels commentaar hun input leveren. De requirements engineers verwerken vervolgens dat commentaar in de requirements tekst.

Dit alles gebeurt online, en daarmee is de laatste status van de requirements specificatie altijd real-time inzichtelijk voor iedereen.
Een belangrijke feature van de requirements tool is dat de commentaren van de stakeholders inzichtelijk zijn voor alle stakeholders van het project. Ook voorgaande versies van de requirements zijn eenvoudig in te zien.

Deze aspecten werkt motivatie en begrip bij de stakeholders; men ziet de vorige versie van een requirement met het bijbehorende commentaar, en men ziet wat ermee is gebeurt in de nieuwe versie van het requirement. Men kan ook door commentaar van andere stakeholders getriggerd worden en inspiratie opdoen voor nieuwe commentaren. Al met al levert deze betrokkenheid een betere en meer door de organisatie gedragen specificatie op.

Uiteindelijk zijn de requirements engineers verantwoordelijkheid voor de requirements teksten; zij zorgen ervoor dat de requirements SMART zijn (specific, measurable, attainable, relevant, time-bound), voor eenheid van stijl, geen doublures van eisen, de juiste karakteristieken per requirement, de traceability naar requirements in een hoger liggende laag, etc.

Aanpak en visie rond gebruik van ISO 9126 karakteristieken.
Wat Pyramid-Logic anders doet dan gebruikelijk is: kijk niet naar requirements vanuit non-functional, of functional perspectief. Maar doe dit juist andersom: elk requirement  (na analyse, overleg met stakeholders etc.) is geldig zoals het is. Vervolgens pas hang je er een karakteristiek aan (bijvoorbeeld beheersbaarheid, of bruikbaarheid). Hierdoor wordt je niet geremd (“we gaan nu alle non-functional requirements bedenken!” werkt niet).

Zijn we compleet?
Wel helpen deze karakteristieken om te checken of de specificatie compleet is (“hebben we voldoende eisen die over beheersbaarheid gaan?”). Ook helpen deze karakteristieken het indelen van werk in het realisatie team (“geef mij even alle requirements die over usability gaan”).

Nieuwe karakteristiek: Security
Binnen de ISO 9126 wordt gesproken over functionality, met als sub-karakteristiek security. Wij zien security als een van de hoofd-typen karakteristieken. Beveiliging is iets wat op alle lagen in het model van toepassing moet kunnen zijn. Niet alleen maar in de set “functional” requirements.

Spelregels omgaan met karakteristieken: Elke requirement dat niet over reliability, usability, efficiency, maintainability, portability of security gaat, is een type functional requirement.
Je kunt meerdere karakteristieken per requirement hebben.