Antwoord.

Functionele vereisten beschrijven wat het systeem moet doen: bedrijfsoperaties, processen, gebruikersscenario's - dat wil zeggen functionaliteit.

Niet-functionele vereisten bepalen hoe het systeem moet werken: beperkingen, kwaliteitsparameters, prestaties, veiligheid, gebruiksvriendelijkheid, enz. Deze vereisten beïnvloeden vaak de keuze van technologieën, schaalbaarheid en de duurzaamheid van de oplossing.

Waarom is het belangrijk om te onderscheiden:

• Een duidelijke scheiding bevordert het correct formuleren van de taak voor ontwikkelaars en testers.
• Het helpt om het overslaan van kritische kenmerken te voorkomen (bijvoorbeeld, veiligheid, schaalbaarheid).
• Niet-vermoede niet-functionele vereisten worden vaak de bron van projectfalen.

Kernkenmerken:

• Functionele vereisten zijn gedrag van het systeem.
• Niet-functionele vereisten zijn kwaliteit en beperkingen.
• Beide types moeten expliciet worden vastgelegd en goedgekeurd.

Vragen met een twist.

Valt ‘gebruiksvriendelijkheid van de interface’ onder functionele vereisten?

Nee, dat is een niet-functionele parameter (usability). Een functionele vereiste is bijvoorbeeld de aanwezigheid van een knop "Opslaan", de niet-functionele vereiste is de snelheid van de respons en het gebruiksgemak.

Kan ik niet-functionele vereisten negeren als ze niet expliciet door de klant zijn vermeld?

Nee. De analist is verplicht om zelfs impliciete niet-functionele vereisten te bespreken en te formaliseren, anders neemt het risico op een mislukte lancering, klachten van gebruikers en extra kosten toe.

“Het systeem moet 1000 aanvragen per minuut kunnen verwerken”. Is dit een functionele vereiste?

Nee, dit is een niet-functionele vereiste - een prestatiekenmerk.

Typische fouten en anti-patronen

• De nadruk alleen leggen op functionaliteit ("het belangrijkste is dat het werkt, snelheid komt later").
• Impliciete formulering van niet-functionele vereisten - "het moet snel zijn", "betrouwbaar", "veilig".
• Het negeren van niet-functionele testen.

Voorbeeld uit het leven

Negatieve case: Het systeem heeft de opgegeven zakelijke functionaliteit volledig gerealiseerd, maar begon te "vertragen" bij hoge belasting, omdat de prestaties helemaal niet in aanmerking waren genomen. Voordelen:

• Snelle ontwikkeling, nauwkeurige uitvoering van de opgegeven scenario's. Nadelen:
• Het systeem is niet geschikt voor gebruik onder werkelijke belasting, het bedrijf moest de architectuur urgent herzien.

Positieve case: De analist heeft samen met de architect en de klant de maximale belasting, reactietijdcriteria vastgelegd en belastingstests uitgevoerd. Voordelen:

• Het product werkte stabiel en weerstond de groei van gebruikers.
• De ontwikkelingsplannen voorzagen in schaalbaarheid. Nadelen:
• In de ontwerpfase moest meer tijd worden besteed aan discussie en extra tests.