Mirjam van den Berg beschrijft in de pocket "Helder wensen en eisen! vijf stappen voor het opstellen van requirements en beschrijft een requirementsmodel bestaande uit vijf soorten requirements (door haar dus 'wensen en eisen' genoemd). Hieronder mijn samenvatting.

Van den Berg begint met het betogen dat in de dagelijkse praktijk de slechte kwaliteit van eisen en wensen resulteert in: (a) projecten die voortijdig stoppen, (b) gebrekkig software, (c) veel herstelwerk en -kosten, en (d) overbodige functionaliteit.

De oorzaak van slechte requirements ligt vaak in de gebrekkige communicatie tussen de belanghebbenden, waarbij het vaak misgaat omdat men aanneemt te begrijpen wat de ander bedoeld. Oftewel typisch een geval van aannames als 'mother of all fuck ups'.

Dat het beter kan en moet is vooral een kwestie van meer aandacht besteden aan het ontwikkelen van requirements. Zich baserend op de Wet van Boehm, benoemt Van de Berg dat de kosten van een ontwikkeltraject exponentieel dalen naarmate meer tijd en aandacht wordt besteed aan het ontwikkelen van eisen en wensen.

De vijf stappen die volgens Van den Berg gevolgd moeten worden (om aannames en miscommunicatie te minmaliseren) zijn:

1. Maak een indeling in soorten wensen en eisen (vanuit behoeften).

2. Beschrijf elk soort wens en eis volgens eigen kenmerken: de juiste gegeven opschrijven voor de verschillende soorten wensen en eisen.

3. Luister actief! Vraag door! (toepassen van communicatietechnieken)

4. Stel een verklarende woordenlijst op.

5. Toets de eisen en wensen (fouten, aannames en verwarring zo snel mogelijk via review (informeel) of inspectie (formeel) achterhalen).

Volgens Van den Berg bestaat het proces voor het opstellen van wensen en eisen uit (minimaal) vijf fasen:

1. Identificeren en analyseren van de belanghebbenden.

2. Identificeren van wensen en eisen.

3. Specificeren van wensen en eisen.

4. Inspecteren van wensen en eisen.

5. Autoriseren van wensen en eisen (door belanghebbenden).

Van den Berg definieert wensen en eisen als: "heldere en duidelijke beschrijvingen van de verwachtingen van belanghebbenden betrokken bij een project aan het eindresultaat en/of aan het proces om tot het eindresultaat te komen." Een eis heeft hierbij voor een belanghebbende een hogere prioriteit dan een wens. De wensen en eisen geven (alleen) antwoord op de vraag 'Wat' met het te realiseren eindresultaat moet worden bereikt. Het is dus oplossingsvrij. Een oplossing geeft namelijk antwoord op de vraag 'Hoe' dit dan moet gebeuren. In de woorden van Van den Berg:

"Oplossingen zijn dus geen wensen en eisen! Integendeel zelfs. Wensen en eisen vormen de basis voor het in kaart brengen van alle mogelijke oplossingen. Daarna zal de beste oplossing gekozen moeten worden. Bij die keuze die moet een afweging worden gemaakt tussen de mate waarin een oplossing bijdraagt aan het doel dat moet worden bereikt én de kosten om de gewenste oplossing te realiseren."

Dé reden om wensen en eisen ook écht oplossingsvrij te formuleren is dat anders het risico dreigt dat allerlei alternatieven over het hoofd worden gezien. Van den Berg geeft als tip twee controlevragen om te beoordelen of er geen sprake is van een oplossing: (1) Komt het woord 'hebben' voor in de geformuleerde wens of eis?, (2) Stel de vraag: "Kan het ook nog op een andere manier? Als één van beide vragen met ja kan worden beantwoord gaat het vaak om een oplossing en is het nodig de behoefte achter deze oplossing te achterhalen (door de vraag te stellen: "Waarom heb je ... nodig?). Oplossingen kunnen wel als aanbeveling worden meegegeven bij de requirements.

Volgens Van den Berg is geen eenduidige indeling in requirements (bijv. "waarom" (business), "wat" (user) en "hoe" (system), "functioneel" vs. "niet-functioneel") en wordt nog vaak onterecht gedacht dat de business alleen eisen en wensen zou mogen aangeven die gaan over het "Waarom" en de ICT-afdeling alleen mogen aangeven welke wensen en eisen zij stelt aan het systeem. Van den Berg stelt dat de business wel degelijk wensen en eisen kan hebben over de manier waarop het gewenste eindresultaat moet worden gerealiseerd (geformuleerd in termen van randvoorwaarden), terwijl ook ICT wensen en eisen kan hebben ten aanzien van het wat (bijv. keuze nieuw besturingsplatform).

Verwarring over wie welke soorten eisen mag stellen, is - aldus Van den Berg - te voorkomen door de volgende vijf categorieën wensen en eisen te onderscheiden:

1. Behoeften: wat wil je ermee bereiken? Beantwoorden de vragen wat men wil bereiken en welke behoeften vervuld moeten worden .

2. Benodigdheden: wat - vaak gaat het om een product - heb je nodig om de behoefte te vervullen?

3. Functies; wat moet een product kunnen doen.

4. Kwaliteiten: hoe goed moet een product de functies kunnen uitvoeren? In welke mate moet de functie aanwezig zijn? (bijv. op het gebied van werking, veiligheid, verschijning, bruikbaarheid)

5. Randvoorwaarden: vooraf gestelde grenzen aan de oplossing(srichting).

Van den Berg visualiseert de vijf categorieën schematisch door middel van een 'piramide aan eisen en wensen', waarbij alle eisen en wensen moeten bijdragen aan het beoogde eindresultaat (de behoefte). De concrete en meetbare resultaten die men wil bereiken staan centraal. Volgens Van den Berg wordt in de prakijk vaak wel aandacht wordt besteed aan de benodigdheden en de functies, maar dat er weinig tot geen aandacht is voor de behoeften (als het eindresultaat dat bereikt moet worden met de onderliggende functies) en de kwaliteiten (hoe goed moeten de functies worden uitgevoerd). Door behoeften en kwaliteiten wél te beschrijven, kun je vooraf al bepalen óf wensen en eisen überhaupt bijdragen aan het eindresultaat en zo ja, is het mogelijk vooraf deze wensen en eisen te prioriteren (naar hun bijdrage aan het eindresultaat). Bijkomend voordeel is dat je ook beschikt over betere acceptatiecriteria.

Ad (2)  Beschrijf elk soort wens en eis volgens eigen kenmerken

Elk soort wens en eis heeft eigen specifieke kenmerken:

Functies

• Omschrijf elke functie kort en bondig in één zin
• Gebruik één kernwerkwoord per zin (dat de vraag beantwoord wát het product moet doen!)
• Beschijf elke functie 'uniek': controleer combinaties van 'verwachtingen' door formulering te screenen op het gebruik van het woord 'en'.
• Verschaf extra achtergrond (bijv. herkomst)
• Ken een prioriteit toe aan een functie
• Definieer de betekenis van in de formulering gebruikte termen en/of afkortingen (bij functie óf in verklarende woordenlijst)

Kwaliteit

• Gebruik één bijwoord (dat antwoord geeft op de vraag hoe goed de functie moet worden uitgevoerd óf het product moet zijn)
• Geef expliciet aan bij welk product of functie de kwaliteit hoort
• Maak de kwaliteit meetbaar (meetschaal, -eenheden en -methode + norm(en))
• Geef indien nodig en relevant extra achtergrondinformatie

Randvoorwaarden

• Beschrijf per randvoorwaarde concreet aan welke norm exact moet worden voldaan

Behoeften

• Maak de behoefte meetbaar (meetschaal/-eenheden en - methode + norm(en))

Ad (3) Luister actief! Vraag door!

Van de Berg stelt dat door gebruik te maken van vijf vraagtechnieken de benodigde informatie van de belanghebbenden kan worden verkregen:

• Stel open + gesloten vragen: open vragen beginnen met een vraagwoord (wie, wat, hoe, waarom, waar, wanneer, waarmee, enz.)
• Stell toekomstgerichte vragen (problemen in het heden en verleden => wat wil men niet, toekomst => wat je wél wil)
• Stel abstraherende + concretisererend vragen (afwisseling in abstractieniveaus; voorkom dat je een oplossing concretiseert)
• Stell vragen die kaders afbakenen (voorkomen woorden die niet eenduidige zijn: > 1 betekenis, generalisaties ('altijd') of vaag ('modern')
• Zorg voor afwisseling in de vragen (schakelen tussen vraagtechnieken, abstractieniveaus)

Bron: Heldere wensen en eisen! 5 Stappen om aannames te voorkomen bij Business én ICT (2011), Mirjam van den Berg