Plan & Track - Requirements

Introductie

Requirements vormen de basis van iedere oplossing. Ze bepalen niet alleen wat er gebouwd wordt, maar ook waarom en met welke kwaliteit.

wat een oplossing moet doen (functionaliteit)
hoe goed deze moet functioneren (kwaliteit)

1. Wat zijn requirements?

Business requirements

Waarom bestaat de oplossing? Welke waarde wordt geleverd?

Functional requirements

Wat moet het systeem concreet doen?

Non-functional requirements

Hoe goed moet het systeem functioneren?

Constraints

Beperkingen zoals technologie, regelgeving en architectuur.

Assumptions

Uitgangspunten die als gegeven worden aangenomen.

2. FURPS+

Functionality
Usability
Reliability
Performance
Supportability
Security
Data
Integration

3. Van requirement naar implementatie

Requirement
   ↓
Use Case
   ↓
User Story
   ↓
Implementation

👉 Zorgt voor traceability van business behoefte naar technische oplossing. Zie ook de aparte pagina Requirement Traceability voor een volledige uitwerking.

4. Mapping naar oplossingen

Afhankelijk van het type requirement worden verschillende oplossingsrichtingen gekozen.

Scenario	Oplossingsrichting
UI logica	Client-side logica / UI rules
Server logica	Backend services / APIs
Integratie	Workflows / pipelines / messaging
Data verwerking	Data pipelines / transformations

5. User stories

User stories vertalen requirements naar concrete, implementeerbare eenheden van werk. Ze richten zich op de behoefte van de eindgebruiker en zorgen ervoor dat development altijd gekoppeld blijft aan business waarde.

Een goede user story is klein, begrijpelijk en gericht op één duidelijke functionaliteit.

Standaard format:

Als [gebruiker]
wil ik [functionaliteit]
zodat [waarde]

👉 Dit format helpt om continu de relatie te leggen tussen functionaliteit en business waarde.

6. Acceptatiecriteria

Acceptatiecriteria bepalen wanneer een user story als “gereed” kan worden beschouwd. Ze vormen de basis voor testing en zorgen ervoor dat verwachtingen eenduidig zijn.

Acceptatiecriteria moeten:

concreet en testbaar zijn
eenduidig interpreteerbaar zijn
direct gekoppeld zijn aan de user story

Veelgebruikte structuur (Given / When / Then):

Given – de beginsituatie of context
When – de actie of gebeurtenis
Then – het verwachte resultaat

Voorbeeld:

Given een gebruiker een aanvraag invult
When de aanvraag wordt opgeslagen
Then wordt automatisch een bevestiging verstuurd

👉 Goede acceptatiecriteria maken requirements meetbaar en zorgen voor voorspelbare testing en oplevering.

7. Stappenplan

Onderstaand stappenplan helpt bij het gestructureerd verzamelen, analyseren en uitwerken van requirements. Door deze stappen bewust te doorlopen, ontstaat een consistente en beheersbare aanpak.

Stakeholders identificeren
Wie zijn betrokken en welke belangen spelen er?
Scope bepalen
Wat valt binnen de oplossing en wat expliciet niet?
Requirements verzamelen
Inventariseren via workshops, interviews en analyse van bestaande processen.
Structureren en valideren
Categoriseren (bijvoorbeeld via FURPS+) en afstemmen met stakeholders.
Uitwerken naar use cases
Vertalen naar concrete scenario’s en interacties tussen gebruiker en systeem.

👉 Door deze aanpak ontstaat een duidelijke lijn van business behoefte naar ontwerp en implementatie.

8. SMART

Requirements moeten SMART geformuleerd zijn om ambiguïteit te voorkomen en toetsbaar te maken binnen development en testing.

Specifiek – duidelijk en eenduidig geformuleerd
Meetbaar – resultaat is controleerbaar
Acceptabel – afgestemd met stakeholders
Realistisch – haalbaar binnen context en platform
Tijdgebonden – voorzien van duidelijke planning of deadline

👉 SMART criteria helpen om requirements concreet, begrijpelijk en testbaar te maken.