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