In het boek Grip op requirements onderkennen Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis twee indelingen van requirements. De eerste onderverdeling die vaak wordt gebruikt voor requirements is de splitsing in functionele requirements en niet-functionele requirements. De tweede indeling van requirements is het onderkennen van business requirements, gebruikers requirements en systeem- of softwarerequirements.

Functionele requirements vs. niet-functionele requirements

1. Functionele requirements: requirement die het door een systeemfunctie gewenste gedrag beschrijft.

2. Niet-functionele requirements: requirement die niet het gedrag van het systeem beschrijft maar andere systeemeisen definieert (kwaliteitseisen en/of beperkingen waaraan het systeem moet voldoen)

Functionaliteit definiëren Cannegieter, De Swart en Zandhuis als de mogelijkheden die het systeem moet bieden zoals gesteld in functionele requirements.

Kwaliteitsrequirements geven aan hoe goed het beoogde systeem haar functionaliteit moet aanbieden; het gaat om een kwaliteitseigenschap die niet door een functioneel requirement wordt afgedekt. Een beperking is een requirement dat de oplossingsruimte beperkt in aanvulling op de functionele en kwaliteitsrequirements. In tegenstelling tot functionele en kwaliteitsrequirements kun je een beperking niet implementeren; het gaat om eisen die de oplossingsruimte of het ontwikkelproces limiteren. Bijvoorbeeld, 'het systeem moet gebruik maken van een Oracle-database' en 'het systeem moet voor het eind van het jaar operationeel zijn'.

Business requirements, gebruikersrequirements & systeem- of softwarerequirements

1. Business requirements: requirements die beschrijven wat de met het systeem te realiseren doelen zijn (welke toegevoegde waarde heeft het systeem voor de organisatie?).

2. Gebruikersrequirements: requirements die de activiteiten, processen of taken beschrijven die een gebruiker met het systeem wil uitvoeren (op welke manier ga je de business requirements halen?).

3. Systeem- of softwarerequirements: requirements die het gewenste gedrag of de gewenste kwaliteit van het systeem beschrijven (aan welke eisen moet het systeem voldoen?).

Business requirements zijn geformuleerd vanuit het perspectief van bedrijfsdoelstellingen. Gebruikersrequirements vanuit het perspectief van de bedrijfsvoering en de gebruikers. Systeemrequirements worden beschreven vanuit het perspectief van het systeem.

Bron: Grip op requirements, Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis

Grip op requirements
IREB foundation examenstof uitgelegd en praktisch gemaakt
Jan Jaap Cannegieter, Nicole de Swart, Johan Zandhuis

Bij Bol.com | Managementboek | Amazon.nl

Volgens Katarzyna Knot vormt een zgn. boilerplate een goede manier voor het duidelijk en eenduidig vastleggen van requirements. Een boilerplate is een semi-formele methode die je dwingt om requirements op een vaste, gestructureerde manier te beschrijven.

Het International Requirements Engineering Board (IREB) adviseert bovenstaande boilerplate voor het formuleren van requirements.  Een veel gebruikte boilerplate is het formuleren van een user story in termen van:

'Als een <type gebruiker> wil ik <iets doen> zodat ik <deze benefits haal>'

Bron: De manier om requirements goed te formuleren, Katarzyna Knot

Bij het formuleren van een business requirement kan de onderstaande syntax worden gebruikt:

<bedrijf(sonderdeel)> heeft <doel>, daarvoor dient

<proces/systeem> de volgende <prestatie, eigenschappen> te leveren.

Bij het eliciteren van requirements is het zaak de behoeften van gebruikers te vertalen naar meetbare requirements:

Zie ook mijn slideshare-presentatie met de 2 bovenstaande afbeeldingen.

Op haar blog geeft Nicole de Swart de volgende beschrijving van business rules:

Business rules vertonen veel overeenkomsten met requirements maar ze zijn niet hetzelfde. Business rules zijn regels die een bepaald aspect van de business definiëren of beperken. Ze zijn bedoeld om de kenmerken van de business te handhaven of het gedrag van de business te beïnvloeden (Business Rules Group). Business rules zijn onafhankelijk van de werking van het systeem en van de inrichting van het proces. Als de werkzaamheden niet met het systeem maar volledig handmatig uitgevoerd zouden worden, gelden de business rules nog steeds.

Een business rule is vaak de bron van één of meer requirements. Sommige business rules kunnen rechtstreeks overgenomen worden als requirement, bijvoorbeeld de afspraak dat klanten een zescijferig klantnummer krijgen ter identificatie. Voor andere business rules geldt dat ze op verschillende manieren geïmplementeerd kunnen worden.

Volgens Nicole de Swart zijn er vijf soorten bedrijfsregels:

1. Feiten: uitspraken over de business die waar zijn. Het gaat meestal over belangrijke bedrijfsbegrippen en de relaties daartussen (bijv. een hotelreservering geldt altijd voor een aaneengesloten periode).

2. Beperkingen: beperking van de manier waarop de business werkt. Beperkingen zijn te herkennen aan woorden als moeten, mogen niet, alleen toegestaan als (bijv. een reservering mag niet meer dan één jaar van tevoren gedaan worden).

3. Geconditioneerde acties: actie die onder bepaalde voorwaarden wordt geïnitieerd. Deze business rules beginnen vaak met het woord 'als' of 'wanneer' (bijv. als de gasten van een gereserveerde kamer niet voor 18:00 uur hebben ingecheckt en ook niet op de dag zelf telefonisch hebben laten weten hoe laat ze zullen arriveren, wordt de kamer vrijgegeven voor andere gasten).

4. Conclusies: nieuw feit dat ontstaat als een ander feit of een berekening aan een bepaalde voorwaarde voldoet. Ook deze business rules beginnen vaak met het woord 'als' of 'wanneer', maar daarop volgt een nieuw feit en geen actie zoals bij de vorige categorie (bijv. als op één van de dagen in de gewenste reserveringsperiode geen kamer beschikbaar is, is de hele reservering niet mogelijk).

5. Berekeningen: een berekening kan gepaard gaan met ingewikkelde rekenregels of wiskundige formules. Denk aan de rekenregels waaraan de salarisadministratie moet voldoen (bijv. de totaalprijs van een reservering moet berekend worden door <rekenregel>).

Bron: Business rules

In het boek SMART Requirements 2.0 beschrijven Jasper Zandvliet, Ömer Aydinli en Edwin Hendriks hun visie waarmee ze vanuit hun SMART requirements-methode kijken naar softwareontwikkeling. :

De lussen in de bovenstaande afbeelding representeren de verschillende ontwikkelcycli van de softwareontwikeling. Volgens Aydinli, Hendriks & Zandvliet is het type softwareontwikkeling (waterval,iteratief, agile, enz.) is bepalend voor het aantal lussen dat doorlopen wordt en de 'omvang' van de lus(sen). De individuele stappen binnen de lussen zijn altijd hetzelfde, onafhankelijk van de gehanteerde aanpak. Hierbij kan de diepgang van de verschillende stapjes overigens wel variëren.

1. Wens en elicitatie: softwareontwikkeling begint met de wens van de business. Je wilt software ontwikkelen die één op één overeenkomt met de wens van de business. Vaak is deze wens nog weinig concreet en zal deze tijdens 'elicitatie' tastbaar moeten worden gemaakt.

2. Requirements: Aydinli, Hendriks & Zandvliet definiëren requirements als de eisen, wensen en voorwaarden waaraan een product of dienst (resultaat) of een proces of het te gebruiken systeem moeten voldoen. De requirements geven in de eerste plaats aan aan welke voorwaarden het te ontwikkelen resultaat moet voldoen. Naast de requirements voor het resultaat zijn er nog twee andere vormen van requirements: (i) requirements voor de manier waarop het proces om het resultaat te realiseren moet worden uitgevoerd, en (ii) requirements voor de (ICT-)systemen die gebruikt moeten worden.

3. Specificaties: requirements worden verder gedetailleerd in specificaties. Deze beschrijven de manier waarop de requirements moeten worden vormgegeven en hoe zij worden doorgevoerd binnen de resultaten, processen en systemen.

4. Proces: nadat de requirements helder zijn, is het zaak een proces te ontwerpen om het gewenste resultaat te bereiken. Dit proces is gebaseerd op zowel de specifaties van het resultaat als de aanvullende requirements die gaan over de manier waarop het proces moet worden uitgevoerd.

5. Bouw/Test: wanneer de requirements en specificaties eenduidig zijn beschik je over alle benodigde informatie om aan de slag te gaan met het ontwikkelen en testen van de benodigde ICT-middelen.

6. Acceptatie: de requirements zijn geëvalueerd en geaccordeerd door de business en vormen daarmee het 'contrat' op basis waarvan de oplossingen voor de business worden ontwikkeld. Acceptatie vindt plaats op basis van de door de business geaccordeerde requirements. Op deze manier fungeren de requirements als acceptatiecriteria.

7. Software: na acceptatie van het resultaat, beschikt de business over software die gebruikt kan worden in de dagelijkse praktijk.

Bron: SMART Requirements 2.0, Jasper Zandvliet, Ömer Aydinli en Edwin Hendriks

Requirements-goeroe Nicole de Swart (auteur van het Handboek Requirements) geeft op haar website zeven tips om requirements SMART (Specifiek, Meetbaar, Acceptabel, Realiseerbaar en Tijdgebonden) te maken:

1. Maak actieve zinnen. Het is dan expliciet wie de actie uitvoert.

2. Vermijd vage woorden. Deze woorden geven onvoldoende informatie.

3. Maak requirements atomair. Ze kunnen dan niet verder opgesplitst worden.

4. Zet het kernpunt aan het begin van de zin. De zin is dan duidelijker en makkelijker leesbaar.

5. Formuleer requirements positief. Negatieve zinnen met ontkenningen geven niet expliciet aan wat wel gewenst is.

6. Kwantificeer waar mogelijk. Dat maakt requirements meetbaar.

7. Gebruik geen homoniemen. Die leiden tot ambiguïteit.

Bron: SMART requirements: 10 voorbeelden, Nicole de Swart

Volgens Basile Lemaire is het vaak lastig binnen projecten requirements goed te prioriteren. "Bestaande methodieken zijn omslachtig of onnodig complex. Een ander probleem is dat prioriteiten vaak worden bepaald vanuit een it-perspectief in plaats vanuit de bedrijfsvoering. Helaas komt het ook vaak voor dat degene die het hardste roept, bepaalt wat een ‘must’ is." Lemaire ontwikkelde een instrument voor het prioriteren van requirements: het Bulk & Gedonder kwadrant.

Omdat binnen business analyse de MoSCow-methodiek vaak gebruik wordt voor het prioriteren van requirements, gaat Lemaire uitgebreid in op de nadelen van deze methode. Voor wie MoSCow nog niet kent, het is een acroniem van vier categorieën waarin - in dit geval - requirements worden ingedeeld:

1. Must have: requirement is noodzakelijk voor projectsucces.

2. Should have: requirement is belangrijk maar minder tijdkritisch als de must-have, of er is een ‘workaround’ om in de werkpraktijk toch aan het requirement te kunnen voldoen.

3. Could have: requirement is niet belangrijk voor projectsucces; mee te nemen als het weinig kost en wel veel oplevert.

4. Won’t have: requirement draagt weinig bij aan projectsucces of is weinig rendabel en wordt in ieder geval niet nu geïmplementeerd.

Lemaire beoordeelt MoSCoW als een prima methode (eenvoudig, prioriteren vanuit bedrijfsvoering), maar onderkent drie mogelijke nadelen:

1. Het is lastig te bepalen te bepalen in hoeverre een requirement bijdraagt aan succes. In de praktijk bestaat daarbij het risico dat het aan grootste deel van de requirements een must-have wordt toegekend; iedereen wil zeker stellen dat zijn wens wordt meegenomen.

2. Risico van ‘trade-offs’ of compromissen: ik ga mee met jouw must-have voor dit requirement als jij meegaat met mijn must-have voor dat requirement.

3. Risico dat de stakeholder die het hardst roept of het meeste macht uitoefent, bepaalt wat de must-haves zijn. De vraag is dan in hoeverre het gaat om bedrijfsbelangen of om zijn belangen.

Deze nadelen pleiten - aldus Lemaire - voor "een methodiek die vanuit de bedrijfsvoering op een eenvoudige, transparante manier kan prioriteren terwijl eventueel ‘machtsmisbruik’ wordt tegengegaan": het Bulk & Gedonder-kwadrant.

Het Kwadrant gaat uit van afbreukrisico: wat zijn de consequenties wanneer er niet aan een requirement wordt voldaan? Per requirement wordt de prioriteit
bepaald. Het prioriteren geschiedt met stakeholders vanuit de bedrijfsvoering zoals klanten, gebruikers, proceseigenaren en functioneel beheerders. It-risico’s worden in principe als irrelevant beschouwd. Een risico is namelijk pas een risico als een bedrijfsproces in gevaar komt. Dat daar mogelijk een it-probleem
aan ten grondslag ligt, is belangrijk voor je implementatie en oplossing maar niet voor je prioritering.

De prioritering vindt plaats aan de hand van twee assen, de Bulk-as en de Gedonder-as. De Bulk-as: als aan dit requirement niet wordt voldaan, hebben daar (onacceptabel) veel eindgebruikers last van. De Gedonder-as: als aan dit requirement niet wordt voldaan, volgt escalatie (‘komt er gedonder van’).

Op basis van de twee assen kunnen vier kwadranten worden onderkend, die staan voor een prioriteit 1, prioriteit 2 of prioriteit 3:

1. Prio 1: requirement moet correct geïmplementeerd en grondig getest zijn. Indien het (nog) niet correct geïmplementeerd, is de consequentie dat de volgende projectfase, of de in productiename, moet worden uitgesteldust have: requirement is noodzakelijk voor projectsucces.

2. Prio 2: requirement moet in principe correct geïmplementeerd zijn. De opdrachtgever kan er bij tijdsdruk echter voor kiezen dat pas in een volgende projectfase of release aan het requirement moet zijn voldaan.

3. Prio 3: requirement mag onder tijdsdruk of bij budgetbeperkingen sneuvelen; hier gaat men vanuit de bedrijfsvoering geen (serieuze) last van hebben.

Prioriteren volgens het Bulk en Gedonder-kwadrant heeft twee belangrijke voordelen. Allereerst zal een stakeholder, wanneer hij graag wil dat een requirement een hogere prioriteit krijgt, moeten kunnen aantonen dat, door niet te voldoen aan dat requirement, de gebruikerspopulatie er last van kan hebben of dat de zaak gaat escaleren. Aangeven dat iets een must is op basis van machtspositie of hard roepen, gaat nu niet op.

"Een ander voordeel is dat er geen reden is om over prioriteiten te onderhandelen en compromissen te sluiten; het is nu duidelijk waar de werkelijke risico’s liggen als het gaat om het behalen van succes. De ervaring leert dat stakeholders met elkaar goed in staat zijn te bepalen wanneer er sprake is van onacceptabel veel gebruikers op de Bulk-as. Tevens zijn ze in staat een hele reële inschatting te maken wanneer er sprake is van escalatie. Door het groepsproces ontstaat een open discussie over consequenties, projectdoelstellingen en het behalen van de business case."

Lemaire geeft aan dat de verdeling van de requirements over de drie verschillende prioriteiten vaak als volgt is: 50% van de requirements heeft prioriteit 2, prioriteit 1 en 3 geldt voor elk 25% van de requirements.

Bron: Bulk en Gedonder-kwadrant kan uitkomst bieden, Basile Lemaire, in: Computable 07/10/2011

Volgens Mirjam van den berg herken je slechte requirements aan de onderstaande signalen:

1. Klagende business en ICT (business klaagt dat ICT niet levert wat ze willen. ICT klaagt dat business niet weet wat ze wil).

2. Requirements geformuleerd als oneliners.

3. Veelvuldig gebruik van (onverklaarde) vaktermen.

4. Beschrijving van oplossing in plaats van gewenst resultaat.

5. Woordgebruik laat ruimte voor aannames/interpretatie.

6. Vooral aandacht voor wat het systeem moet doen (functionaliteit) en minder naar hoe goed het systeem iets moet doen (kwaliteit).

7. Requirements laten zich moeilijk vertalen naar goede en meetbare testgevallen.

8. Meervoudige verwachtingen gebundeld in één requirement (geven problemen bij scoping en testen).

9. Géén (duidelijke) rangorde tussen requirements.

Bron: 10 signalen dat je te maken hebt met slechte requirements, Mirjam van den Berg

Nicole de Swart - auteur van het Handboek Requirements - geeft in haar artikel SMART requirements vijf tips voor het schrijven van specifieke en eenduidige requirements:

1. Formuleer vage woorden specifieker ('vaag' staat voor woorden die ruimte geven voor een eigen invulling, zoals bijvoorbeeld 'behandelen', 'afhandelen', 'verwerken').

2. Herformuleer dubbele ontkenningen (omdat dit niet prettig leest en vaak onduidelijk is).

3. Splits meervoudige condities waarin zowel 'en' als 'of' voorkomt op (en voorkom interpretatieverschillen door deze condities op te splitsen in afzonderlijke requirements).

4. Vervang meervoudige condities met geneste 'als dan'-constructies door opsommingen van de condities.

5. Herformuleer negatieve requirements (laat requirements aangeven onder welke voorwaarde het systeem een actie wél moet uitvoeren).

Bron: SMART requirements, Nicole de Swart