Mike van Spall (Synergio) illustreert op bovenstaande wijze het belang van goede requirements. Volgens Van Spall gaat het erom dat de requirements goed zijn, maar is het ook belangrijk om de goede requirements te hebben.

De requirements goed.....

• Formuleer requirements glashelder
• Structureer de requirements duidelijk
• Prioriteer de requirements
• Relateer de requirements aan (een deel van de) oplossing
• Wijs requirements toe aan een moment van oplevering

De goede requirements....

• Identificeer de juiste belanghebbenden en betrokkenen
• Plaats de requirements in de juiste context
• Zorg ervoor dat de requirements duidelijk traceerbaar zijn naar een doelstelling
• Zorg ervoor dat de requirements bepalend zijn voor de vorm of werking van de oplossing

Bij goede requirements goed krijgen gaat het - aldus Van Spall - om een drie-traps raket bestaande de drie vragen:

1. Waarom?: Wat zijn de doelen die gerealiseerd moeten worden cq. de behoeften waarin je wil voorzien? Voor welk probleem zoek je een oplossing?

2. Waarmee?: met welke oplossingsrichting denk je het probleem op te lossen cq. kun je invulling geven aan de onderkende behoefte(n) .

3. Wat?: over welke kenmerken van de oplossingsrichting beschikken om daadwerkelijk een oplossing te zijn voor het probleem? Wat is nodig om de doel(en) te realiseren?

.

Zie ook: Requirements volgens Synergio (2)

Bron: Presentatie Waarom SMART requirements niet altijd “smart” zijn……! door Mike van Spall (Synergio)

Ellen Gottesdiener definieert requirements engineering als een discipline binnen system en software engineering die alle activiteiten en deliverables omvat die horen bij het definiëren van producteisen. Requirements engineering bestaat uit twee onderdelen:

1. Requirements development: activiteiten voor het eliciteren (elicit), analyseren (analyse), specificeren (specify) en valideren (validate) van requirements.

2. Requirements management: activiteiten voor het ondersteunen (support) en beheersen (control) van de informatie van/over de requirements bij het opstellen van de requirements, zoals het vaststellen van een baseline, wijzigingenbeheer en het borgen van de traceerbaarheid van de requirements.

Bron: The Software Requirements Memory Jogger, Ellen Gottesdiener

In The Software Requirements Memory Jogger stelt Ellen Gottesdiener dat requirements kritisch zijn voor het succes van het eindproduct. Ook al worden er tijdens het opstellen van de requirements nog geen software getest, het uitvoeren van conceptuele testen helpt bij het ontdekken van incomplete, foutieve en onduidelijke requirements.

Software requirements worden vaak verdeeld in twee categorieën:

1. Functionele requirements: requirements die de 'vermogens' (capabilities) beschrijven van het product; dingen die het product moet doen voor de gebruikers of in staat stellen om te doen met de software. Gottesdiener noemt functionele requirements 'the doing part of software'..

2. Niet-functionele requirements: eigenschappen die het product moet hebben die misschien niet duidelijk zijn voor de gebruikers, zoals bijvoorbeeld kwaliteitsattributen (quality attributes), beperkingen (constraints) en externe koppelingen (external interfaces). Gottesdiener noemt niet-functionele requirements 'the being part of the software - de kenmerken en beperkingen voor het gedrag van de software.

Kwaliteitsattributen: eigenschappen van de softwareontwikkeling en operationele omgeving, zoals performance, capaciteit, onderhoudbaarheid, portabiliteit, betrouwbaarheid en usability.

Ontwerp- en implementatiebeperkingen: beperken hoe de software kan worden ontworpen (bijv. maximaal aantal actieve gebruikers), de omgeving waarbinnen de software zal functioneren of een voorgeschreven programmeertaal.

Externe koppelingen: interfaces met andere systemen (hardware, software en menselijk).

Volgens Gottesdiener zijn er drie niveaus van requirements:

1. Business requirements: de requirements die gerelateerd zijn aan de business (Waarom wordt het project ondernomen?). Verklaringen (statements) over de business rationale voor het autoriseren van het project. Ze geven aan wat men met de software wil bereiken in termen van (de bijdrage aan) bedrijfsdoelen en bedrijfsstrategie. Business requirements kunnen een hoog-niveau beschrijving omvatten van de software requirements waarbij gebruik gemaakt wordt van kenmerken (samenhangend verzameling van extern zichtbare functionaliteit) om de bedrijfsdoelen (deels) mee te realiseren.

2. User requirements: requirements die gerelateerd zijn aan de gebruikers van het systeem (Wat kunnen de gebruikers met het systeem doen?). Definities van de eisen aan de software vanuit het perspectief van de gebruiker. User requirements beschrijven de taken die de gebruiker met de software moet kunnen uitvoeren en de benodigde kwaliteitskenmerken van de software. Volgens Gottesdiener zijn user requiremetns de brug tussen de bedrijfsdoelen (uitgedrukt in business termen) en de gedetailleerde software requirements (uitgedrukt in meer technische termen).

3. Software requirements: requirements die de software zelf beschrijven (Wat moeten ontwikkelaars bouwen?). Gedetailleerde beschrijvingen van alle functionele en niet-functionele eisen waaraan de software moet voldoen om te voorzien in de behoeften van de business en de gebruikers (binnen de grenzen van de gestelde ontwerp- en implementatiebeperkingen). Door middel van de software requirements bereiken de techneuten en de business overeenstemming over wat het product moet doen.

Bron: The Software Requirements Memory Jogger, Ellen Gottesdiener

Jan Hendrik Stam stelt in zijn artikel “Nut en noodzaak van business requirements” (Computable, 16/12/2012) dat door aandacht te besteden aan het vaststellen van business requirements veel hoofdpijnpunten voorkomen kunnen worden: “De toepassing van business requirements is daarmee bittere noodzaak. Groot voordeel: het is echt geen rocket science.”

Stam maakt onderscheid tussen twee niveaus van requirements: (1) ‘gedetailleerde requirements’ en de ‘requirements van een hoger niveau’ (2). Het eerste niveau omvat de functional requirements (Wat moet het product kunnen?) en non-functional-requirements  (Welke eisen stellen we aan de werking?), terwijl het bij het ‘hogere’ niveau gaat om de business requirements (‘Waarom doen we dit?').

Volgens Stam richten organisaties zich bij het ontwikkelen van software vaak vooral op de functionele en niet-functionele requirements en wordt er minder tot geen aandacht besteed aan de business requirements. Dit terwijl de business requirements juist van belang zijn om vooraf helder te krijgen wat de business eigenlijk wil bereiken. Bezinnen vóór het beginnen lijkt logisch, maar volgens Stam blijven organisatie vaak het antwoord schuldig op deze vraag en wordt desondanks de ontwikkeling toch voortgezet. Het verwaarlozen van de business requirements is niet zonder risico: dure of uitlopende projecten, oplossingen die duur zijn in het gebruik of oplossingen die überhaupt niet wordt gebruikt.

De nieuwe software moet – als het goed is – een oplossing bieden voor een probleem. Business requirement zijn noodzakelijk om vooraf helder te maken waaraan de nieuwe oplossing moet bijdragen. Stam spreekt in dit verband over een ‘continue heroverweging’, waarbij twee afwegingen noodzakelijk zijn: (a) hoe verhouden de kosten van de oplossing zich tot de baten, (b) zin er omstandigheden en/of ontwikkelingen in de buitenwereld die reden zijn om de business requirements bij te stellen. Stam ziet business requirements als hulpmiddel om het bestaansrecht van een project doorlopend te blijven toetsen.

“Als gevolg van die continue heroverweging kan blijken dat het niet zinvol is om met de ontwikkeling door te gaan. Het voordeel is dat je dat dan in een vroeg stadium kunt signaleren. Het alternatief is bovendien onwenselijk: als je je tijdens de ontwikkeling niet stoort aan wat er in de buitenwereld gebeurt kan het gebeuren dat de uiteindelijke oplossing bij voltooiing volledig obsoleet blijkt te zijn.”

Volgens Stam hebben bij het opstellen van requirements de verschillende belanghebbenden (stakeholders) vaak verschillende, zelfs conflicterende belangen hebben. Het is zaak te kom tot een set aan requirements “die voor alle stakeholders acceptabel is, waarbij ook meteen gezegd is dat niet iedere stakeholder helemaal gekregen heeft wat hij van origine wenste”. Stam stelt dan ook: “Goede communicatie met stakeholders, maar ook tussen stakeholders onderling is een voorwaarde voor een complex aan requirements waarmee iedereen kan leven en dat een oplossing oplevert die echt bijdraagt aan de business.”

“De vertaling van business requirements naar een werkbare oplossing zal onherroepelijk betekenen dat niet iedereen krijgt wat hij wilde. (…) Sommige requirements zullen organisatiebreed gedeeld worden, maar andere zullen conflicteren. Stakeholders moeten daarom in staat zijn het belang van hun eigen onderdeel voor de business goed in te schatten, vooral ook in verhouding tot de organisatie als geheel. Dat betekent dat het eigen belang niet overschat moet worden, maar zeker ook niet onderschat. (…) De stakeholders moeten … verder kunnen kijken dan hun neus lang is en the big picture voor ogen houden.”

Naast het belang van goede requirements en welwillende stakeholders, is het – aldus Stam – ook nodig om op managementniveau weloverwogen requirements bij te stellen bij veranderende omstandigheden. “Elke verandering heeft meestal ook een financiële dimensie. Met andere woorden: er moet vaak geld bij. Het management moet in principe bereid zijn die investering te doen. Voordeel daarbij is wel dat die financiële injectie - middels business requirements - valt te verantwoorden en niet, zoals in veel gevallen, in een zwart gat wordt gekieperd.”

Tot slot, bepleit Stam ("Om te borgen dat het eindproduct maximaal bijdraagt aan de business") de requirements van alle stakeholders vast te leggen in een zgn. requirements traceability matrix. Met deze matrix is het niet alleen mogelijk inzichtelijk te maken welke requiremetns voor welke belanghebbenden belangrijk zijn, maar kan ook worden aangegeven hoe requirements zich tot elkaar verhouden.

Bron: Nut en noodzaak van business requirements, Jan Hendrik Stam (Capgemini) in Computable, 16/12/2012

In hun boek Precies volgens plan!, Succesvolle IT-projecten met heldere requirements gaan Mark Hoogveld, Jan Willem Knop en Marcel Schaar in op de relatie tussen heldere requirements en het succes van een IT-project. Hieronder een samenvatting van het eerste hoofdstuk.

Omdat bij informatie-intensieve organisaties de ict nauw verweven is met de bedrijfsvoering, hebben veranderingen in de ICT rechtstreeks invloed op de bedrijfsvoering van een organisatie. Grote veranderingen vinden veelal plaats middels programma’s en projecten. Een ICT-project is succesvol te noemen als het de informatievoorziening zodanig heeft veranderd dat deze de beoogde bijdrage aan de bedrijfsdoelstellingen levert. Randvoorwaarde is vanzelfsprekend dat deze bijdrage binnen de grenzen van tijd, geld en kwaliteit (inclusief de functionaliteit) gerealiseerd moet worden, de zgn. duivelsdriehoek.

Mark Hoogveld, Jan Willem Knop en Marcel Schaar baseren zich op Aart J. van Dijk, gepromoveerd op een onderzoek naar succes- en faalfactoren bij ict-projecten, die een project als succesvol definieert wanneer geldt dat het doel van de verandering wordt bereikt door (a) realisatie van de afgesproken kwaliteit (inclusief functionaliteit); (b) de geplande doorlooptijd met maximaal 50 procent wordt overschreden, geaccordeerde scopewijzigingen uitgezonderd; en (c) de kosten voor de verandering met maximaal 50 procent worden overschreden, geaccordeerde scopewijzigingen uitgezonderd (‘overrun’).

Volgens Van Dijk zijn er zeven aspecten van IT-projecten die bepalend zijn voor een succesvolle afloop, de zgn. Big Hitters:

1. Goed projectmanagement

2. Realistische deadlines

3. Goede communicatie

4. Sterk en compleet requirementsdocument

5. Voldoende betrokkenheid van toekomstige gebruikers

6. Betrokkenheid en commitment van senior management

7. Voldoende professionaliteit (professionals)

Van Dijk stelt: “[g]eef aandacht aan deze Big Hitters en je maakt grote kans op een succes, verwaarloos er één van, en de kans dat je project niet succesvol wordt is haast een zekerheid.” Requirements worden niet alleen expliciet genoemd als 4e Big Hitter, maar bovendien geldt dat ze ook een cruciale rol spelen bij alle andere Big Hitters.

Volgens Hoogveld, Knop en Schaar zijn er drie pijlers van belang bij het goed (kunnen) beschrijven van requirements:

1. Belanghebbenden

2. Kwaliteit

3. Context

Ad (1) Belanghebbenden
Hoogveld, Knop en Schaar definëren requirements als de eisen die belanghebbenden stellen ten aanzien van een product. Dit kan een fysiek product zijn, maar ook een dienst, organisatie, proces, functionaliteit of systeem. Requirements zijn niets anders dan een communicatiemiddel, een gezamenlijk vastgelegd referentiekader. Binnen een project stellen requirements een projectteam in staat om een eindproduct te realiseren dat voldoet aan de eisen van de belanghebbenden. Om aantoonbaar te maken dat het eindproduct voldoet aan de requirements geven de belanghebbenden aan welke requirements zij dermate belangrijk vinden, dat ze in het eindproduct gecontroleerd moeten worden om tot acceptatie over te kunnen gaan. Deze requirements noemen we acceptatiecriteria .

Belanghebbenden zijn in te delen in drie groepen:
• huidige belanghebbenden;
• toekomstige belanghebbenden;
• transitiebelanghebbenden (projectbelanghebbenden).

Ad (2) Kwaliteit (inclusief functionaliteit )
Requirements omschrijven de eisen aan het eindresultaat; wanneer is het product, in de ogen van de belanghebbenden, goed genoeg? Ze definiëren de kwaliteit. De kwaliteitseisen zijn meestal afgeleiden van de algemene kwaliteitseigenschappen die producten kunnen hebben. Zoals bijvoorbeeld functionaliteit, veiligheid, robuustheid, gebruikersvriendelijkheid, et cetera.

Ad (3) Context
De werkelijke invulling van kwaliteitseigenschappen moet samen met belanghebbenden worden gedaan en de kwaliteitseigenschappen krijgen een specifieke betekenis binnen de context van het product. “In de context van het ontwikkelen van een informatiesysteem kan de kwaliteitseigenschap ‘veiligheid’ bijvoorbeeld resulteren in het requirement ‘Onbevoegden
mogen geen toegang hebben tot het informatiesysteem’. Binnen de context van een gastank denken we veel meer aan explosiegevaar.”

Niveaus van requirements
In de praktijk worden requirements vaak verdeeld over vier niveaus:

1. Doelstelling: welke bedrijfsdoelstellingen wil het bedrijf realiseren?

2. Business requirements: aan welke eisen moeten de organisatie en bedrijfsprocessen voldoen om de bedrijfsdoelstellingen te (kunnen) realiseren?

3. User requirements: aan welke eisen moet een deelproces voldoen en wat zijn de bijbehorende functionaliteiten, bijvoorbeeld de marketing-, sales- of financiële processen van de organisatie?

4. System requirements: aan welke eisen moeten de IT-systemen voldoen die de functionaliteiten moeten ondersteunen?

Requirements engeneering
Het voortbrengingsproces van requirements wordt requirements engineering genoemd.
Requirements engineering resulteert in vastgelegde en vastgestelde requirements.

Een van de werkpakketten in een projectplan is is het verzamelen van de wensen en eisen ten aanzien van de oplossing, eerst de user requirements en later de system requirements. Een requirements engineer krijgt als opdracht dit werkpakket uit te voeren. Een belangrijke eerste stap – na afstemming met de opdrachtgever over de opdracht en de scope, is het inventariseren van de belanghebbenden en hun belang, de belanghebbendenanalyse. De fase van het opstellen van requirements resulteert in een eisendocumt (‘programma van eisen’) dat ter goedkeuring wordt voorgelegd aan de belanghebbenden en de opdrachtgever.
De projectmanager neemt het resultaat van het werkpakket in ontvangst en tekent het af.
De goedgekeurde set requirements vormt de basis voor de volgende fasen van het project. Ze zijn het uitgangspunt voor analyses, ontwerpen, de te bouwen oplossing, de acceptatiecriteria ten behoeve van testen, et cetera. Binnen een project blijft de rol van de requirements engineer van belang bij het overdragen van requirements aan diegenen die deze nodig hebben voor het uitvoeren van hun werkpakketten. Verder beheert de requirements engineer de opgeleverde set van requirements om te borgen dat de uiteindelijke oplossing voldoet aan de eisen van de belanghebbenden en het resultaat bijdraagt aan de doelstelling van de opdrachtgever.

Bron: Precies volgens plan!, Succesvolle IT-projecten met heldere requirements Mark Hoogveld, Jan Willem Knop, Marcel Schaar (pdf-versie Hoofdstuk 1: Succesvolle IT-projecten)

Bij het uitleggen van nut en noodzaak van requirements aan collega's ontstonden spontaan de 4 B's voor het opstellen van requirements:

1. Betrek de belanghebbenden (stakeholders): "If you believe that you know the requirements better than the customer, you are part of the problem, not the solution" (Alan M. Davis)

2. Begrijp: probleem, behoefte.

3. Beschrijf het 'WAT' (en dus niet het 'HOE'); oplossingvrij, eenduidg, identifcieerbaar én uniek.

4. Beslis: valideren, prioriteren en autoriseren tót er een volledige set aan requirements is vastgelegd en vastgesteld.

Leo Kouwenhouven en Joke Peek beschrijven in het Computable-artikel "Requirements: bezint eer ge begint" de belangrijkste basics van requirements en gaan vooral in op de rol van stakeholder(s). Het artikel blijft wat mij betreft een beetje steken in algemeenheden, maar geeft wel goed inzicht in de complexiteit van het requirementsproces.

Het belang van requirements wordt ondersteund met een verwijzing naar het klassieke Chaos Report van de Standish Group en de stelling dat zonder goede requirements eigenlijk geen goede oplossing mogelijk is.

Requirements worden onderverdeeld in: functionele en niet-functionele requirements: "Functionele requirements zijn de eisen die de business aan de werking van het systeem stelt: wat moet het kunnen? Het gaat hier om functionaliteit die de organisatie in staat stelt haar werk te doen. De non-functional requirements beschrijven hoe het systeem moet werken en aan welke kwaliteitseisen het moet voldoen. Denk hierbij aan zaken zoals veiligheid, betrouwbaarheid, compliancy, compatibiliteit, beheerbaarheid en gebruikersvriendelijkheid."

Binnen het requirementsproces is het volgens Kouwenhoven en Peek belangrijk voldoende aandacht te besteden aan de rol van de stakeholders. De rol van de stakeholders is cruciaal bij het achterhalen en verifiëren van de requirements. Belangrijke aandachtspunten zijn verder dat de relevante stakeholders al vanaf het beginstadium bij een project worden betrokken en zich bewust is van zijn verantwoordelijkheden ('ownership' van de requirements en daarmee verantwoordelijk voor het uiteindelijke eindresultaat!).

Bij het achterhalen van de stakeholders via een zgn. stakeholderanalyse moet ook worden gekeken of de getraceerde stakeholders ook daadwerkelijk een goede vertegenwoordiging zijn van hun achterban (incl. mandaat) en of hij of zij beschikt over de juiste kennis en (communicatie)vaardigheden. "Die analyse moet tijdig uitgevoerd worden. Stel dat het traject onderweg is en je komt erachter dat de stakeholder stelselmatig de verkeerde input op de verkeerde gronden heeft geleverd, of dat hij alleen namens zichzelf spreekt; dan is veel kostbare tijd verloren gegaan en kun je eigenlijk opnieuw beginnen."

Kouwenhoven en Peek stellen dat bij de vaststelling van requirements stakeholders en requirements-engineers goed moeten (kunnen) samenwerken en beide partijen beschikken over de juiste vaardigheden. "En hoe goed de soft skills en hard skills van de requirements-engineers ook zijn, als de stakeholders niet hetzelfde niveau hebben wordt de vaststelling van de requirements een moeilijk verhaal. Dat is dan ook vaak de praktijk: stakeholders moeten meedoen in het requirements-proces, maar weten vaak niet wat er van hen wordt verwacht en wat ze van de requirements-engineers mogen verwachten. Opleiding kan stakeholders helpen hun verantwoordelijkheden duidelijk te maken, hun rol in te vullen en te voldoen aan de verwachtingen."

Volgens Kouwenhoven en Peek spreken requirements-engineers en stakeholders letterlijk een andere taal: "Onder requirements-engineers zelf bestaat vaak al onenigheid over het gebruikte jargon, laat staan dat de stakeholders aan kunnen sluiten op die taal van de requirements-engineers.
Het resultaat: aan de ene kant heb je de requirements-engineers die op technisch niveau precies weten hoe de vork in de steel zit, maar eigenlijk geen idee hebben van wat de stakeholders precies verwachten en willen; aan de andere kant de stakeholders die het ontbreekt aan kennis van het proces waar ze inzitten en die niet in staat zijn hun wensen en eisen op het juiste detailniveau aan de requirements-engineers over te brengen. (..) De requirements-engineer moet in staat zijn de ‘vraag achter de wens' van de stakeholder bloot te leggen, de requirements achter de gevraagde oplossing; de stakeholder moet ervan doordrongen zijn dat ook de niet uitgesproken requirement cruciaal kan zijn."

Kouwenhoven en Peek wijzen ook op het belang van een duidelijke scope van het project: "Wat beoogt de organisatie met de nieuwe oplossing? Aan de hand daarvan kun je bepalen welke requirements nodig zijn om dat doel te bereiken en welke niet. Het kan dan gebeuren dat stakeholders het moeten doen zonder allerlei nice to haves die misschien handig zijn, maar niet essentieel. Die scope ontbreekt vaak, laat staan dat het de stakeholders duidelijk is naar welk einddoel wordt toegewerkt. Stakeholders moeten met andere woorden de randvoorwaarden weten waarbinnen ze hun requirements kunnen formuleren. Dat verhoogt de kans op goede requirements."

Bron: Leo Kouwenhoven/Joke Peek, artikel "Requirements: bezint eer ge begint", Computable 29-07-2011

Volgens Guy Beauchamp is hét kenmerk van een goede business analist dat hij of zij beschikt over een analytische houding (analytical attitude). Deze houding heb je of je hebt het niet en is samen te vatten in: "Trust nothing, believe no-one, prove everything".

1. Vertrouw niets (trust nothing): dingen zijn niet altijd wat het lijkt. Doe geen aannames, maar onderzoek waar het precies om gaat en of claims worden waargemaakt.

2. Geloof niemand (believe no-one): het feit dat iets gezegd wordt door iemand met een hoge positie en/of veel materiekennis, maakt iets nog niet waar. Laat dingen bevestigen en valideer het tegen de andere informatie die je al hebt.

3. Bewijs alles (prove everything): doe je al door niets en niemand bij voorbaat te vertrouwen en alleen conclusies te trekken op basis van feiten.

Bron: http://www.requirementsnetwork.com/node/1361

I can teach anybody how to get what they want out of life. The problem is that I can't find anybody who can tell me what they want.

Mark Twain