Waarom gebruik je requirements en risico’s?

René Ceelen, 
3 juli 2019

Veelgestelde vragen zijn: “Waarom zitten er requirements en risico’s in TestMonitor? En hoe moet ik die gebruiken?” In het vorige artikel Testgeval, Testsuite, Testrun: wat is het verschil?” is het onderstaande plaatje al getoond, waarin juist deze definities werden uitgelegd.

Requirements en Risico's

In dit artikel zal ik uitleggen wat requirements en risico’s zijn en hoe je die het beste kunt gebruiken in TestMonitor, zodat je hier het beste profijt van hebt tijdens de gehele testcyclus van plannen, analyseren tot rapporteren.

Wat zijn requirements?

De term requirement is al in de jaren zestig vanuit de software-engineering in gebruik (Barry Boehm). Volgens de wereldwijd erkende Business Analysis Body of Knowledge is een vereiste:

  1. Een voorwaarde of mogelijkheid die een stakeholder nodig heeft om een probleem op te lossen of een doel te bereiken.
  2. Een voorwaarde of mogelijkheid waaraan een oplossing of oplossingscomponent moet voldoen om te voldoen aan een contract, standaard, specificatie of andere formeel opgelegde documenten.
  3. Een gedocumenteerde weergave van een voorwaarde of mogelijkheid zoals in 1 of 2.
 
Dus in de woorden van een leek is een requirement direct wat er moet worden geïmplementeerd en wat we verwachten te krijgen. De requirements bevatten het gedrag, de kenmerken en eigenschappen van het toekomstige systeem. Daarom is de belangrijkste taak van de requirements ervoor te zorgen dat deze door alle belanghebbenden worden begrepen.

Verschillende types requirements

Om efficiënt met de requirements te werken, moet je een onderscheid maken tussen de verschillende soorten. Ik zal er een paar noemen, maar deze lijst is niet uitputtend:

Functionele eisen
 
Functionele eisen geven aan wat het systeem voor de gebruiker moet doen en worden door de klant en opdrachtgever opgesteld. Ze definiëren de werkzaamheid van de software, zodat de gebruikers hun taken gemakkelijk kunnen uitvoeren. 

Niet-functionele eisen

Niet-functionele eisen zijn eisen die ook aan het systeem worden gesteld, maar die niet direct bijdragen aan het bereiken van het doel. Ze zeggen hoe, hoe goed, hoe snel, hoe betrouwbaar het systeem moet zijn. Ze zijn bedoeld als een aanvullende beschrijving van de functies van het product, die belangrijk zijn voor belanghebbenden. 

Organisatie eisen
 
Organisatie eisen zijn de doelen, doelstellingen of behoeften die de organisatie heeft opgesteld. Denk aan winstmaximalisatie, kostenminimalisatie of wettelijke eisen. Binnen TestMonitor worden in dit type de verschillende bedrijfsprocessen benoemd. 

Gebruikerseisen
 
Gebruikerseisen kijken naar de functionaliteit van het systeem vanuit het perspectief van de gebruiker. Zij beschrijven de taken die gebruikers moeten kunnen uitvoeren door gebruik te maken van het nieuwe systeem. Use cases of user stories zijn uitermate geschikt voor het beschrijven van de gebruikerseisen. 

Risico's

Uit de hoek van risicomanagement is de definitie van het begrip risico een gebeurtenis die een negatief of positief effect heeft op het bereiken van de organisatiedoelstellingen. Gebeurtenissen met een positief effect kunnen negatieve effecten compenseren of vertegenwoordigen kansen. Een kans is de mogelijkheid dat een gebeurtenis zich voordoet die op positieve wijze het behalen van doelen kan beïnvloeden, waarbij de creatie, innovatie, of het behoud van waarde wordt versterkt.

Requirements en risico's van TestMonitor

Nadat enkele requirements en risico’s zijn gemaakt, kunnen deze rechtstreeks gekoppeld worden aan afzonderlijke testgevallen, zodat tijdens de analyse of rapporteren van de testresultaten direct een selectie van een bepaalde eis of meerdere gepresenteerd kunnen worden.

requirements
Een extra functionaliteit in TestMonitor is dat de afgeleide issues vanuit de testresultaten automatisch de gekoppelde requirements overneemt. Hiermee kan dezelfde analyse of rapportering plaatsvinden bij de issues. Een operationeel directeur vindt het namelijk prettig om te horen dat 80% van de openstaande issues gerelateerd aan zijn eisen en risico’s na hertest zijn gesloten.
 
Hier als voorbeeld de ‘niet gesloten’ issues voor de eis “automatisch inloggen”. 
automatisch inloggen

Volg ons op Twitter en LinkedIn voor het laatste nieuws. Benieuwd naar welke nieuwe ontwikkelingen er nog meer aan zitten te komen? Bekijk dan eens onze Roadmap!

Probeer het 14 dagen gratis

Start vandaag nog met TestMonitor! Maandelijks betalen, geen lange contracten & altijd te annuleren.