Requirement is een veelgebruikte term binnen softwareontwikkeling. Toch is de betekenis ervan niet altijd duidelijk. In de praktijk gebruiken veel mensen het woord eis als synoniem voor requirement. Dit is onterecht, omdat niet alle eisen tevens requirements zijn. Requirements zijn alleen die eisen die gesteld worden aan het gedrag of de kwaliteit van het systeem om te voorzien in behoeften van een belanghebbenden uit de business.
Bijvoorbeeld de onderstaande eisen zijn geen requirements:
– Het project moet het Rational Unified Process (RUP) volgen;
– Het systeem moet gebruik maken van een Oracle DBMS;
– De rekenmodule moet de maandlasten van de hypotheek berekenen;
– Over een hotelovernachting moet het hoge btw-tarief geheven worden.
It-projecten en -systemen moeten naast requirements nog aan een heleboel andere eisen voldoen. Veel van die eisen hebben een sterke relatie met requirements en worden daarom vaak voor requirements aangezien. Toch is het verstandig om project constraints, design constraints, ontwerpbeslissingen en business rules expliciet te onderscheiden.
Project constraints
Dit zijn eisen waaraan het project moet voldoen die te maken hebben met kosten, doorlooptijd, bemensing, projectfasering, ontwikkelproces en op te leveren producten. Ze maken onderdeel uit van het vakgebied projectmanagement. Deze eisen worden soms (ten onrechte) aangeduid met project requirements.
Enkele voorbeelden van project constraints:
– Het project moet het rational unified process (rup) volgen;
– Het systeem moet eind volgend jaar operationeel zijn;
– Het projectteam moet ook gebruikersdocumentatie opleveren.
Design constraints
Design constraints (technische beperkingen) zijn eisen die voorschrijven dat bepaalde technologieën gebruikt moeten worden of dat de requirements op een bepaalde manier geïmplementeerd moeten worden. Denk aan beperkingen in ontwikkelplatformen en communicatieprotocollen. Design constraints komen meestal voort uit het ict-beleid of de enterprise architectuur. Ze beperken de ruimte die softwarearchitecten en ontwikkelaars hebben om de requirements te implementeren.
Enkele voorbeelden van design constraints:
– Het systeem moet gebruik maken van een Oracle DBMS;
– Alle klantgegevens moeten in het crs-systeem worden opgeslagen;
– De ws-Interoperability standaard voor elektronische berichten moeten gevolgd worden.
Ontwerpbeslissingen
Deze beslissingen stellen eisen aan de manier waarop de requirements geïmplementeerd worden, rekening houdend met de design constraints. Ontwerpbeslissingen kunnen gaan over de opbouw van de software of over de interactie tussen het systeem en zijn omgeving. Een softwarearchitectuur en een schermontwerp bevatten veel ontwerpbeslissingen.
Enkele voorbeelden van ontwerpbeslissingen:
– Er komt een afzonderlijke rekenmodule voor de complexe berekeningen;
– Er moet voortdurend een klok in de linkeronderhoek getoond worden;
– De managementinformatie moet in een grafiek weergegeven worden.
Business Rules
Dit zijn regels die een bepaald aspect van de business definiëren of beperken. Het is bedoeld om de kenmerken van de business te handhaven of het gedrag van de business te beïnvloeden (Business Rules Group). Business rules komen onder andere voort uit het bedrijfsbeleid, uit wet- en regelgeving en uit branchestandaarden. Ze zijn vaak de bron voor één of meer requirements. De systemen moeten voldoen aan deze business rules of ze zelfs afdwingen.
Enkele voorbeelden van business rules:
– Over een hotelovernachting moet het hoge btw-tarief geheven worden;
– Een reservering mag niet meer dan één jaar van tevoren gedaan worden;
– Als de gasten van een gereserveerde kamer niet voor 18.00 uur hebben ingecheckt wordt de kamer vrijgegeven voor andere hotelgasten.
@Nicole:
De zin uit je reactie: “Daarbij is het m.i. belangrijk om je te concentreren op de ‘echte’ requirements en project constraints, design constraints en ontwerpbeslissingen (die absoluut belangrijk zijn in een IT-project) voornamelijk aan anderen over te laten.” is hetgeen ik miste in je artikel, namelijk het “waarom” of “de toegevoegde waarde” van je hele betoog.
Waarvoor dank
Ik ben het helemaal met Henri eens. Requirements volledig uitschrijven en exact proberen te specificeren werkt niet (en is idd onmogelijk). Ik heb nergens dikke documenten met requirements bepleit. Kennelijk is dat de associatie van mensen als je het over requirements hebt.
Ik ben net als Henri voorstander van agile ontwikkeling. De software wordt dan incrementeel en iteratie ontwikkeld waardoor de requirements niet op voorhand uitgekristalliseerd hoeven te zijn.
Wilco, ik heb je gevonden op LinkedIn, en face-to-face vangt meer dan je zomaar op kunt schrijven, ik besef ook wel dat we niet ver van elkaar afzitten in mening. Ik doe al zo lang systeem ontwikkeling in alle mogelijke smaken waardoor je een referentie kader ontwikkeld over wat werkt en wat niet werkt en ik las het artikel inderdaad alsof requirements totaal en compleet moeten zijn, maar met de reactie van jou en Nicole erbij geeft dat wat nuance 🙂
Wel mooi ook dat het artikel verrijkt en aangevuld word met kennis en ervaring, leuk!
Ik zie een levendige discussie waarbij de toon van definities blijkbaar toch niet helemaal de muziek maakt als ik kijk naar aanvullingen. Desondanks ben ik toch benieuwd in hoeverre de ’taaltechnische’ aspecten van invloed zijn op het resultaat bij bijvoorbeeld uitbesteding naar India maar ook bij aanbestingen.
Naast ontwikkelaars en requirement engineers spelen namelijk ook steeds vaker juristen een rol in het spel. En deze hebben soms weer hele andere definities voor eisen en vereisten.
Requirement vertaalt naar eis. Ik begrijp dat het betoog over zachte en harde eisen gaan, maar het anglosisme en barbarisme zal meer mist genereren dan duidelijk verschaffen.
Ook is een synoniem alleen toepasbaar binnen dezelfde taal en niet als er ernstig vergrijp wordt gemaakt aan barbarisme.
De vraag die Ewout uitzet is een goede, doordat we ons zelf verwarren met wazige termen zullen we naar buitenlanders toe helemaal chaotisch overkomen en zal het communiceren een stuk moeilijker worden.
Requirements: (Vereisten, Eis, Behoefte)
User requirements, Functional requirements, Non-functional requirements, Business Requirements, Operational requirements, Financial requirements, security requirements
Constraints: (Beperkingen, kader, besluiten)
Randvoorwaarden, budgetten, doorlooptijden, wet- en regelgeving, normen (ISO, etc)
Rules: (Regels, beleid)
Beleid, principes, uitgangspunten, opdrachtafbakening, wet en regelgeving,
In Nederland ontwerpen we vaak met een programma van Eisen en Wensen die we vervolgens waarderen met MOSCOW en onderverdelen in de verschillende stakeholders op basis van COPAFIT.
Het gehele gebied rond requirements is genormeerd in een IEEE standaard de 29148:2011. Misschien moeten we daar eens beginnen voordat we de zaak zoals in dit artikel wordt gepoogd, door elkaar halen.
Ik vind persoonlijk de keuze tussen een randvoorwaarden en een uitgangspunt altijd al lastig. Kan beide een constaint zijn, maar kan ook beleid zijn. Bijvoorbeeld: Data wordt opgeslagen in een DBMS (randvoorwaarde bijv. vanuit een principe). De DBMS is gebaseerd op MYSQL. (uitgangspunt op basis van beleid). In het artikel zijn deze samengevoegd in een dessin constant….Volgens is DDMS een ontwerp e/o princiep keuze en het merk komt voor uit een beleid. Door het integraal als design contraint op te merken roep je al van alles over je af….
Hoe lastig maken we het in ICT?
@Nicole
je zegt het terecht: binnen jouw vakgebied, daar zit nu net ook de oorzaak van de discussie en de essentie van een behoorlijk aantal comments op je tekst (op zich heel niet verkeerd, zoals je het aankaart!).
Omdat ik niet in de IT, maar in de iCt zit kijk ik er kennelijk wat anders tegen aan. In dat kader heeft de ervaring geleerd dat het effectiever is om aan te sluiten bij de gangbare definities i.p.v. een eigen vakgebied te willen creëren. Het is met regelmaat de basis voor “mis-understanding”.