Requirements die kloppen: business, functioneel en non-functioneel

Requirements zijn de eisen aan een oplossing. Er zijn drie soorten: business (wat je wilt bereiken), functioneel (wat het systeem moet doen) en non-functioneel (hoe goed het moet werken). Zijn die niet scherp, dan bouw je iets dat werkt zoals gevraagd maar niet doet wat nodig is.

Waarom requirements het verschil maken

De meeste projecten lopen niet vast op de techniek, maar op onduidelijke eisen. Iedereen knikt bij de start, en bij de oplevering blijkt dat iedereen iets anders bedoelde. Goede requirements voorkomen dat. Ze maken verwachtingen expliciet, zodat je achteraf kunt toetsen of de oplossing doet wat beloofd was.

De drie soorten, in volgorde

1. Business requirements (het wat)

Dit is het doel en de waarde voor de organisatie. Waarom doen we dit, wat levert het op? Bijvoorbeeld: de doorlooptijd van een offerte halveren. Geen techniek, wel richting.

2. Functionele requirements (het hoe)

Wat moet het systeem concreet doen? Dit zijn de acties en functies. Voorbeelden: de gebruiker logt in met e-mail en wachtwoord, het systeem stuurt automatisch een bevestiging, een manager keurt een aanvraag goed.

3. Non-functionele requirements (het gedrag)

Hoe goed, hoe snel, hoe veilig en hoe betrouwbaar? Deze worden het vaakst vergeten en doen het vaakst pijn. Voorbeelden: een pagina laadt binnen twee seconden, het systeem verwerkt 1.000 gelijktijdige gebruikers, gegevens worden versleuteld opgeslagen, het systeem is 99,9 procent van de tijd beschikbaar.

Maak ze SMART

Een eis als "het systeem moet snel zijn" is geen eis, het is een wens. Maak elke eis toetsbaar: specifiek, meetbaar en met een norm. "Snel" wordt "een zoekopdracht geeft binnen 300 milliseconden resultaat". Nu kun je achteraf vaststellen of eraan voldaan is.

Zo haal je requirements op

• Bepaal eerst de scope: wat hoort er wel en niet bij.
• Breng de stakeholders en hun rollen in kaart.
• Haal eisen actief op via gesprekken, observatie en data, niet via aannames.
• Cluster wat bij elkaar hoort en gooi dubbelingen en symptomen eruit.
• Prioriteer met MoSCoW: must, should, could, won't.
• Maak ze SMART en valideer ze terug bij de stakeholders.

Veelgemaakte fouten

• Een oplossing als eis opschrijven ("we willen pakket X") in plaats van het achterliggende doel.
• Non-functionele eisen vergeten, waardoor performance en veiligheid pas bij de livegang opvallen.
• Eisen niet valideren, waardoor je bouwt op aannames die niemand bevestigd heeft.

Kort samengevat

• Business zegt wat je wilt, functioneel wat het systeem doet, non-functioneel hoe goed.
• Vergeet de non-functionele eisen niet, die doen het vaakst pijn.
• Maak elke eis meetbaar, anders kun je niet toetsen of het klopt.
• Valideer terug bij de stakeholders voordat je bouwt.

Requirements scherp krijgen is een vaste stap in ICT Fundamentals. Je oefent het op een eigen vraagstuk, zodat je het meteen kunt toepassen.