Samenvatting: Requirements Engineering
Het artikel biedt een uitgebreide handleiding voor het formuleren van sterke, effectieve requirements. De centrale stelling is dat een goede requirement één controleerbaar punt vaststelt en beschrijft wat er bereikt moet worden in plaats van hoe dit technisch gerealiseerd dient te worden.
Kernpunten uit het artikel:
- Kwaliteitseisen: Een sterke requirement is kort, enkelvoudig en voldoet aan de ISO/IEC/IEEE 29148-standaard. Dit betekent dat hij eenduidig, testbaar, noodzakelijk, haalbaar, volledig, consistent en traceerbaar moet zijn.
- Testbaarheid als filter: De auteur stelt dat een zin pas een requirement is als er een concrete methode is om aan te tonen dat eraan voldaan is. Vage termen zoals "snel" of "intuïtief" moeten worden vervangen door meetbare data en specifieke scenario's.
- Requirement versus Design: Er wordt een scherp onderscheid gemaakt tussen functionele eisen en ontwerpbeslissingen. Door het 'hoe' weg te laten, krijgt de bouwer de ruimte om de meest efficiënte technische oplossing te vinden.
- Praktische schrijfgids: Het artikel adviseert om per uitspraak één verplichting te formuleren, permanente ID's toe te kennen en consistente hulpwerkwoorden (shall, should, may) te gebruiken. Daarnaast is een conflictcontrole over de gehele set essentieel.
- Non-functionele requirements: Er wordt gewaarschuwd dat aspecten als performance, beschikbaarheid, beveiliging, toegankelijkheid (WCAG) en capaciteit vaak over het hoofd worden gezien omdat ze geen directe 'feature-eigenaar' hebben.
Het artikel concludeert met een zevenstappenplan voor analyse—van het herformuleren van de behoefte tot het vastleggen van de bron—om ruwe verzoeken om te zetten in professionele specificaties.
Hoe goede requirements eruitzien (en hoe je ze schrijft)
Dit artikel richt zich op de individuele requirement op de pagina: hoe een sterke requirement eruitziet en hoe je deze schrijft. In welk document deze thuishoort en hoe je de informatie uit mensen haalt, zijn aparte taken. Alles hieronder is toepasbaar op één zin per keer.
Waar ziet een goede requirement aan uit?
Een goede requirement is kort, enkelvoudig en controleerbaar. De algemeen erkende kwaliteitseisen zijn dat een requirement eenduidig, testbaar, noodzakelijk, haalbaar, volledig, consistent met de rest van de set en traceerbaar naar een reden moet zijn. Deze eigenschappen staan in ISO/IEC/IEEE 29148 (de standaard voor requirements engineering), hoewel men de standaard niet letterlijk voor zich hoeft te hebben om ze toe te passen.
- Eenduidig: Twee mensen die de tekst afzonderlijk lezen, bouwen hetzelfde.
- Testbaar: Je kunt beschrijven hoe je zou aantonen dat er aan voldaan is.
- Noodzakelijk: Als je het verwijdert, stopt iets dat een gebruiker of de business nodig heeft met werken.
- Haalbaar: Het kan gebouwd worden binnen de bestaande beperkingen, niet binnen de beperkingen die men zou willen hebben.
- Volledig: Het leunt niet op een feit dat alleen in het hoofd van iemand bestaat.
- Consistent: Het spreekt geen andere requirement in hetzelfde document tegen.
- Traceerbaar: Zes maanden later kun je nog steeds zeggen wie erom vroeg en waarom.
Hieronder ziet u hoe deze principes worden toegepast op vijf gewone zinnen:
| Zwakke versie | Wat gaat er mis? | Sterkere versie |
|---|
| Gebruikers kunnen rapporten exporteren en e-mailen. | Twee verplichtingen in één regel; de helft kan falen terwijl de regel als 'afgevinkt' wordt beschouwd. | Splits dit op: "Een gebruiker kan een rapport exporteren als CSV." en "Een gebruiker kan een geëxporteerd rapport e-mailen naar elk adres binnen hun eigen organisatie." |
| Rapporten moeten worden goedgekeurd vóór publicatie. | Geen actor benoemd, waardoor de bouwer zelf maar iemand kiest. | Een finance manager moet een rapport goedkeuren voordat het gepubliceerd kan worden. |
| Het systeem ondersteunt relevante bestandstypen. | Onduidelijke verzameling; de lezer bepaalt wat "relevant" betekent. | Uploads accepteren PDF-, PNG- en JPEG-bestanden tot 10 MB. Alles wat hier niet aan voldoet, wordt geweigerd met een melding waarin de geaccepteerde typen worden genoemd. |
| Er wordt een bevestigingsmail verzonden wanneer een bestelling is geplaatst. | Stil over fouten, waardoor het foutpad onder tijdsdruk ter plekke wordt verzonnen. | Een bevestigingsmail wordt verzonden binnen 60 seconden nadat een bestelling is geplaatst. Als het verzenden faalt, blijft de bestelling geldig en wordt de fout in een wachtrij gezet voor een nieuwe poging. |
| Beheerders kunnen gebruikers beheren. | "Beheren" maskeert vijf verschillende gedragingen met verschillende rechten. | Een beheerder kan elke gebruiker in hun eigen organisatie aanmaken, deactiveren en het wachtwoord resetten. Beheerders kunnen geen gebruikers verwijderen. |
Let op wat de sterkere versies kosten: elke zin vereiste een beslissing (welke formaten, wiens goedkeuring, wat gebeurt er bij fouten, is verwijdering toegestaan?). Dat is het eigenlijke werk. Het schrijven is het makkelijke gedeelte, wat verklaart waarom vage requirements zo populair zijn.
Testbaarheid als ultieme controle
Als je niet kunt beschrijven hoe je zou aantonen dat aan een requirement is voldaan, dan is het geen requirement. Dan is het een voorkeur, en dat moet ook zo worden opgeschreven zodat niemand er tijdens een release-review op wordt afgerekend.
Twee soorten zinnen falen hier vaker dan alle anderen samen:
- "Het systeem moet snel zijn." Snel waar, voor wie, bij welke actie en onder welke belasting? Testbaar gemaakt wordt dit bijvoorbeeld: "Zoeken naar bestellingen geeft resultaten terug in minder dan twee seconden voor 95% van de queries met 200 gelijktijdige gebruikers." Er moesten drie beslissingen worden genomen om dit te schrijven: iemand koos de relevante operatie, iemand koos het percentiel en iemand accepteerde het getal. Tot die tijd betekent "snel" whatever de lezer hoopt, en lezers zijn optimistisch.
- "De interface moet intuïtief zijn." Deze zin overleeft het proces van testbaar maken vaak niet, wat waardevolle informatie is. Het kan een bruikbaarheidsdoel worden met een gekoppelde taak: "Een gebruiker die het product nog niet eerder heeft gezien, voltooit zonder hulp een boeking; geverifieerd met vijf participanten in gemodereerde testen." Meestal verdwijnt zo'n requirement echter volledig, omdat iemand moet definiëren wie de gebruiker is en welke taak telt, en niemand die verantwoordelijkheid wil nemen.
Het testbaar maken van een requirement verbetert niet per se het schrijfwerk; het dwingt een beslissing af die tot dan toe werd uitgesteld. De vaagheid diende een doel: het zorgde ervoor dat de vergadering kon eindigen.
Wanneer er geen eerlijk doel kan worden geformuleerd, schrijf de intentie dan op als een 'doel' (aim), label dit zo en houd het buiten de genummerde lijst waarop de acceptatie wordt gemeten. Veertien requirements en drie expliciete doelen zijn beter dan zeventien requirements waarvan vier niet kunnen falen.
Wat is een gedetailleerde requirement?
Een gedetailleerde requirement laat de bouwer geen ruimte om te gokken. Het dicht de gaten. Het specificeert echter niet de oplossing; het verwarren van deze twee is de meest voorkomende fout.
Vergelijk deze twee:
- "Het uploadscherm moet een voortgangsbalk tonen met het voltooide percentage."
- "Een gebruiker die een bestand groter dan 5 MB uploadt, kan zien dat de upload vordert en ongeveer hoeveel er nog overblijft."
De eerste is niet gedetailleerder; het is een ontwerpbeslissing (design decision) waaraan een requirement-nummer is gegeven. Het dwingt je tot een voortgangsbalk, zelfs als een engineer de upload in stukken zou kunnen hakken en direct kon bevestigen, wat het probleem beter en goedkoper zou oplossen. Als je het "hoe" voorschrijft, neem je de kans weg dat degene die het systeem het beste kent met een betere oplossing komt.
Soms is het "hoe" echter wel de requirement. Een toezichthouder vereist een bepaalde controle, een contract bepaalt een format of een design-systeem legt een component vast. Schrijf deze als beperkingen (constraints) en vermeld waar de verplichting vandaan komt. Rechtvaardigbare beperkingen zijn prima; beperkingen die voortkomen uit de gewoonte van één persoon uit een vorige baan, zijn duur.
Wat betreft de hoeveelheid detail: stop wanneer de volgende vraag die een bouwer zou stellen, beantwoord wordt in het document. Foutpaden (error paths), lege toestanden (empty states) en rechten zijn vaak de plekken waar antwoorden ontbreken; dit zijn geen uitzonderingen ('edge cases'), maar essentiële onderdelen.
Hoe schrijf je een goede requirements-specificatie?
Schrijf elke requirement zo dat deze op zichzelf gelezen, begrepen en geverifieerd kan worden. Controleer daarna de hele set op tegenstrijdigheden. Een specificatie is niet één lange requirement, maar een verzameling korte requirements plus de discipline om te voorkomen dat ze met elkaar in conflict komen.
- Eén verplichting per uitspraak. Als de zin "en" bevat, controleer dan of je twee dingen hebt beschreven die onafhankelijk van elkaar kunnen slagen of falen. Meestal is dat zo.
- Geef elke requirement een permanent identificatienummer (ID) en gebruik dit nooit opnieuw, zelfs niet nadat de requirement is verwijderd. Hergebruikte ID's zorgen ervoor dat oude review-opmerkingen onjuist worden.
- Reserveer één hulpwerkwoord voor verplichtingen. De formele conventie is shall voor verplicht, should voor wenselijk en may voor toegestaan (zie RFC 2119 voor internetstandaarden).
- Controleer de set, niet alleen de zin. Twee requirements kunnen elk goed geschreven zijn, maar samen onmogelijk.
De meeste productteams gebruiken shall, should en may niet, en hoeven dat ook niet. De waarde zit niet in het vocabulaire, maar in het feit dat verplichtingen telbaar worden: een reviewer zoekt op "shall" en heeft direct de volledige lijst van waarvoor men verantwoordelijk is.
De conflictcontrole is de stap die mensen vaak overslaan. Eén requirement stelt dat transactiegegevens zeven jaar bewaard blijven. Een andere stelt dat alle gegevens van een gebruiker binnen 30 dagen verwijderd moeten worden als het account wordt gesloten. Beide zijn redelijk en competent geschreven, maar ze kunnen niet beide waar zijn. Dit ontdek je niet door zinnen één voor één te lezen.
De requirements die pas in de laatste week worden opgeschreven
Non-functionele requirements zijn het zwakste punt van de meeste teams. Ze duiken vaak pas op in de laatste week, wanneer een loadtest faalt of een security-vragenlijst van een klant arriveert. Het was niet moeilijk om ze te schrijven; ze hadden simpelweg geen auteur.
Functionele requirements hebben een duidelijke eigenaar (degene die de feature wilde). Non-functionele requirements horen bij iedereen, waardoor niemand ze uitwerkt. Vijf categorieën dekken het meeste wat vaak wordt vergeten:
- Performance: Een operatie, een doelstelling, een belasting en een percentiel.
- Beschikbaarheid (Availability): Een uptime-doel, een meetwindow en wat er gebeurt met lopend werk tijdens een storing. Dat laatste deel wordt vaak vergeten.
- Beveiliging (Security): Authenticatie, autorisatieregels, data in rust en in transit, bewaring en verwijdering. Bewaring vereist een specifiek getal.
- Toegankelijkheid (Accessibility): Benoem een niveau, bijvoorbeeld conformiteit met WCAG 2.2 op niveau AA. Het noemen van een standaard is effectiever dan het beschrijven van een intentie; "de site moet toegankelijk zijn" is niet testbaar.
- Capaciteit en data: Verwachte volumes, groei, maximale bestands- en recordgroottes, en wat er gebeurt bij het bereiken van de limiet.
De 7 stappen in requirement-analyse
Er is geen canonieke lijst van zeven stappen; tekstboeken hanteren verschillende tellingen. Hieronder volgt de sequentie die één ruw verzoek omzet in één geschreven requirement:
- Herformuleer de behoefte zonder de oplossing. Als dit niet kan, vraag dan opnieuw door.
- Benoem de actor. Anonieme requirements worden gebouwd voor een gebruiker die niemand kent.
- Vraag wat als 'falen' zou gelden. Het antwoord wordt je verificatiemethode.
- Splits de tekst totdat elke uitspraak precies één verplichting bevat.
- Controleer tegen bestaande requirements. Zoek naar duplicaten, tegenstrijdigheden of speciale gevallen van iets dat al bestaat. Dit is cruciaal bij lijsten van meer dan vijftig items.
- Koppel de non-functionele limieten waarvan het afhangt (volumes, responstijden, rechten, bewaring). Op dit moment zijn deze nog goedkoop om toe te voegen.
- Leg de bron en de beslissing vast. Wie vroeg erom, welk probleem lost het op en welke keuze is er gemaakt waar alternatieven waren? Dit zorgt ervoor dat het document overleeft als de auteur vertrekt.
Veelgestelde vragen (FAQ)
Is "must" beter dan "shall"? Geen van beide is inherent beter. Kies één term en gebruik deze uitsluitend voor verplichtingen. Als uw reviewers zakelijke mensen zijn in plaats van engineers, leest "must" natuurlijker.
Wat maakt een requirement traceerbaar? Een permanent identificatienummer, een vastgelegde bron en een beschreven verificatiemethode. Traceerbaarheid is essentieel wanneer er wordt voorgesteld om de scope te verkleinen; het laat zien wat er precies kapotgaat als iets wordt geschrapt.
Wanneer zijn er teveel requirements? Er is geen vast aantal, maar er is een symptoom: zodra mensen stoppen met het lezen van de lijst en in plaats daarvan een collega vragen wat erin staat, is de lijst te groot geworden. Splits de lijst dan op per functionaliteit (capability), zodat elke lezer ongeveer dertig items heeft om zich mee bezig te houden.
Kan een mock-up dienen als requirement? Alleen in combinatie met een schriftelijke uitspraak over de verplichting. Een ontwerp toont één oplossing voor een probleem dat nooit expliciet wordt benoemd, en het verbindt je aan elk detail op het scherm, inclusief details waar de ontwerper niet over heeft nagedacht. Verwijs naar de mock-up en geef aan welke delen ervan bindend zijn.
Hoe goede requirements eruitzien (en hoe je ze schrijft)
Dit artikel richt zich op de individuele requirement op de pagina: hoe een sterke requirement eruitziet en hoe je deze schrijft. In welk document deze thuishoort en hoe je de informatie uit mensen haalt, zijn aparte taken. Alles hieronder is toepasbaar op één zin per keer.
Waar ziet een goede requirement aan uit?
Een goede requirement is kort, enkelvoudig en controleerbaar. De algemeen erkende kwaliteitseisen zijn dat een requirement eenduidig, testbaar, noodzakelijk, haalbaar, volledig, consistent met de rest van de set en traceerbaar naar een reden moet zijn. Deze eigenschappen staan in ISO/IEC/IEEE 29148 (de standaard voor requirements engineering), hoewel men de standaard niet letterlijk voor zich hoeft te hebben om ze toe te passen.
- Eenduidig: Twee mensen die de tekst afzonderlijk lezen, bouwen hetzelfde.
- Testbaar: Je kunt beschrijven hoe je zou aantonen dat er aan voldaan is.
- Noodzakelijk: Als je het verwijdert, stopt iets dat een gebruiker of de business nodig heeft met werken.
- Haalbaar: Het kan gebouwd worden binnen de bestaande beperkingen, niet binnen de beperkingen die men zou willen hebben.
- Volledig: Het leunt niet op een feit dat alleen in het hoofd van iemand bestaat.
- Consistent: Het spreekt geen andere requirement in hetzelfde document tegen.
- Traceerbaar: Zes maanden later kun je nog steeds zeggen wie erom vroeg en waarom.
Hieronder ziet u hoe deze principes worden toegepast op vijf gewone zinnen:
| Zwakke versie | Wat gaat er mis? | Sterkere versie |
|---|
| Gebruikers kunnen rapporten exporteren en e-mailen. | Twee verplichtingen in één regel; de helft kan falen terwijl de regel als 'afgevinkt' wordt beschouwd. | Splits dit op: "Een gebruiker kan een rapport exporteren als CSV." en "Een gebruiker kan een geëxporteerd rapport e-mailen naar elk adres binnen hun eigen organisatie." |
| Rapporten moeten worden goedgekeurd vóór publicatie. | Geen actor benoemd, waardoor de bouwer zelf maar iemand kiest. | Een finance manager moet een rapport goedkeuren voordat het gepubliceerd kan worden. |
| Het systeem ondersteunt relevante bestandstypen. | Onduidelijke verzameling; de lezer bepaalt wat "relevant" betekent. | Uploads accepteren PDF-, PNG- en JPEG-bestanden tot 10 MB. Alles wat hier niet aan voldoet, wordt geweigerd met een melding waarin de geaccepteerde typen worden genoemd. |
| Er wordt een bevestigingsmail verzonden wanneer een bestelling is geplaatst. | Stil over fouten, waardoor het foutpad onder tijdsdruk ter plekke wordt verzonnen. | Een bevestigingsmail wordt verzonden binnen 60 seconden nadat een bestelling is geplaatst. Als het verzenden faalt, blijft de bestelling geldig en wordt de fout in een wachtrij gezet voor een nieuwe poging. |
| Beheerders kunnen gebruikers beheren. | "Beheren" maskeert vijf verschillende gedragingen met verschillende rechten. | Een beheerder kan elke gebruiker in hun eigen organisatie aanmaken, deactiveren en het wachtwoord resetten. Beheerders kunnen geen gebruikers verwijderen. |
Let op wat de sterkere versies kosten: elke zin vereiste een beslissing (welke formaten, wiens goedkeuring, wat gebeurt er bij fouten, is verwijdering toegestaan?). Dat is het eigenlijke werk. Het schrijven is het makkelijke gedeelte, wat verklaart waarom vage requirements zo populair zijn.
Testbaarheid als ultieme controle
Als je niet kunt beschrijven hoe je zou aantonen dat aan een requirement is voldaan, dan is het geen requirement. Dan is het een voorkeur, en dat moet ook zo worden opgeschreven zodat niemand er tijdens een release-review op wordt afgerekend.
Twee soorten zinnen falen hier vaker dan alle anderen samen:
- "Het systeem moet snel zijn." Snel waar, voor wie, bij welke actie en onder welke belasting? Testbaar gemaakt wordt dit bijvoorbeeld: "Zoeken naar bestellingen geeft resultaten terug in minder dan twee seconden voor 95% van de queries met 200 gelijktijdige gebruikers." Er moesten drie beslissingen worden genomen om dit te schrijven: iemand koos de relevante operatie, iemand koos het percentiel en iemand accepteerde het getal. Tot die tijd betekent "snel" whatever de lezer hoopt, en lezers zijn optimistisch.
- "De interface moet intuïtief zijn." Deze zin overleeft het proces van testbaar maken vaak niet, wat waardevolle informatie is. Het kan een bruikbaarheidsdoel worden met een gekoppelde taak: "Een gebruiker die het product nog niet eerder heeft gezien, voltooit zonder hulp een boeking; geverifieerd met vijf participanten in gemodereerde testen." Meestal verdwijnt zo'n requirement echter volledig, omdat iemand moet definiëren wie de gebruiker is en welke taak telt, en niemand die verantwoordelijkheid wil nemen.
Het testbaar maken van een requirement verbetert niet per se het schrijfwerk; het dwingt een beslissing af die tot dan toe werd uitgesteld. De vaagheid diende een doel: het zorgde ervoor dat de vergadering kon eindigen.
Wanneer er geen eerlijk doel kan worden geformuleerd, schrijf de intentie dan op als een 'doel' (aim), label dit zo en houd het buiten de genummerde lijst waarop de acceptatie wordt gemeten. Veertien requirements en drie expliciete doelen zijn beter dan zeventien requirements waarvan vier niet kunnen falen.
Wat is een gedetailleerde requirement?
Een gedetailleerde requirement laat de bouwer geen ruimte om te gokken. Het dicht de gaten. Het specificeert echter niet de oplossing; het verwarren van deze twee is de meest voorkomende fout.
Vergelijk deze twee:
- "Het uploadscherm moet een voortgangsbalk tonen met het voltooide percentage."
- "Een gebruiker die een bestand groter dan 5 MB uploadt, kan zien dat de upload vordert en ongeveer hoeveel er nog overblijft."
De eerste is niet gedetailleerder; het is een ontwerpbeslissing (design decision) waaraan een requirement-nummer is gegeven. Het dwingt je tot een voortgangsbalk, zelfs als een engineer de upload in stukken zou kunnen hakken en direct kon bevestigen, wat het probleem beter en goedkoper zou oplossen. Als je het "hoe" voorschrijft, neem je de kans weg dat degene die het systeem het beste kent met een betere oplossing komt.
Soms is het "hoe" echter wel de requirement. Een toezichthouder vereist een bepaalde controle, een contract bepaalt een format of een design-systeem legt een component vast. Schrijf deze als beperkingen (constraints) en vermeld waar de verplichting vandaan komt. Rechtvaardigbare beperkingen zijn prima; beperkingen die voortkomen uit de gewoonte van één persoon uit een vorige baan, zijn duur.
Wat betreft de hoeveelheid detail: stop wanneer de volgende vraag die een bouwer zou stellen, beantwoord wordt in het document. Foutpaden (error paths), lege toestanden (empty states) en rechten zijn vaak de plekken waar antwoorden ontbreken; dit zijn geen uitzonderingen ('edge cases'), maar essentiële onderdelen.
Hoe schrijf je een goede requirements-specificatie?
Schrijf elke requirement zo dat deze op zichzelf gelezen, begrepen en geverifieerd kan worden. Controleer daarna de hele set op tegenstrijdigheden. Een specificatie is niet één lange requirement, maar een verzameling korte requirements plus de discipline om te voorkomen dat ze met elkaar in conflict komen.
- Eén verplichting per uitspraak. Als de zin "en" bevat, controleer dan of je twee dingen hebt beschreven die onafhankelijk van elkaar kunnen slagen of falen. Meestal is dat zo.
- Geef elke requirement een permanent identificatienummer (ID) en gebruik dit nooit opnieuw, zelfs niet nadat de requirement is verwijderd. Hergebruikte ID's zorgen ervoor dat oude review-opmerkingen onjuist worden.
- Reserveer één hulpwerkwoord voor verplichtingen. De formele conventie is shall voor verplicht, should voor wenselijk en may voor toegestaan (zie RFC 2119 voor internetstandaarden).
- Controleer de set, niet alleen de zin. Twee requirements kunnen elk goed geschreven zijn, maar samen onmogelijk.
De meeste productteams gebruiken shall, should en may niet, en hoeven dat ook niet. De waarde zit niet in het vocabulaire, maar in het feit dat verplichtingen telbaar worden: een reviewer zoekt op "shall" en heeft direct de volledige lijst van waarvoor men verantwoordelijk is.
De conflictcontrole is de stap die mensen vaak overslaan. Eén requirement stelt dat transactiegegevens zeven jaar bewaard blijven. Een andere stelt dat alle gegevens van een gebruiker binnen 30 dagen verwijderd moeten worden als het account wordt gesloten. Beide zijn redelijk en competent geschreven, maar ze kunnen niet beide waar zijn. Dit ontdek je niet door zinnen één voor één te lezen.
De requirements die pas in de laatste week worden opgeschreven
Non-functionele requirements zijn het zwakste punt van de meeste teams. Ze duiken vaak pas op in de laatste week, wanneer een loadtest faalt of een security-vragenlijst van een klant arriveert. Het was niet moeilijk om ze te schrijven; ze hadden simpelweg geen auteur.
Functionele requirements hebben een duidelijke eigenaar (degene die de feature wilde). Non-functionele requirements horen bij iedereen, waardoor niemand ze uitwerkt. Vijf categorieën dekken het meeste wat vaak wordt vergeten:
- Performance: Een operatie, een doelstelling, een belasting en een percentiel.
- Beschikbaarheid (Availability): Een uptime-doel, een meetwindow en wat er gebeurt met lopend werk tijdens een storing. Dat laatste deel wordt vaak vergeten.
- Beveiliging (Security): Authenticatie, autorisatieregels, data in rust en in transit, bewaring en verwijdering. Bewaring vereist een specifiek getal.
- Toegankelijkheid (Accessibility): Benoem een niveau, bijvoorbeeld conformiteit met WCAG 2.2 op niveau AA. Het noemen van een standaard is effectiever dan het beschrijven van een intentie; "de site moet toegankelijk zijn" is niet testbaar.
- Capaciteit en data: Verwachte volumes, groei, maximale bestands- en recordgroottes, en wat er gebeurt bij het bereiken van de limiet.
De 7 stappen in requirement-analyse
Er is geen canonieke lijst van zeven stappen; tekstboeken hanteren verschillende tellingen. Hieronder volgt de sequentie die één ruw verzoek omzet in één geschreven requirement:
- Herformuleer de behoefte zonder de oplossing. Als dit niet kan, vraag dan opnieuw door.
- Benoem de actor. Anonieme requirements worden gebouwd voor een gebruiker die niemand kent.
- Vraag wat als 'falen' zou gelden. Het antwoord wordt je verificatiemethode.
- Splits de tekst totdat elke uitspraak precies één verplichting bevat.
- Controleer tegen bestaande requirements. Zoek naar duplicaten, tegenstrijdigheden of speciale gevallen van iets dat al bestaat. Dit is cruciaal bij lijsten van meer dan vijftig items.
- Koppel de non-functionele limieten waarvan het afhangt (volumes, responstijden, rechten, bewaring). Op dit moment zijn deze nog goedkoop om toe te voegen.
- Leg de bron en de beslissing vast. Wie vroeg erom, welk probleem lost het op en welke keuze is er gemaakt waar alternatieven waren? Dit zorgt ervoor dat het document overleeft als de auteur vertrekt.
Veelgestelde vragen (FAQ)
Is "must" beter dan "shall"? Geen van beide is inherent beter. Kies één term en gebruik deze uitsluitend voor verplichtingen. Als uw reviewers zakelijke mensen zijn in plaats van engineers, leest "must" natuurlijker.
Wat maakt een requirement traceerbaar? Een permanent identificatienummer, een vastgelegde bron en een beschreven verificatiemethode. Traceerbaarheid is essentieel wanneer er wordt voorgesteld om de scope te verkleinen; het laat zien wat er precies kapotgaat als iets wordt geschrapt.
Wanneer zijn er teveel requirements? Er is geen vast aantal, maar er is een symptoom: zodra mensen stoppen met het lezen van de lijst en in plaats daarvan een collega vragen wat erin staat, is de lijst te groot geworden. Splits de lijst dan op per functionaliteit (capability), zodat elke lezer ongeveer dertig items heeft om zich mee bezig te houden.
Kan een mock-up dienen als requirement? Alleen in combinatie met een schriftelijke uitspraak over de verplichting. Een ontwerp toont één oplossing voor een probleem dat nooit expliciet wordt benoemd, en het verbindt je aan elk detail op het scherm, inclusief details waar de ontwerper niet over heeft nagedacht. Verwijs naar de mock-up en geef aan welke delen ervan bindend zijn.
Groetjes,