De term requirements is een volgens De Swart een verzamelnaam voor allerlei typen systeemeisen en voor de behoeften aan geautomatiseerde ondersteuning van belanghebbenden uit de business. In haar 'Handboek requirements' beschrijft zij een requirementsmodel waarbij zij zich baseert op een analyse van de bonte verzamelingen aan typeringen die binnen het vakgebied Requirements engineering van requirements worden gegeven.
In het requirementsmodel onderscheidt De Swart twee perspectieven: het systeemperspectief, met daarin de softwarerequirements, en het business perspectief, met daarin de business requirements en de gebruikersrequirements.
Het systeemperspectief: functionele en niet-functionele software requirements
Het systeemperspectief gaat over de eisen die vanuit de business aan het systeem worden gesteld, waarbij het gaat om requirements van het type softwarerequirements. De Swart definieert softwarerequirements als het gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business. Het gaat dus om systeemeisen die voortkomen uit behoeften van de business (bijvoorbeeld: het systeem moet maximaal twee seconden nadat de klant een zoekopdracht heeft gegeven de lijst met gevraagde hotelkamers tonen).
Softwarerequirements kunnen worden onderverdeeld in functionele requirements en niet-functionele requirements. Bij functionele requirements gaat het om het gewenste gedrag (functionaliteit) van het systeem. Het gaat hierbij om van buitenaf waarneembaar gedrag en niet om de interne werking van het systeem. Functionele requirements beschrijven de input die het systeem nodig heeft, de output die het systeem levert en dategene wat ervoor nodig is om de input om te zetten in output, oftewel de systeemfuncties.
De Swart definieert functionele softwarerequirements als het gedrag (functionaliteit) dat een systeem moet vertonen om in een behoefte te voorzien van een belanghebbende uit de business. Functionele requirements komen op verschillende detailniveaus voor. Globale functione requirements geven op hoofdlijnen het gedrag van het systeem weer (bijv. het systeem moet continu actuele statusinformatie geven). Om de software te kunnen ontwikkelen die voldoet aan de behoeften van de business zijn gedetailleerde(re) requirements nodig. Dit kunnen acties zijn die het systeem moet uitvoeren in specifieke situaties en de wijze waarop het systeem bij bepaalde fouten moet reageren.
Niet-functionele requirements zijn de aan het systeem gestelde kwaliteitseisen. Deze eisen hebben betrekking op het systeem als geheel of op een specifieke functie van het systeem; ze geven aan hoe goed het systeem moet werken. De Swart definieert niet-functionele requirements als kwaliteitseisen waaraan het systeem moet voldoen om in een behoefte te voorzien van een belanghebbende uit de business.
Het businessperspectief: business- en gebruikersrequirements
Binnen het businessperspectief gaat het om de behoeften van de business om processen te ondersteunen met geautomatiseerde systemen. Het businessperspectief omvat twee typen requirements: business requirements en gebruikersrequirements. Het businessperspectief voegt aan het systeemperspectief toe 'waarom' het systeem gewenst (business requirements) is en 'wat' voor proces of activiteit het systeem moet ondersteunen (gebruikersrequirements).
Business requirements geven aan welke toegevoegde waarde het systeem moet leveren aan de business. Het systeem is voor de business immers geen doel op zich. De opdrachtgever wil met het systeem een businessdoel realiseren. Heldere business requirements zijn nodig om de kans te vergroten dat een te ontwikkelen systeem daadwerkelijk bijdraagt aan de beoogde doelen. Doelen zijn altijd op te splitsen in subdoelen en ieder doel is ook onderdeel van een hoger liggend doel. Het hoger liggende doel is te achterhalen door te vragen waarom iemand een bepaald doel wil bereiken. Subdoelen zijn te achterhalen door te vragen hoe iemand een bepaald doel wil realiseren. De business requirements bepalen welke gebruikers- en welke softwarerequirements relevant zijn. Requirements die niet bijdragen aan de realisatie van business requirements vallen buiten de scope.
De Swart definieert business requirements als een verbetering in een bestaand proces of een nieuw proces die een belanghebbende uit de business met het systeem wil realiseren (bijvoorbeeld een opdrachtgever die producten via het internetkanaal wil aanbieden). De meeste procesverbeteringen zijn slechts gedeeltelijk met een geautomatiseerd systeem te realiseren. Vaak gaat het om een combinatie van handmatige en geautomatiseerde acties om een proces uit te voeren.
Gebruikersrequirements geven aan op welke manier de business requirements gerealiseerd worden. Ze geven aan welke werkzaamheden door het systeem uitgevoerd of ondersteund moeten worden (bijv. hotelgast wil kamer laten zoeken op basis van ingevoerde selectiecriteria). De Swart definieer gebruikersrequirements als een proces (of subproces of taak of activiteit) die de gebruiker met behulp van het systeem wil uitvoeren. Gebruikersrequirements komen op meerdere detailniveaus voor: ondersteuning van een bedrijfsproces, subproces, procestaak of activiteit. Volgens De Swart hebben gebruikersrequirements de voorkeur bij systemen met veel gebruikersinteractie. Functionele softwarerequirements liggen meer voor de hand bij systemen waarbij zich het belangrijkste deel van de functionaliteit buiten het gezichtsveld van de gebruikers afspeelt (bijv. bij batchprocessen)
Bron: Handboek Requirements (2010), Nicole de Swart
Essentially, all models are wrong, but some are useful.
George E.P. Box
