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)