In mijn eerdere blog ging ik dieper in op een effectieve aanpak voor het uitvoeren van een GAP-analyse. Een uitkomst van deze analyse kan zijn dat er een nieuw systeem nodig is. Dit nieuwe systeem moet voorzien in de wensen en eisen van de stakeholders. Om dit zo goed mogelijk in kaart te brengen worden er requirements opgehaald bij deze stakeholders. In dit blog wil ik het hebben over de non-functional requirements: wat dit zijn en waarom ze waardevol zijn.   

Wat zijn non-functional requirements? 

Het ophalen van requirements is een taak die bij de Business- en Informatie Analist ligt. Bij requirements wordt er veelal gedacht aan functionele requirements. Functionele requirements beschrijven wat het systeem moet doen om aan de behoeften van de gebruikers te voldoen. Het zijn de specificaties van de functies en het gewenste gedrag dat een systeem moet leveren.

Requirements die regelmatig vergeten worden, maar minstens net zo belangrijk, zijn de non-functionele requirements (NFR’s). De NFR’s zorgen ervoor dat een systeem betrouwbaar, efficiënt en gebruiksvriendelijk is. Ze beschrijven de kwaliteitseisen en ontwerpbeperkingen waaraan een nieuw systeem moet voldoen. Daarnaast hebben ze invloed op de gebruikservaring en de algehele acceptatie van het systeem. 

Welke non-functional requirements zijn er? 

Wanneer je online zoekt naar een overzicht van non-functional requirements categorieën krijg je diverse resultaten. Het meest uitgebreid is de NEN-ISO/IEC 25010. Ik gebruik in praktijk altijd een beperktere set hiervan. Dit was altijd voldoende voor mijn projecten.  In dit blog leg ik uit welke non-functional requirements ik beschrijf in mijn projecten.

• Performance: Performance beschrijft hoe goed een systeem functioneert op het gebied van snelheid, efficiëntie, en resourcegebruik. 
• Betrouwbaarheid (Reliability): Betrouwbaarheid beschrijft het vermogen van een systeem om stabiel en consistent te functioneren binnen de verwachte operationele omstandigheden.
•  Gebruiksvriendelijkheid (Usability): Gebruiksvriendelijkheid beschrijft hoe eenvoudig en efficiënt gebruikers met het systeem kunnen werken om hun doelen te bereiken. 
• Schaalbaarheid (Scalability): Schaalbaarheid beschrijft het vermogen van een systeem om mee te groeien met toenemende belasting of complexiteit zonder in te boeten op prestaties, stabiliteit of gebruiksgemak. 
• Beveiliging (Security): Beveiliging beschrijft de maatregelen en mechanismen die zijn ingebouwd om gegevens, gebruikers, en systemen te beschermen tegen ongeautoriseerde toegang, misbruik, manipulatie en aanvallen. 
• Onderhoudbaarheid (Maintainability): Onderhoudbaarheid verwijst naar het gemak en de effectiviteit waarmee software kan worden aangepast, verbeterd of gecorrigeerd gedurende de levenscyclus van de software.   
• Draagbaarheid (Portability): Draagbaarheid richt zich op de mogelijkheid om het systeem naar andere omgevingen, besturingssystemen of platformen te verplaatsen zonder dat aanpassingen of herstructurering nodig zijn. 
• Compliance: Compliance betreft het voldoen aan regelgeving, standaarden en richtlijnen die relevant zijn voor de software. 
• Beschikbaarheid (Availability): Beschikbaarheid heeft betrekking op hoe vaak en hoe lang het systeem operationeel is voor gebruikers. 
• Uitbreidbaarheid (Extensibility): Uitbreidbaarheid verwijst naar de mogelijkheid om eenvoudig nieuwe functionaliteiten, modules of componenten toe te voegen zonder dat de bestaande code aanzienlijk moet worden aangepast of herschreven. 

Concrete voorbeelden van de non-functional requirements vind je hier. 

Hoe leg ik de non-functional requirements vast? 

Zoals aangegeven is het ophalen van de non-functional requirements een taak voor de Business- en Informatie Analist. Deze requirements moeten bij de stakeholders opgehaald worden. Voorbeelden van stakeholders zijn eindgebruikers, klanten, de opdrachtgever, de systeemontwikkelaar, etc. Het verzamelen van deze informatie kan gedaan worden door het afnemen van interviews of het organiseren van één of meerdere workshops.

De non-functional requirements moeten vervolgens gedocumenteerd worden. Dé manier om non-functional requirements vast te leggen is er niet. Ik kies er meestal voor om ze vast te leggen in een tabel. Deze tabel kan een separaat document zijn, maar het kan ook onderdeel zijn van bijvoorbeeld een Business Analyse Document. Hierbij geef ik iedere requirement een uniek nummer en een titel. Daarbij komt een beschrijving waarbij ik het SMART principe gebruik (specifiek, meetbaar, acceptabel, realistisch, tijdsgebonden). Daarnaast voeg ik acceptatiecriteria toe en geef ik aan onder welke categorie NFR de requirement valt. Door de non-functional requirements op deze manier vast te leggen, is het mogelijk om te testen of het systeem aan alle eisen voldoet. Hiervoor zijn er verschillende soorten testen. Denk bijvoorbeeld aan stress testing, failover testing, penetration testing, usibilty testing en regression testing.