Wat is de requirementsfase?

De requirementsfase in de SSDLC richt zich op het verzamelen, analyseren en specificeren van wat het systeem moet doen. Het is de eerste inhoudelijke fase waarin functionele én niet-functionele eisen worden vastgesteld, inclusief beveiligingsbehoeften. De output van deze fase vormt de basis voor ontwerp, implementatie, testen én onderhoud.

Casus

Een zorginstelling wil een nieuw cliëntendossier ontwikkelen. In de requirementsfase worden functionele wensen verzameld zoals “inzage in eigen dossier” en “notities toevoegen door zorgmedewerkers”, maar ook niet-functionele eisen zoals “data moet binnen Nederland opgeslagen worden” en “alle toegang moet worden gelogd”.

Hoe zit de requirementsfase in elkaar?

1. Doel van de fase

Het doel is om duidelijke en haalbare eisen te formuleren voor het te ontwikkelen systeem. Deze eisen zijn het fundament voor het verdere ontwikkelproces.

2. Activiteiten binnen de fase

  • Interviews, workshops en observaties met stakeholders
  • Analyseren van de context (businessdoelen, wetgeving, bestaande systemen)
  • Opstellen van use cases of user stories (voor communicatie)
  • Identificeren van niet-functionele eisen
  • Opstellen van een eerste traceability-matrix

3. Betrokken rollen

  • Product owner / opdrachtgever
  • Gebruikers en domeinexperts
  • Analisten
  • Security officer (voor risico-inventarisatie)
  • Developer (voor haalbaarheidstoetsing)

4. Op te leveren resultaten

  • Vision & scope document
  • Use case model en beschrijvingen (volgens HBO-ICT-SE-richtlijnen)
  • Lijst met niet-functionele eisen (bv. volgens ISO/IEC 25010)
  • Beveiligingsvereisten en dreigingsmodellen
  • Traceability-matrix

5. Beveiligingsfocus

  • Vaststellen van vertrouwelijkheids-, integriteits- en beschikbaarheidsbehoeften (CIA)
  • Classificatie van data
  • Security-by-design uitgangspunten vastleggen
  • Mogelijke dreigingen identificeren (voor volgende fase: threat modeling)

6. Modelleertechnieken of tools

  • UML use case diagram
  • Domeinmodellen
  • BPMN voor processen
  • C4-contextdiagram
  • Tools: Miro, Lucidchart, Visual Paradigm

7. Feedbackloops of iteraties

  • Reviews met stakeholders
  • Validatie van eisen in meerdere iteraties (bv. in SCRUM via refinement sessies)
  • Herziening van requirements na sprintfeedback of risicosessies

8. Communiceerbaarheid van tussenresultaten

  • Gebruik van wireframes, scenario’s en voorbeelden
  • Verschillende versies van het document voor verschillende doelgroepen
  • Technisch: UML, tabellen
  • Niet-technisch: beschrijvingen in gewone taal, wireframes

9. Traceerbaarheid

  • Nummering van use cases en requirements
  • Koppeling tussen use case en stakeholder
  • Traceability matrix: van eis naar ontwerp, implementatie en test (zoals aanbevolen in de richtlijnen van HBO-ICT-SE)

10. Testmogelijkheden of controlepunten

  • Eisen worden geformuleerd als testbare criteria (“specification by example”)
  • Elke use case wordt voorzien van testgevallen of acceptatiecriteria
  • Eerste aanzet tot testplan of testscenario’s

11. Voorbeelden of casus

Use case: "Reserveren afspraak bij huisarts"

Preconditie: gebruiker is ingelogd
Basisstroom:
- Kies dag en tijd
- Bevestig keuze
- Ontvang bevestiging per mail

Alternatieve stroom A1: tijdslot niet meer beschikbaar

Niet-functionele eis: afspraakbevestiging moet binnen 3 seconden zichtbaar zijn

12. Betekenis voor de volgende fase

De requirementsfase levert het fundament voor het ontwerp. In de ontwerp- en architectuurfase worden:

  • Functionele eisen vertaald naar componenten, interfaces en logica
  • Niet-functionele eisen (zoals performantie en beveiliging) vertaald naar technische oplossingen
  • Use cases omgezet naar interactie-, toestands- en klassendiagrammen
  • Beveiligingseisen verwerkt in threat models en controleregelmechanismen

Zonder heldere en gevalideerde requirements is er in de volgende fase risico op misinterpretatie, scope creep en beveiligingslekken.

Hoe gebruik je de requirement fase

De requirementsfase vormt het startpunt én fundament van de softwareontwikkeling. Je gebruikt deze fase om gericht en gestructureerd toe te werken naar een systeem dat voldoet aan de wensen en eisen van gebruikers én aan kwaliteitsnormen zoals veiligheid, prestaties en wettelijke verplichtingen.

In de praktijk gebruik je deze fase om:

  • Behoeftes boven water te krijgen via gesprekken, observaties en workshops met stakeholders.
  • Eisen tastbaar te maken in de vorm van use cases, niet-functionele eisen en beveiligingsrichtlijnen.
  • De scope en haalbaarheid van het project vast te leggen en af te bakenen.
  • Beveiligingsrisico’s vroegtijdig te signaleren, zodat deze in ontwerp en implementatie kunnen worden meegenomen.
  • De traceerbaarheid van eisen te borgen richting ontwerp, implementatie en testen.
  • Verschillende belanghebbenden te betrekken bij de validatie van tussenresultaten, bijvoorbeeld met wireframes of scenario’s.

Door requirements goed te gebruiken, voorkom je misverstanden, onnodige aanpassingen later in het proces en vergroot je de kans op een succesvol eindproduct.


Volgende stap: Uitleg SSDLC Designfase