Requirements analyse

Requirements analyse is het proces van het verzamelen, documenteren en valideren van de wensen en eisen voor een systeem. Bij het ontwerpen van AI-systemen is dit extra belangrijk: stakeholders hebben vaak hoge verwachtingen, maar beperkt begrip van wat AI wel en niet kan. Ook is het enorm belangrijk om de impact van het AI-systeem op de gebruikers mee te nemen.

Interviews

Interviews zijn een van de meest directe manieren om requirements te verzamelen. Je spreekt met stakeholders, eindgebruikers en domeinexperts om hun behoeften, verwachtingen en zorgen te begrijpen.

Typen interviews

Type	Kenmerken	Wanneer gebruiken
Gestructureerd	Vaste vragenlijst, dezelfde vragen voor iedereen	Vergelijkbare antwoorden nodig van meerdere respondenten
Semi-gestructureerd	Vaste thema's, ruimte voor doorvragen	Balans tussen structuur en flexibiliteit
Ongestructureerd	Open gesprek, geen vaste vragen	Verkenningsfase, nieuwe inzichten ontdekken

Interviewtechnieken

Techniek	Beschrijving
Open vragen	"Hoe ziet een typische werkdag eruit?" — nodigt uit tot uitgebreide antwoorden
Doorvragen	"Kun je daar een voorbeeld van geven?" — verdieping
Samenvatten	"Dus als ik het goed begrijp..." — checken of je het snapt
Stiltes	Geef ruimte, mensen vullen stiltes vaak met extra informatie
Laddering	"Waarom is dat belangrijk?" — achterliggende motivaties blootleggen

Interview checklist voor AI-projecten

[ ] Wat is het probleem dat opgelost moet worden?
[ ] Hoe wordt dit probleem nu aangepakt (zonder AI)?
[ ] Welke data is beschikbaar? Wie beheert deze?
[ ] Hoe zou een ideale oplossing eruitzien?
[ ] Wat zijn de risico's als het systeem fouten maakt?
[ ] Wie gaat het systeem gebruiken en in welke context?
[ ] Welke beslissingen worden genomen op basis van de output?

!!! tip "AI-specifieke vragen" Vraag expliciet naar verwachtingen over nauwkeurigheid, uitlegbaarheid en wat er moet gebeuren als het model het fout heeft. Dit voorkomt teleurstellingen later.

MoSCoW

MoSCoW is een prioriteringsmethode om requirements te ordenen op basis van hun belang. De naam is een acroniem voor de vier prioriteitsniveaus.

De vier categorieën

Prioriteit	Betekenis	Toelichting
Must have	Moet erin zitten	Zonder deze requirements is het systeem niet bruikbaar. Dit zijn de minimale eisen voor een werkend product.
Should have	Zou erin moeten zitten	Belangrijke requirements die veel waarde toevoegen, maar het systeem werkt ook zonder.
Could have	Zou erin kunnen zitten	Wenselijke features die worden meegenomen als er tijd/budget over is.
Won't have (this time)	Komt er nu niet in	Expliciet uitgesloten voor deze versie, mogelijk in de toekomst.

MoSCoW toepassen

Lijst alle requirements — verzamel eerst alles zonder te filteren
Bepaal per requirement de prioriteit — samen met stakeholders
Valideer de verdeling — Must haves zouden niet meer dan ~60% moeten zijn
Documenteer de rationale — leg vast waarom iets een Must of Won't is

Voorbeeld voor een AI-systeem

Requirement	Prioriteit	Rationale
Model voorspelt churn met >80% accuracy	Must	Kernfunctionaliteit
Dashboard toont voorspellingen	Must	Nodig voor gebruik door business
Model legt uit waarom klant churnt	Should	Belangrijk voor actionable insights
Real-time voorspellingen	Could	Batch is voldoende voor huidige use case
Integratie met CRM-systeem	Won't	Fase 2, nu te complex

!!! warning "Valkuil: alles is een Must" Als stakeholders alles als Must hebben labelen, werkt de methode niet. Stel duidelijke criteria op en wees bereid om terug te duwen.

User Stories

User stories beschrijven requirements vanuit het perspectief van de eindgebruiker. Ze focussen op wie iets nodig heeft, wat ze nodig hebben, en waarom.

Formaat

Als [rol]
wil ik [actie/functionaliteit]
zodat [doel/waarde]

Kenmerken van goede user stories (INVEST)

Criterium	Betekenis
Independent	Niet afhankelijk van andere stories
Negotiable	Details zijn bespreekbaar
Valuable	Levert waarde voor de gebruiker
Estimable	Team kan inschatten hoeveel werk het is
Small	Klein genoeg om in één sprint te realiseren
Testable	Je kunt verifiëren of het werkt

User stories voor AI-systemen

Bij AI-projecten is het belangrijk om ook de onzekerheid en beperkingen van het model mee te nemen:

Traditionele story	AI-specifieke uitbreiding
"Als gebruiker wil ik een voorspelling zien"	+ "...met een indicatie van de betrouwbaarheid"
"Als manager wil ik fraude detecteren"	+ "...en begrijpen waarom een transactie verdacht is"
"Als arts wil ik een diagnose-suggestie"	+ "...waarbij ik altijd de eindebeslissing neem"

Voorbeelden

Voorbeeld 1: Voorspellend onderhoud

Als productiemedewerker
wil ik een waarschuwing krijgen wanneer een machine dreigt uit te vallen
zodat ik preventief onderhoud kan inplannen en stilstand kan voorkomen.

Voorbeeld 2: Chatbot

Als klantenservicemedewerker
wil ik dat de chatbot eenvoudige vragen zelfstandig beantwoordt
zodat ik meer tijd heb voor complexe klantvragen.

Voorbeeld 3: Aanbevelingssysteem

Als webshopbezoeker
wil ik productsuggesties zien op basis van mijn browsegedrag
zodat ik sneller relevante producten vind.

Acceptatiecriteria

Elke user story heeft acceptatiecriteria nodig — concrete voorwaarden waaraan voldaan moet zijn:

User Story: Als gebruiker wil ik een spamfilter zodat mijn inbox schoon blijft.

Acceptatiecriteria:
- Het model classificeert e-mails als spam of niet-spam
- Precision voor spam is minimaal 95% (weinig false positives)
- Gebruiker kan een e-mail handmatig als "geen spam" markeren
- Gemarkeerde e-mails worden gebruikt om het model te verbeteren

!!! note "Van story naar technische requirements" User stories zijn een startpunt. Voor AI-systemen moeten ze vertaald worden naar technische specificaties: welke data is nodig, welke metrics gelden, hoe wordt het model geëvalueerd, en wat zijn de randvoorwaarden (latency, privacy, etc.)?