In de IBM's whitepaper "Ten steps to better requirements management" worden door Dominic Tavassoli de volgende 10 stappen beschreven die een organisatie helpen om beter requirements te definiëren en managen:

1. Structureer de requirements: structuur werkt begripverhogend en voorkomt dubbelingen en omissies

2. Manage en verbind requirements met behoeften (customer needs): traceerbaarheid is van belang voor impactbepaling

3. Manage beperkingen (constraints): de zgn. niet-functionele requirements bepalen in belangrijke de kwaliteit van het systeem

4. Visualiseer requirements: het visueel modelleren is een belangrijk communicatiemiddel en faciliteert het eliciteren van requirements

5. Test de requirements: zorg ervoor dat requirements vanaf het begin goed testbaar zijn.

6. Overbrug de kloof tussen business en ontwikkeling: less is more, focus op de waarde en prioriteit van requirements voor de business.

7. Beheers de verandering van requirements: requirements zijn aan continue verandering onderhevig, zorg voor wijzigingenbeheer.

8. Volg de metrieken en trends: zorg dat alle stakeholders voortgang in/rond requirements goed kunnen volgen (bijv. via een dashboard)

9. Zorg voor voorbeelden van goede requirements: 'best practices' bevorderen de kwaliteit, consistentie en volledigheid van requirements.

10. Hergebruik requirements: waarbij je in het ideale geval een link legt met het originele requirements

Bron: Ten steps to better requirements management, Requirements Management Whitepaper, Dominic Tavassoli (Juni 2009, IBM)

Anything can be made measurable in a way that is superior to not measuring it at all.

Tom Gilb

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

Binnen de agile softwareontwikkeling vormen de zgn. user stories de aanbevolen requirementstechniek. User stories staan voor requirements verteld vanuit het gezichtspunt van de gebruikers. Belangrijk hierbij is dat de veranderbehoefte wordt weergegeven in de taal van taal van de business.

Volgens Nicode de Swart voldoen user stories bij voorkeur aan de syntax: "Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>" en geeft hierbij als voorbeeld: "Als student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb gehaald." Het gaat hierbij alleen om de korte omschrijving ter aanduiding van de user story. Het is niet de bedoeling om volledige functionaliteit al tot in detail te beschrijven. Hiervoor is een ander onderdeel de user stories bedoeld: mondelinge communicatie. 'Mondeling' omdat het veel effectiever is om detailinformatie mondeling over te dragen.

Zodra de ontwikkelaar een user story gaat implementeren is detailinformatie nodig over de gewenste werking van de user stories. De korte omschrijving is té globaal, zodat het ontwikkelteam de gebruiker (product owner) vragen moet gaan stellen. De antwoorden op de vragen worden - voor zover nodig voor de correcte werking van de te realiseren software - vastgelegd als acceptatiecriteria. Door de samenwerking tussen het ontwikkelteam en de product owner is dus ook geen analist nodig als brugfunctie tussen business en ICT.

Deze acceptatiecriteria vormen het derde onderdeel van user stories. De acceptatiecriteria hoeven - omdat er intensief wordt samengewerkt bij het implementeren van de user stories - niet volledig te zijn. De kracht van het werken met user stories is volgens De Swart dan ook dat het detailleren van requirements, het ontwikkelen van de software en het testen ervan hand in hand gaan: "De ontwikkelaar laat regelmatig aan de product owner zien wat hij gebouwd heeft. De product owner geeft feedback en samen bespreken ze wat er nog toegevoegd of gewijzigd moet worden. Aangezien een user stories in enkele dagen tot ruim een week tijd gerealiseerd wordt, is het niet nodig om naast de mondelinge afstemming nog veel te documenteren."

Onderdelen user story

1. Korte beschrijving als aanduiding van de requirement (ivm planning)

2. Mondelinge communicatie om de details te achterhalen (tijdens de realisatie)

3. Acceptatiecriteria om juiste werking vast te stellen

De kracht van user stories zit in het feit dat door de intensieve samenwerking tussen het ontwikkelteam en de product owner en de nadruk op mondelinge communicatie drie voordelen optreden:

1. Eenvoud:"Het is niet nodig (en niet wenselijk) om vooraf de gedetailleerde requirements te achterhalen en te beschrijven. Dat is maar goed ook want het is onmogelijk om de requirements (in use cases) voor 100% volledig en eenduidig te specificeren".

2. Flexibiliteit: user stories kunnen beter omgaan met voortschrijdend inzicht: "Tot aan de start van de iteratie/sprint waarin de user story geïmplementeerd wordt, heeft voortschrijdend inzicht geen negatief effect op het project".

3. Snelheid: een user story moet in maximaal 10 werkdagen geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, moeten worden opgesplitst. Kom daar maar eens om, bij een volledige use case. Het is niet langer een analist gedetailleerd requirements te laten specificeren. Verder gaat ook geen tijd verloren aan het lezen en begrijpen van gedetailleerde requirements door de ontwikkelaars en testers en is het - omdat detaillering van requirements later en mondeling plaatsvindt - niet nodig om wijzigingen door te voeren in de specificaties.

Bron: Nicole de Swart op http://www.reaco.nl/kenniscentrum/userStories.asp

Op haar website stelt Nicole de Swart dat mooi zou zijn als requirements 'just in time' kunnen worden opgesteld: "Net op tijd om te kunnen plannen en net op tijd om de software te kunnen ontwikkelen. We zouden dan geen last hebben van wijzigende requirements, geen change control board nodig hebben en geen scope creep kennen. Dit scheelt veel tijd, geld en gedoe."

In de goede oude watervaltijdperk was het de gewoonte om alle requirements ver van te voren op te stellen (up front) om vervolgens op basis van de totale set aan requirements een offerte op te stellen, een planning te maken en te kunnen starten met de ontwerp- en bouw-activiteiten. De werkelijkheid blijkt alleen wat minder voorspelbaar dan gehoopt, zodat wijzigingen in de overeengekomen requirements onvermijdelijk zijn (bijv. door veranderingen in de omgeving, voortschrijdend inzicht en/of ontbrekende requirements).

Volgens De Swart laten agile ontwikkelmethoden zien dat 'just in time' requirements mogelijk zijn. Het idee hierbij is het vaststellen (en vooral detailleren) van requirements zo lang mogelijk uit te stellen. In eerste instantie is het alleen nodig een globaal totaalbeeld te hebben dat net genoeg detail geeft om de doorlooptijd van het project in te kunnen schatten. Vervolgens worden alleen de requirements die ook daadwerkelijk moeten worden geïmplementeerd nader uitgewerkt. Ook hier geldt weer dat het detailniveau net genoeg moet zijn om de relatieve ontwikkelinspanning (niet in uren) in te kunnen schatten en een planning op te stellen voor de eerstvolgende iteratie.

"Pas als een ontwikkelaar daadwerkelijk de software voor een bepaalde requirement gaat bouwen, spreekt hij de wensen en de details door met de continue beschikbare (en fysiek aanwezige) vertegenwoordiger van de business. Met deze aanpak zijn de juiste requirements, op het juiste detailniveau, 'just in time' beschikbaar. Omvangrijke producten met uitgebreide specificaties hoeven dan niet opgesteld en niet onderhouden te worden."

Bron: http://www.reaco.nl/kenniscentrum/vanUpFrontNaarJustInTime.asp

Nicole de Swart definieert de belanghebbenden (stakeholders) bij een softwareontwikkeltraject als de personen of organisatie(onderdelen) die beïnvloed wordt door of zelf invloed kunnen uitoefenen op de uiteindelijke werking van het systeem en stelt dat belanghebbenden en requirements onlosmakelijk met elkaar verbonden zijn: belanghebbenden zijn de bron voor de requirements en bepalend voor de behoeften en eisen die vanuit de business aan het te ontwikkelen systeem worden gesteld.

De Swart maakt een onderverdeling in drie hoofdgroepen belanghebbenden (op basis van het verschil in belang dat men heeft):

1. Belanghebbenden bij het businessdoel: belang bij het verbeteren van de interne bedrijfsvoering of bij het op de markt brengen van een nieuw softwareproduct. Bijv. opdrachtgever en/of sponsor.

2. Belanghebbenden bij het systeem: belang bij, nadat het geautomatiseerde systeem is ingevoerd, de werking van het systeem, in de zin dat ze voordelen óf nadelen kunnen nadeel ondervinden van de invoering van het nieuwe systeem. Bijv. gebruikers, 'systeemondersteuners' (beheerders, helpdesk), 'autoriteiten' (juridische afdeling, IT-auditoren).

3. Belanghebbenden bij het project: werken vaak mee aan de totstandkoming van het systeem en hebben tijdens het project en vaak ook daarna nog, als het systeem in beheer is genomen, invloed op de werking van het systeem. Bijv. projectteam, ICT-afdeling, gebruikersvoorbereiders (verandermanagers, opleiders, opstellers gebruikershandleiding)

Bron: Handboek Requirements (2010), Nicole de Swart en http://www.reaco.nl/handboekRequirements/praktischeHandvatten/ChecklistBelanghebbenden.pdf

De systeemontwikkemethode Rational Unified Process (RUP) is onderverdeeld in negen disciplines onderscheiden. Requirements is één deze disciplines. Requirements als discipline maakt onderscheid tussen drie typen requirements en positioneert ze ten opzichte van elkaar in een piramide. Het volume van de piramide representeert het aantal requirements van een bepaald type.RUP plaatst requirements in het probleem- en oplossingsdomein. De needs vormen de zgn. businessrequirements. De features en de softwarerequirements gaan over de behoeften en eisen ten aanzien van het systeem. Ondanks het feit dat binnen de piramide geen gebruikersrequirements voorkomen, onderkent RUP wel use cases. Deze worden gepositioneerd bij de softwarerequirements. De reden hiervoor is dat de use cases de softwarerequirements in context plaatsen.

Binnen RUP worden zes activiteiten onderscheiden om requirements op te stellen:Binnen de discipline Requirements worden twee rollen onderkend die verantwoordelijk zijn voor het vastleggen van de functionele en niet-functionele eisen: (1) de informatie-analist, en (2) de Use Case ontwerper.

1. Analyseer het probleem: welk probleem moet worden opgelost?

2. Begrijp de behoeften (needs) van de belanghebbenden: wat wil men met het systeem bereiken?

3. Defineer het systeem: onderkennen use cases + afbakenen van het systeem

4. Manage de scope van het systeem: prioriteer features en use cases en bepaal de scope van de eerstvolgende iteratie

5. Verfijn de systeemdefinitie: specificeer use cases + aanvullende requirements op het gewenste detailniveau

6. Manage de veranderende requirements: analyseer impact van voorgestelde wijzigingen in de baseline + besluit

De rol van de informatieanalist (binnen RUP) is verantwoordelijk voor het helder krijgen van requirements en het modelleren van Use Cases, waardoor hij de functionaliteit en grenzen van het te bouwen systeem bepaalt en bewaakt. De Use Case ontwerper is verantwoordelijk voor het specficeren van Use Cases, inclusief schermontwerpen en schermverloop.

Bron: Handboek Requirements (2010), Nicole de Swart, en RUP op Maat (2008), Eef Dekker en Remi-Armand Collaris

De niet-functionele (software)requirements zijn de kwaliteitseisen waaraan een systeem moet voldoen. De ISO 9126 standaard (ISO, 2001) bevat een checklist met kwaliteitseigenschappen voor het opstellen van de niet-functionele requirements. De checklist omvat zes hoofdeigenschappen met daarbinnen subeigenschappen.

(1) Functionaliteit: hoe goed moet het systeem de gewenste ondersteuning leveren?

• Juistheid
• Geschiktheid
• Naleving voorschriften
• Beveiligbaarheid
• Koppelbaarheid

(2) Betrouwbaarheid: in welke mate moet het systeem zonder verstoringen functioneren?

• Bedrijfszekerheid
• Foutbestendigheid
• Herstelbaarheid

(3) Bruikbaarheid (usability): hoe eenvoudig moet het systeem te gebruiken zijn?

• Begrijpelijkheid
• Leerbaarheid
• Gebruiksgemak
• Aantrekkelijkheid

(4) Efficiency: hoe snel moet het systeem haar taken uitvoeren en hoeveel middelen mogen hierbij gebruikt worden?

• Snelheid
• Middelenbeslag

(5) Onderhoudbaarheid: hoe eenvoudig moet het zijn om het systeem aan te passen?

• Wijzigbaarheid
• Analyseerbaarheid
• Stabiliteit
• Testbaarheid

(6) Overdraagbaarheid (portabiliteit): in welke mate moet het systeem naar een andere omgeving overgezet kunnen worden?

• Aanpasbaarheid
• Installeerbaarheid
• Gezamenlijkheid
• Inpasbaarheid

Nicole de Swart geeft in onderstaande documenten (PDF formaat) voor alle kwaliteitseigenschappen een definitie (incl. voorbeelden en 'elicitatievragen' waarmee business analisten niet-functionele requirements concreet en tastbaar kunnen maken vor belanghebbenden):

• Functionaliteit
• Betrouwbaarheid
• Bruikbaarheid
• Efficiëncy
• Onderhoudbaarheid
• Overdraagbaarheid

Bij het opstellen van niet-functionele requirements is het van belang dat de business analist zoekt naar de belangrijkste kwaliteitseigenschappen. Volgens De Swart zijn in de praktijk vaak niet meer dan vijf tot acht kwaliteitseigenschappen echt belangrijk zijn voor een ICT-systeem en is het (dus) overbodig om voor alle kwaliteitseigenschappen niet-functionele requirements op te stellen: "Dat zou veel tijd kosten, weinig toegevoegde waarde opleveren en een saaie exercitie worden". De Swart stelt van elk systeem een bepaalde basiskwaliteit verwacht mag worden (bijv. het feit dat op schermen de responsetijd enkele seconden en niet enkele minuten mag zijn) en is het alleen nodig de 'bovengemiddeld zware en belangrijkste' niet-functionele requirements te specificeren.

Bron: Handboek Requirements (2010), Nicole de Swart en http://www.handboekrequirements.nl/non-functional-requirements/

Zie ook het artikel Softwareproductkwaliteit van Danny Greefhorst en Gert Florijn in Informatie.

Bij het opstellen van requirements gaat het erom overeenstemming te bereiken over een set requirements, de zgn. baseline. De wijze waarop deze baseline tot stand komt, is afhankelijk van het gekozen ontwikkelproces.

(1) Ontwikkelen volgens waterval-methode

Bij toepassing van de waterval-methode worden alle requirements in één keer aan het begin van het traject opgesteld, goedgekeurd en opgenomen in de baseline. Voor de start van het systeemontwerp en de realisatie zijn alle requirements bekend.

(2) Iteratief ontwikkelen

Bij een iteratief ontwikkelproces worden aan het begin van het traject aleen globale requirements opgesteld, goedgekeurd en opgenomen in de baseline. Het detailleren van de requirements gebeurt (net) voorafgaand aan de iteratie. Deze requirements worden tijdens de iteratie geïmplementeerd.

(3) Agile

In een agile-ontwikkeltraject worden voorafgaande aan de iteratie alleen globale requirements goedgekeurd en opgenomen in de baseline (product backlog genoemd). Detaillering en implementatie van de requirements vindt plaats tijdens de iteraties.

Bron: Handboek Requirements (2010), Nicole de Swart

Volgens De Swart kan een use case worden beschouwd als een requirements aangezien een use case aangeeft welke geautomatiseerde ondersteuning gewenst is. Een use case representeert namelijk de geautomatiseerde ondersteuning aan een gebruiker bij de uitvoering van een procestaak.

Een use case levert een resultaat dat zelfstandig waarde heeft voor de gebruiker en geeft aan hoe de gebruiker en het systeem samenwerken om dat resultaat te behalen. Elke use cases bestaat uit een verzameling requirements die gezamelijk nodig zijn om het gewenste resultaat te realiseren.

De use case techniek is een techniek om requirements te specificeren vanuit het businessperspectief. Een use case geeft aan hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen dat waarde heeft voor de gebruiker. Alle acties van het systeem en de gebruiker die nodig zijn om het doel van de gebruiker te halen, zijn gegroepeerd tot een use case.

De Swart definieert use cases als een verzameling gedetailleerde requirements die samen een logisch geheel vormen van opeenvolgende acties die leiden tot een resultaat dat waarde heeft voor de gebruiker.

Bron: Handboek Requirements (2010), Nicole de Swart