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

Een veelgebruikte onderverdeling van requirements is het onderscheid in functionele en niet-functionele requirements. Een functionele requirement geeft gewenst gedrag van het systeem weer, terwijl niet-functionele requirements een kwaliteitseis is waaraan het systeem moet voldoen.

Volgens De Swart moet onderscheid gemaakt worden tussen een functionele requirement en een gewenste systeemfunctie. Een functioneel requirement stelt een eis aan het gedrag van een systeem, terwijl een systeemfunctie dat gedrag zélf representeert.

"Een systeemfunctie zet invoer van het systeem om in uitvoer. De actie die het systeem hiervoor uitvoert is de systeemfunctie ofwel het gedrag van het systeem. Een traditioneel functioneel ontwerp is een ontwerp van de gewenste (niet-technische) systeemfuncties en de benodigde systeeminvoer en -uitvoer."

Volgens De Swart impliceert het verschil tussen systeemfuncties en functionele requirements dat een functioneel ontwerp vervangen wordt door een requirementsspecificatie: eisen kun je namelijk niet ontwerpen. De business stelt eisen aan het systeem en een requirements moet deze eisen expliciet maken door ze te specificeren in de zgn. requirementsspecificatie.

Bron: Handboek Requirements (2010), Nicole de Swart

De Swart stelt dat het logisch en onvermijdelijk is dat requirements tussentijds wijzigen. Volgens haar is het idee achter de waterval-aanpak dat eenmaal opgestelde requirements voor de rest van het traject bevroren kunnen worden achterhaald.

In de woorden van De Swart:

"De business en de gewenste ondersteuning daarvan door het systeem staan niet stil tijdens de looptijd van het softwareontwikkelingstraject. Daarnaast is het optreden van voortschrijdend inzicht bij de betrokken gebruikers een normaal verschijnsel. Het managen van de wijzigende requirements voorkomt het zo gevreesde verschijnsel scope creept waarbij de omvang van de te ontwikkelen software ongemerkt of ongecontroleerd blijft toenemen. Hiervoor moet het ontwikkelteam inzicht hebben in de wijzingen, de actuele versie en de status van de requirements."

Bron: Handboek Requirements (2010), Nicole de Swart

Volgens De Swart zijn requirements buitengewoon belangrijk voor succesvolle softwareontwikkeling. Zij citeert in dit verband Karl Wiegers: "Als het niet lukt om de requirements te achterhalen, maakt het ook niet uit meer hoe goed je de overige activiteiten uitvoert" en stelt dat inconsistente, ontbrekende en foutieve requirements doorwerken in vrijwel alle softwareontwikkelactiviteiten.

Fouten die tijdens het opstellen van requirements worden ontdekt en hersteld kosten volgens De Swart vijf tot tien keer minder dan dezelfde fout die tijdens realisatie wordt ontdekt en hersteld. Als die fout pas na ingebruikname zou zijn ontdekt, zouden de herstelkosten 200 keer zoveel zijn dan tijdens het opstellen van de requirements (zie ook Wet van Boehm).

De Swart is van mening dat problemen binnen softwareontwikkeling vaak te maken hebben met requirements, waarbij de oorzaak vaak ligt bij: (a) gebrekkige kwaliteit van de specificatie van requirements, (b) wijzigingen in de requirements, en (c) gebrek aan gebruikersinbreng. Deze problemen zijn te vertalen naar drie kritieke succesfactoren voor softwareontwikkeling:

1. Kwalitatief goede requirementsspecificaties: volledigheid, consistentie, eenduidigheid, bijdragend aan bedrijfsdoel ('validiteit')

2. Managen van wijzigingen in de requirements

3. Voldoende gebruikersinbreng

Bron: Handboek Requirements (2010), Nicole de Swart

De term 'requirements' binnen de context van systeemontwikkeling betekent letterlijk behoefte of eis. In de betekenis van 'behoefte' is een requirement een behoefte aan geautomatiseerde ondersteuning. Bij een requirement als 'eis', gaat het om eisen aan die worden gesteld aan het systeem in termen van gedrag of kwaliteit.

Een veel gebruikte definitie voor requirements (IEEE) is dat requirements staan voor: (a) een conditie of capaciteit die een gebruiker nodig heeft om een probleem op te lossen of een doel te bereiken, (b) eis ten aanzien van wat een systeem(deel) moet 'zijn' of 'doen' om te voldoen aan formele eisen (contract, standaard, ed), of (c) een gedocumenteerde representatie van (a) of (b).

De eerste twee delen van de IEEE-definitie zijn samen te vatten in 'gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business.

De Swart definieert een requirement als: (i) een behoefte aan geautomatiseerde ondersteuning: een proces of een verbetering daarin, die een belanghebbende uit de business (deels) met behulp van het systeem wil uitvoeren,  en (ii) een eis aan een systeem: gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business.

Elke requirement is een eis en geeft een behoefte weer, maar niet elke eis en iedere behoefte zijn een requirement. Een behoefte is alleen een requirements als het gaat om een behoefte van een belanghebbende uit de business om met behulp van het systeem een proces uit te voeren of een procesverbetering te realiseren. Een eis is alleen een requirement als het gaat om een eis die betrekking heeft op het gedrag of de kwaliteit van het systeem om daarmee te voorzien in een behoefte van een belanghebbende uit de business. Een requirement is dus geen synoniem voor eis. Het zijn eisen die gesteld worden aan het gedrag of de kwaliteit van het systeem om in een behoefte van een belanghebbende uit de business te voorzien.

Volgens De Swart vormen requirements als het ware een brug tussen de belanghebbenden uit de business en de softwareontwikkelaars. De requirements geven aan wat het systeem moet kunnen om: de business optimaal te ondersteunen én de ontwikkelaars duidelijk te maken wat ze moeten realiseren.

Wat requirements niet zijn

Technische beperking
Een technische beperking (meestal voortkomend uit het ICT-beleid, bijv. beperkingen in ontwikkelplatformen en communicatieprotocollen) is geen requirement maar stelt wel eisen aan de implementatie van een requirement.

Ontwerpbeslissing
Een ontwerpbeslissing is een beslissing over de manier waarop een requirement geïmplementeerd wordt, rekening houdend met de technische beperkingen. Volgens De Swart zitten er vaak ontwerpbeslissingen in de specificaties van requirements verborgen omdat mensen meer in oplossingen denken dan in requirements. Het nadeel van 'impliciete ontwerpbeslissingen' is dat ongemerkt andere, misschien wel betere oplossingen worden uitgesloten.

Bedrijfsregel
Een bedrijfsregels is een regel die een bepaalt aspect van de business definieert of beperkt. Het is bedoeld om de kenmerken van de business te handhaven of het gedrag van de business te beïnvloeden. Een bedrijfsregel komt onder andere voort uit het bedrijfsbeleid, uit wet- en regelgeving. Een bedrijfsregel is geen requirement maar is in de praktijk vaak de bron van één of meer requirements. Een bedrijfsregel is onafhankelijk van de werking van het systeem en van de inrichting van het proces. Sommige bedrijfsregels kunnen rechtstreeks worden overgenomen als requirement, bijvoorbeeld de afspraak dat klanten een zescijferig klantnummer krijgen ter identificatie. Andere bedrijfsregels kunnen op verschillende manieren worden geïmplementeerd.

Bron: Handboek Requirements (2010), Nicole de Swart

Requirements engineering gaat over het definiëren, documenteren en onderhouden van requirements gedurende de levenscyclus van de ontwikkeling van een informatiesysteem. Requirements engineering is een iteratief proces. Eerst moeten de business requirements worden ontwikkeld en vastgesteld ('gebaselined'), vervoglens vormen de business requirements input voor het ontwikkelen van requirements op gebruikersniveau. Hierbij kan het nodig zijn de business requirements aan te vullen en/of verder te verfijnen.

Requirements engineering wordt onderverdeeld in: (1) requirements development, en (2) requirements management.

Requirements development omvat alle activiteiten voor het identificeren en vastleggen van requirement en het vervolgens bereiken van overeenstemming over de requirements.

Volgens De Swart is het doel van requirements engineering het tot stand brengen en in stand houden van overeenstemming tussen de opdrachtgever, medewerkers en de softwareontwikkelaars over de requirements. Requirements development richt zich op het tot stand brengen van de overeenstemming.

Requirements development omvat alle activiteiten die problemen, kansen en behoeften omzetten naar een overeengekomen set aan requirements, de zgn. baseline. Anders gezegd gaat het om de activiteiten die nodig zijn om nieuwe requirements aan de baseline toe te voegen. Het begint bij het in kaart brengen van globale requirements, waarna de requirements tot op het gewenst detailniveau worden gespecificeerd. De gedetailleerde requirements in de baseline dienen bij een waterval- of iteratief ontwikkeltraject als basis voor de realisatie van het systeem.

Bij het specificeren van requirements dreigt volgens De Swart altijd verlammingsgevaar (analysis paralysis): de specificaties van requirements zijn nooit perfect, het kan altijd beter, completer en duidelijker. Het risico is dus dat je té lang doorgaat met het perfectioneren van beschreven requirements. Requirements development streeft naar requirementsspecificaties die 'goed genoeg' zijn om met een aanvaardbaar risico te starten met het realiseren van het systeem. Het risico bestaat in dit verband uit de kosten voor en het uitvoeren van herstelwerkzaamheden bij fouten in reeds goedgekeurde specificaties. De kwaliteit van de requirementsspecificaties is hoog genoeg, zodra de kosten voor het nog verder verhogen van de kwaliteit van de requirementsspecificaties niet meer opwegen tegen de verwachte herstelkosten later in het traject.

Volgens De Swart zijn 'de requirements in de baseline namelijk niet in beton gegotenen geldt: "Hoewel de requirements in de baseline zijn goedgekeurd en misschien zelfs al zijn geïmplementeerd, zijn wijzigingen daarin onvermiijdelijk. Dit komt omdat de wereld niet stil staat tijdens de ontwikkeling van het systeem." Als gevolg van wijzigingen in de omgeving en voortschrijdend inzicht, zullen namelijk gedurende de gehele cyclus van softwareontwikkeling wijzigingen plaats (moeten) vinden. Requirements management omvat alle activiteiten die nodig zijn om wijzigingen in de specificaties van de requirements in de baseline door te voeren. Doel hiervan is het gecontroleerd laten plaatsvinden van wijzigingen. De activiteiten met betrekking tot het omgaan met wijzigingen op requirements die 'gebaselined' zijn: het doen van wijzigingsverzoeken, het uitvoeren van impactanalyses en de besluitvorming over en invoering van goedgekeurde wijzigingen.

De Swart onderscheid vier processtappen, met daarbinnen specifieke activiteiten

Requirements development

(1) Positioneren van het systeem binnen het businessdomein

• Analyseren van de business
• Zoeken van belanghebbenden en gesprekspartners

(2) Definiëren van de gewenste oplossing

• Vaststellen behoeften en eisen aan geautomatiseerde ondersteuning
• Selecteren belangrijkste kwaliteitseigenschappen
• Identificeren technische beperkingen
• Afbakenen systeem

(3) Detailleren van de requirements

• Vaststellen van door het systeem uit te voeren activiteiten
• Vaststellen van benodigde kwaliteitsniveau van het systeem

Volgens De Swart zijn bij elk van de drie processtappen binnen requirements development vier subgebieden nodig:

[i] Elicitatie (expliciet maken van requirements)
[ii] Analyse (onderzoeken requirements op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid)
[iii] Specificatie (vastleggen van requirements, incl. meta-informatie)
[iv] Validatie (zekerstellen dat gespecificeerde requirements overeenkomen met behoeften van de business)

Requirements managmeent

(4) Beheren van de requirements

Volgens De Swart rust requirements management op vijf pijlers:

[a] Wijzigingsbeheer
[b] Versiebeheer
[c] Traceerbaarheid
[d] Metagegevens
[e] Managementoverzichten (inzicht in stand van de requirements in de baseline)

Bron:  Software Requirements Engineering: What, Why, Who, When and How (Linda Westfall), Handboek Requirements (2010), Nicole de Swart

Users requirements beschrijven de taken die gebruikers moeten kunnen uitvoeren door gebruik te maken van het nieuwe product of systeem.

Use cases zijn uitermate geschikt voor het beschrijven van de user requirements.

User requirements kijken naar de functionaliteit van het systeem vanuit het perspectief van de gebruiker. Deze requirements geven aan wat het systeem moet doen om de gebruikers in staat te stellen hun doelen te bereiken. Er kunnen meerdere user requirements nodig zijn om een enkel business requirement te realiseren.

Een belangrijk aspect van het eliciteren van requirements is het classificeren van gebruikersgroepen. Dit houdt in dat je op zoek moet gaan naar groepen van gebruikers die verschillend zijn voor wat betreft: frequentie van het gebruik, de gebruikte eigenschappen (features), toegangsniveaus, of anderzins.

Bron: 10 Requirements Traps to Avoid (Karl E. Wiegers), Software Requirements Engineering: What, Why, Who, When and How (Linda Westfall)

Requirements geven aan wat de eisen en behoeften zijn voor aanpassingen en uitbreidingen in de geautomatiseerde ondersteuning van de bedrijfsprocessen van belanghebbenden uit de business. Bij requirements gaat het vooral om het afstemmen van verwachtingen.

Belanghebbenden

1. Opdrachtgever, belangrijkste belanghebbende omdat het nieuwe/aangepaste systeem hem moet helpen bedrijfsdoelen te halen of problemen op te lossen. De requirements van andere belanghebbenden moeten bijdragen aan het behalen van de requirements van de opdrachtgever. De requiremetns van de opdrachtgever geven aan wat het te ontwikkelen cq. aan te passen systeem moet kunnen om het beoogde bedrijfsdoel te halen..

2. Opdrachtnemer, requirements zijn vooral van belang voor het inschatten van kosten, maken van planningen en het op een goede manier kunnen inzetten van medewerkers.

3. Ontwikkelaars, basis van het systeemontwerp en realisatie.

4. Testers, requirements  zijn de norm waaraan de ontwikkelde software kan worden getoetst.

5. Gebruikers, requirements beïnvloeden in hoge mate of de gebruiker zijn werk goed en op een prettige manier kan uitvoeren.

Bron: Handboek requirements (2010), Nicole de Swart