Antwoord.

Historisch gezien is de aandacht in IT-projecten voornamelijk gericht op functionele vereisten: wat het systeem moet doen. Vragen over prestaties, betrouwbaarheid, schaalbaarheid, beschikbaarheid, beveiliging en onderhoudbaarheid (deze kenmerken worden samengevoegd onder de term "niet-functionele vereisten", NFR) zijn lange tijd van secundair belang gebleven en vaak helemaal niet geformaliseerd.

Probleem

Het negeren of formeel beschrijven van NFR leidt tot aanzienlijke problemen in de operationele fase: het systeem is niet voorbereid op de verwachte belasting, houdt geen stand tegen cyberaanvallen, is moeilijk te onderhouden en op te schalen, of is niet beschikbaar voor het vereiste aantal gebruikers.

Oplossing

Een moderne systeemanalist moet NFR initiëren, formaliseren, analyseren en documenteren. Dit omvat:

samenwerking met architecten, DevOps- en operationele teams om technologische en infrastructurele beperkingen te bepalen;
verzamelen van eisen van het bedrijfsleven (bijvoorbeeld met betrekking tot SLA);
opstellen van een uitputtende lijst van NFR met specifieke drempelwaarden;
implementeren van maatregelen om deze te controleren in de fase van implementatie en ondersteuning;
vastlegging van vereisten in afzonderlijke secties van de specificatie.

Belangrijke kenmerken:

NFR zijn verplicht voor alle grote projecten.
Worden gezamenlijk bepaald met technische en zakelijke belanghebbenden.
Moeten ondubbelzinnig, testbaar en gekoppeld zijn aan zakelijke doelstellingen.

Misleidende vragen.

Wat is het verschil tussen "productkwaliteit" en "niet-functionele vereisten"?

Productkwaliteit is een breder begrip dat niet alleen formaliseerbare parameters omvat, maar ook subjectieve beoordelingen (bijv. UX/UI gebruiksgemak). NFR zijn duidelijk meetbare kenmerken (prestaties, betrouwbaarheid, enz.) die onderworpen zijn aan automatische validatie.

Kan een analist het bepalen van alle niet-functionele vereisten aan de architect overlaten?

Nee, de analist moet samen met de architect en het bedrijfsleven deze vereisten identificeren in de analysefase, anders zullen de vereisten incompleet zijn of alleen vanuit technisch perspectief worden beschreven, zonder rekening te houden met zakelijke behoeften.

Kunnen niet-functionele vereisten alleen in de vorm van algemene uitspraken worden geformuleerd ("het systeem moet betrouwbaar zijn")?

Nee, dergelijke formuleringen zijn ongeschikt voor controle en testing. Specificatie is vereist: bijvoorbeeld, "de hersteltijd van de service na een storing mag niet langer zijn dan 10 minuten".

Veelvoorkomende fouten en antipatronen

Formuleren van vereisten zonder testbare criteria ("snel", "cool", "betrouwbaar").
Het overslaan van hele klassen NFR (bijvoorbeeld, veiligheid voor interne systemen).
Inconsistente vereisten tussen de opdrachtgever en de ondersteuning.

Voorbeeld uit de praktijk

Negatieve case: Het project van het nationale portaal voor overheidsdiensten heeft geen vereisten voor pieklasten geformaliseerd. Het systeem "viel uit" op dagen dat populaire diensten werden gelanceerd, wat leidde tot beveiligingsincidenten.

Voordelen:

Snelle MVP

Nadelen:

Hoge kosten voor aanpassingen
Verlies van gebruikersvertrouwen
Moeilijkheden met ondersteuning

Positieve case: De analist heeft bij de start van het industriële automatiseringsproject samen met de operatie vastgesteld dat systeemstilstanden belangrijker zijn dan nieuwe functies. Hij heeft SLA, noodscenario's uitgewerkt en specifieke metrics vastgelegd.