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.
Driemaal raden wat Google Translate als vertaling geeft voor het Engelse “requirement” :-). Dat maakt het wel erg verwarrend.
Mauwerd en Pa Va Ke,
Hoewel het nu al een interessante discussie wordt ben ik vooral benieuwd naar de reactie van Nicole. Want zoals ik al in eerste reactie aangaf gaat het inderdaad niet om de naam maar de aard van het beestje.
@Ewout
van de 10 artikelen die Nicole tot nu toe geschreven heeft heeft ze er op 4 gereageerd en op 6 niet, kortom bedroevend als een auteur een artikel laat plaatsen, zeker omdat, als ik ze zo even doorgelezen heb, er zeer goede comments bij zitten, die haar tot nadenken zouden moeten zetten
@Nicole
Het woord requirement is een niet Nederlands woord, de meest gebruikte vertaling voor requirement is niet het woord eis, maar het woord vereist. IK ben geen taalpurist, maar het gebruik van Engels en Nederlands door elkaar leidt al snel tot “mis-understanding”. Dat blijkt ook met regelmaat uit de comments op je blogs.
Je werk zou daarom ook geen requirement specialist moet heten…
@Ewout … het niet reageren van auteurs op de commentaren op hun artikelen is me al langer een doorn in het oog …
Nooit leuk als je duidelijkheid tracht te scheppen en dit het tegenovergestelde effect lijkt te hebben. Toch denk ik dat dit meevalt.
Nicole geeft duidelijk aan dat er een verschil is tussen enerzijds een requirement, wat te maken heeft met gewenste kwaliteit en gedrag van een systeem, en anderzijds een eis, wat te maken hebben met beperkingen daarop, doorgaans in tijd geld en middelen.
Het kan zijn dat je het met die definitie niet eens bent, maar dat doet niets af aan de intentie van het artikel om onderscheid te (leren) maken tussen wat gewenst is en wat kan.
ICT is vanaf het begin een internationaal georiënteerd vakgebied en het is niet gek dat er veel Engelstalige terminologie ingeslopen is. De kunst is wel die terminologie zo eenduidig en consequent mogelijk te gebruiken.
Er zijn inmiddels enkele (min of meer standaard) werken over requirementsanalyse en –management verschenen waarin minstens goede pogingen worden gedaan die eenduidigheid te creëren.
Persoonlijk houd ik het bij Succes met de requirements, waarin geen onderscheid wordt gemaakt tussen requirements en eisen. Hierin worden requirements gedefinieerd als “een behoefte of doelstelling van een belanghebbende, dan wel een eis, wens of beperking waaraan een systeem dient te voldoen om aan die behoefte of doelstelling tegemoet te komen”.
Dan hebben we het dus over gewenste functionaliteit enerzijds en de mate waarin die functionaliteit moet functioneren anderzijds. Ingewikkelder moeten we het niet maken.
@Hans,
ik ben het geheel met je eens, echter van een requirement specialist(?), zou je natuurlijk wel van meet af aan duidelijkheid mogen verwachten. Juist als je engels en Nederlands door elkaar wil gebruiken. Er is ook een goed en gebruikelijke woord voor requirement in het Nederlands tenslotte.
Het artikel van Nicole is crystal clear. Het klopt aan alle kanten en er rammelt helemaal niets aan. Je kunt jezelf natuurlijk altijd blijven afvragen hoe ver je moet gaan om iets goed uit te leggen. Bijvoorbeeld, wat is in ICT-land de algemeen geaccepteerde definitie van een requirement? Dat is voor de mensen die dagelijks opereren in het snijvlak van business en informatiesystemen normaliter geen issue. “Requirement” is in dat snijvlak voor de één een begrip, voor iemand die daar verder weg van staat een woord wat hij moet opzoeken in het woordenboek. Dat is ook precies de reden waarom in systeemontwikkeltrajecten waarbij gebruik wordt gemaakt van requirements een woordenlijst wordt samengesteld… Maar, kort samengevat, een requirement is een wens van een gebruiker of belanghebbende om een probleem op te lossen of een doel te bereiken, of het is voorwaarde of capaciteit waar een informatiesysteem aan moet (gaan) voldoen of het is de schriftelijke weergave van één van de voorgaande verklaringen.
Wat in het artikel, althans in mijn ogen, sterk naar voren komt is het onderscheid tussen de verschillende soorten eisen/wensen/requirements/contraints/beslissingen/rules. Juist de vaardigheid om dit onderscheid te maken is essentieel om de juiste en scherp afgebakende “boodschappenlijst” te maken voor het toekomstige informatiesysteem en alleen eisen en wensen neer te leggen zonder je te begeven op het terrein van de mensen die zaken als de genoemde ontwerpbeslissingen moeten nemen. Om even te referen aan het voorbeeld met het Oracle dbms: ik heb recentelijk bij een klant voor de groep gestaan en een voorbeeld gegeven voor de specificaties van een auto. Je kunt natuurlijk een auto gaan kopen en die schiiterend mooie zilvergrijze Mercedes SLE kopen met die prachtige lichtmetalen wielen en linnen cabriokap en bij aflevering zwaar teleurgesteld zijn omdat het een schakelbak is en geen automaat. Maar even terug: er kwamen wensen op tafel als leren stoelen, een automaat, airco, lichtmetalen wielen, sportstuur, mistlampen, en van nu naar 100 in 5 seconden. En zo nog 20 specificaties. Maar hoe ziet die auto eruit? Je kunt de gebruiker ook daar nog vragen over stellen. Je komt daar, voorbeeld, aan bij het genoemde ontwerp. Ik kan me helemaal voorstellen, dat de klant daar ook inspraak in wil, bij een auto bijna vanzelfsprekend. Maar die sprint van 0 naar 100 in 5 seconden. Laten we daar de gebruiker beslissen met welke motor we dat gaan doen? Even aannemende dat de gebruiker teverden is als hij van 0 naar 100 kan in 5 seconden, zal het hem denk ik worst zijn met exact welke motor dat gebeurt. Hier komen we aan de kennis, kunde en verantwoordelijkheid van de fabrikant van de motor (equivalent: de maker van de software) over HOE we deze specificatie gaan realiseren. Een Oracle dbms is maar één van de vele mogelijkheden om specifieke eisen qua performance, opslagcapaciteit e.d. die je aan een dbms stelt, te implementeren. Zo kan de wens ten aanzien van de motor worden worden geimplementeerd met een 2.0 liter motor, een turbo met directe inspuiting maar ook met een formule 1-motor.
WAT de klant graag wil op, zeg maar, een logisch en functioneel niveau, dat kan de klant helemaal vrij uiten (zonder garanties op realisatie) en daar kan niemand hem in beperken maar over HOE één en ander wordt gerealiseerd daar kan de klant wellicht over meepraten maar daar ligt een zware stem bij degene die de oplossing gaat leveren. Die is er namelijk verantwoordelijk voor dat de oplossing die geleverd wordt, de juiste is en dat deze solide is. Voor de gebruiker zijn, gezien dit artikel, vooral de “gewone” requirements en de businessruless van belang. Business rules zijn weliswaar een beperking, maar daaruit voortvloeiend leveren ze wel houvast om businessrequirements (en zoals ik het vaak uitdruk: logische en functionele reqs) vast te stellen. Binnen de project constraints kan de klant zich wellicht ook nog roeren, kan van invloed zijn op de beslissing om het project wel of niet te starten. Met design costraints en ontwerpbeslissingen kom je op het terrein van (bestaande) ict-architectuur (hard- en software), ontwikkeltools, beheer en dus op het terrein van de verantwoordelijkheid van een leverancier of beheerder. Daar zit geen academisch woord bij.
En over het nut van “Requirements”, al mag je ze van mij natuurlijk ook eisen, wensen of verwachting noemen (om het academische sausje weg te laten): als je iets koopt, dan wil je toch dat je het juiste artikel krijgt? Dan moet je dat als klant ook goed kunnen uitleggen cq. bij die vraagstelling geholpen willen en durven worden! En definities: die zijn er niet voor niets. Nicole heeft goed de aandacht gevestigd op zaken waar niet goed op is gelet bij projecten die niet opleveren wat je ervan had verwacht. You don’t need eyes to see, you need vision. Nicole heeft die visie. Nicole, ik hoop dat je ook nog reageert, dat maakt de discussie denk ik alleen maar interessanter.
Tip: kijk niet alleen op google translate, probeer ook eens http://www.interglot.com en vul het woord “requirement” in.
@ Wilco
zo duidelijk is het toch niet als je bijvoorbeeld al “design constraints” technische beperkingen noemt in het artikel, dat zijn namelijk: ontwerpbeperkingen en dat is echt heel wat anders.
@Wilco – bedankt!..goed stuk!…. helder met goede voorbeelden!