Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Niet elke eis is een requirement

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.

Eisen versus requirements

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4793962). © Jaarbeurs IT Media.
?

 

Reacties

Nicole,

Een leuk stuk over definities waarbij ik het wel idee heb dat er vanuit een specifieke discipline een monopolie gelegd wordt op Engelse termen zoals requirements, constraints en rules. De specifieke onderverdeling van eisen vanuit verschillende stakeholders (alweer zo'n begrip) is niet onterecht maar dus wel verwarrend.

En dus doet verhaal me een beetje denken aan de andere communicatie met 'leken' vanuit beheer. Bijvoorbeeld de melding dat een gebruiker een probleem zegt te hebben, de helpdesk het een incident noemt en de behandelaar een uitdaging. Drie verschillende termen voor dezelfde verstoring.

Als ik me dan bedenk dat de business (we blijven bezig) klaagt dat ICT niet goed communiceert dan kan ik me daar iets bij voorstellen;-)

Interessant stuk, genuanceerder dan verdeling in functional (requirements in dit artikel) en non functional (rest van eisen) requirements. Maar in de ICT literatuur beide requirements genoemd -> monopolie op termen lees ik bijv ..
Functional requirements zijn precies de interface tussen business en ICT. Maar zou de business dit artikel eigenlijk begrijpen ?
Die voorbeelden van ontwerp beslissingen zou ik overigens toch maar eens goed met de business overleggen. Lijkt me dat die zelf bepalen hoe bijv hun management informatie moet worden weergegeven met of zonder klok linksonder.

How Projects Really Work:
http://www.projectcartoon.com/cartoon/3

Toch maar Agile ? ;-)

Je kunt natuurlijk uren discussiëren of we het nu hebben over eisen, requirements (al dan niet functioneel), constraints en rules, maar uiteindelijk moet je er aan voldoen.

Ik mis in het artikel dan ook wat de toegevoegde waarde is van het opsplitsen in eisen en requirements.
Niets ten nadele van het artikel of auteur, maar op mij komt het over als wat ik pleeg te noemen "een stukje academische overhead"

PaVaKa, mogelijk heb je gelijk, maar het is toch een leuk verhaaltje om te lezen.

Arme Nicole :-) ICT collega's betwisten haar definities, Business begrijpt haar niet en het project is al zo duur. Alles moet ook ineens Agile, waar het opstellen van degelijke requirements eigenlijk op zich al ter discussie staat : snel een prototype maken en dan weet de product eigenaar (Agile context) pas beetje wattie echt wil en pas echt na een aantal iteraties (Agile context). Andere collega's vinden genuanceerde requirements opstellen ook voor complexe projecten met enorme kosten, eigenlijk maar academische overhead.

@Mauwerd ... om misverstanden te voorkomen: ik vind het opstellen van requirements geen overhead, zeker niet bij complexe projecten met enorme kosten.

Maar wat ik al schreef: ik mis informatie over .
de toegevoegde waarde van het categoriseren zoals aangegeven.

Een voorbeeld uit het artikel:
"Het systeem moet gebruik maken van een Oracle DBMS"

Nicole stelt dat dit een eis is, en geen requirement. Ik kan me zo voorstellen dat hier, als je niet uitkijkt, uren over gebakkeleid wordt door degene die dit ingebracht heeft en degene die requirements/eisen beheert. Het product moet hier uiteindelijk toch aan voldoen, dus wat voegt het dan toe om dit te identificeren als eis ipv een requirement?

Oorsprong en aard van eis is van belang. Maakt nogal wat uit of de de Oracle DMBS eis komt van de Business (Oracle altijd goed want groot en duur en andere partijen in zelfde branche werken er ook mee), ICT Architect (stabiliteit, uniformiteit, performance, schaalbaarheid), Project Manager (project risico's, software dependencies, vorige project ook met Oracle, vendor lock gevaar), Oracle DBMS beheerder (eigen belang), Programmeurs (meeste ervaring bijv toevallig met Oracle SQL).
Dat het product uiteindelijk aan een eis moet voldoen is een mening van iemand. Het staat gewoon ter discussie. In Agile en modern project management staan de requirements na elke iteratie altijd ter discussie. Dan is is het fijn te weten wie wat eist en waarom.

Aan verschillende stakeholders kan je volgende vragen stellen:

Business : ICT neemt verantwoording voor stabiliteit, betrouwbaarheid, continuiteit. Want kan net zo goed met ander pakket. Wil je nou echt Oracle of de eigenschappen die je er aan toekent ?
Architect : MS SQL is goedkoper en schijnt ook goed te werken en in het bedrijf is meer MS kennis dan Oracle op Unix, al eens overwogen ?
Project manager : breng dependencies in kaart met Architect, is het echt een eis ?
Oracle beheerder : jij zegt altijd dat het met Oracle moet maar nooit waarom. Waarom ?
Programmeur : Je krijgt extra tijd voor wennen aan ander DBMS interface dan die dure Oracle. Wil je nog steeds Oracle ?

Een interessant voorbeeld van hoe groot de kloof tussen IT en business geschapen wordt door van definities een academische exercitie te maken. In theorie mag het wel kloppen wat er gezegd wordt maar we weten allemaal wel dat er in de praktijk niet veel van terecht komt.

Het is wat dat betreft hetzelfde probleem door anglicismen te gebruiken waarbij het gros van de mensen de connotatie van het originele woord in de Engelstalige cultuur niet weet en dus er vaak foutief gebruikt wordt gemaakt in situaties waarbij het gekozen woord niet van toepassing kan zijn. Kortom onduidelijk taalgebruik gebruikt voor diverse redenen.

Dus wat project definities betreft kan je bijv. afspreken dat er alleen een taal gebruikt wordt. Hetzij Nederlands, Engels/Amerikaans, Esperanto of Klingon.
Spreek vervolgens dan ook af hoe deze definities omschreven dienen te worden en laat ze eventueel toetsen door een derde partij die het controleert.
Hoe meer ambiguïteit hoe meer het ten koste gaat van de kwaliteit, doorlooptijd of kostprijs.

Kwestie van opnemen in de scholing en aanbestedingen zodat het gemeengoed wordt en mensen het automatisch gebruiken omdat ze niet beter gewend zijn.

ps. Volgens mij wordt er een Oracle RDBMS bedoeld maar dat terzijde.

@Mauwerd: helemaal mee eens, maar als de discussie eenmaal gevoerd is, maakt het dan uit of het een eis of requirement heet?

Dat je vastlegt wat de oorsprong en aard van het beestje is, lijkt me niet meer dan logisch. Maar in mijn optiek is het lood om oud ijzer of je het nu een eis of requirement noemt.

@Pav

"maar als de discussie eenmaal gevoerd is, maakt het dan uit of het een eis of requirement heet?"

Nueuheeee ;-)


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 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!

@Wilco

Je stelt:
"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."

Ik denk niet dat het zo simpel is. Als ik als klant alles op platform X heb draaien, dan wil ik ook dat het nieuwe product op platform X draait. Als ik als klant .net expertise in huis heb, wil ik geen oplossing op java gebaseerd waardoor ik het product niet kan onderhouden indien nodig. Als ik al een databaseomgeving heb op Oracle, wil ik niet ook nog eens een DB2 erbij moeten aanschaffen enz enz enz

Als klant zijn dit wel degelijk requirements die ik aan de opdrachtgever mee wil kunnen geven. Aan de leverancier is vervolgens de uitdaging om binnen deze specificaties het product te maken.

@Pa Va Ke: Wie is in jouw voorbeeld de klant?
Normaal gesproken is de "business" de klant. Deze business bepaalt (doorgaans bij monde van gebruikers) niet alleen de gewenste functionaliteit, maar ook de criteria waaraan het functioneren van die functionaliteit zou moeten voldoen. Hoe ICT dit vervolgens oplost doet dan nauwelijks terzake (de motor-analogie) zolang je erop kunt vertrouwen dat je de juiste prijs/kwaliteit/functionaliteit geleverd krijgt. In veel gevallen is de business niet goed ingevoerd op dat punt en nauwelijks in staat e.e.a te beoordelen.

Dat is dus een aandachtspunt. Zeker daar waar het IT beheer volledig is uitbesteed, is het voor een klant nog nauwelijks te controleren is of hij niet een F1 motor krijgt waar een 2.0 turbo voldoende was geweest.
Dat pleit er dan weer voor de requirements en regierol te beleggen bij een onafhankelijke en terzake kundige dienstenleverancier.

@PaVeKe
Ik probeer in logische/functionele sferen te blijven. Zaken als Java, Oracle e.d. zijn onderdelen van oplossingen. Van het HOE een leverancier iets oplost. En ja, over dat hoe zei ik ook dat de klant daar over mee kan praten, en als hij als een Java of Oracle in huis heeft, kan hij daar dwingend in zijn, uiteraard. "Wellicht" is daar achteraf wat zwak uitgedrukt.

@Maarten
Als dat zo is heb ik me heel onduidelijk uitgedrukt. Als je designconstraint vertaalt namelijk....

@Wilco / @Hans

Het hangt heel erg van je omgeving af en wat je exact als opdracht uitzet. Is het iets nieuws dan is de HOE vraag minder relevant dan wanneer je iets wil laten maken dat in een reeds bestaande omgeving moet gaan draaien.

Ik heb meerdere voorbeelden gehoord van kennissen binnen de ICT die bij de klanten telkens een extra server erbij zetten met "hun" oplossing. Wanneer alle leveranciers dit voor iedere opdracht doen, heb je in no time een potpourri van servers in je bedrijf staan, wat een nachtmerrie is voor de beheersafdeling

Pe Ve Ka en Mauwerd
Natuurlijk maakt het, nadat de discussie gevoerd is en de requirements helder zijn, niet meer uit hoe je het noemt. Ik zou ook in een project zeker geen discussie over termen gaan voeren en de business er al helemaal niet mee vermoeien.
Wat ik wel probeer is om mijn vakgenoten, business- en informatieanalisten, te helpen om de automatiseringsbehoeften van de business te achterhalen. 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.

Als de klant aangeeft dat het systeem in java gebouwd moet worden of op platform X moet draaien, vraagt een goede business-/informatieanalist naar de achterliggende reden van die eis. Is dat vanwege kosten, aanwezige expertise, onderhoudbaarheid, goede ervaringen bij een ander systeem, etc. De eis ofwel technische beperking die de klant aan de leverancier meegeeft, kan vervolgens gefundeerd door een technisch architect van de klant vastgesteld worden. Hij kent de (on)mogelijkheden van de techniek en belanghebbende uit de business niet.

Als de technische beperkingen al eerder vastgesteld zijn – en onderdeel uitmaken van het IT-beleid – hoeft een analist die vragen niet iedere keer opnieuw te stellen. Het relevante deel van het IT-beleid wordt dan, naast de requirements, gecommuniceerd aan de leverancier. Het zijn namelijk 2 verschillende dingen en IT-beleid heeft voor de leverancier ook een andere lading en betekenis dan wanneer je het requirements noemt.)

PS aan hen die aanmerkingen hebben op het artikel van Nicole: wellicht helpt een concrete vraag in haar richting, die zie ik namelijk niet terug. De juiste vraag stellen is natuurlijk dagelijks werk voor hen die eisen en wensen helder willen krijgen.

Maarten
De term ‘requirements’ heeft binnen mijn vakgebied, requirements engineering, een specifieke betekenis. Deze staan niet in een als zodanig in een woordenboek. Binnen de IT gebruiken we overigens met z’n alle heel veel niet-Nederlandse woorden.

Ik heb ook behoefte om een plasje hierover te doen als ontwikkelaar.

Allereerst software ontwikkeling en automatisering in het algemeen is complexe materie die de laatste jaren complexer geworden is! Maar de wereld is sowieso complex, want de vraag "Wie is je klant?" is al een uiterst complexe vraag waar bijvoorbeeld de Rabobank al vele uren aan gespendeerd heeft! Ook gaat het gerucht dat zelfs Jeff Bezos, CEO van Amazon, niet precies weet hoeveel klanten hij heeft voor alleen al het gedeelte Cloud diensten (AWS).

Maar goed, requirements. Ik ben het erg met Maarten eens dat Nicole een artikel schrijft om requirements te verduidelijken maar in de vertalingen al mank gaat. Overigens hoeft Nicole van mij niet te reageren op artikelen, het is geen requirement, het maakt wel je boodschap sterker. Ook ben ik het niet met Wilco eens dat het "crystal clear" is. Wel vind ik het artikel aardig genoeg dat het aan het denken zet en weer wat inzichten deelt waar ik vervolgens niet al teveel waarde aan toe ken en ik zal uitleggen waarom,

Systeem ontwikkeling valt niet te vatten in requirements, businessrules, project en design constraints en ontwerpbeslissingen. Het is hooguit een onderdeel om houvast te geven in een wereld waarin de business zich niet in IT interesseert en omgekeerd. En juist dat houvast is in mijn ogen een vals gevoel van controle.

Ik zal in dit kader twee quotes geven: "All models are wrong, some are useful" en "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."

Alle modellen zijn fout, sommige zijn bruikbaar. Wat ik heel veel zie is dat managers gek zijn om stroomschema's en modellen omdat dit het gevoel geeft dat iets duidelijk is. De wereld is echter veel complexer om in simpele modellen te passen en zo zijn voelen requirements heel natuurlijk aan. Maar alle requirements, ontwerpbeslissingen, businessrules zijn modellen en slechts een onderdeel van het geheel.

Ik ben een voorstander van domein beschrijvingen aan de ene kant en scenario's over verhalen aan de andere kant. Wat is het probleem? Hoe los je dit op? Hoe zie je dit voor je? Hoe past dit binnen het domein? Wat is het ecosysteem? Als je dan een ontwerp hebt, realiseer dat in een simpel systeem en ontwikkel dat agile.

Het nadeel van (ellelange) beschrijvingen in de vorm van requirements is dat het goed lijkt, maar dat de ontwikkelaars er niets mee kunnen, de regie "koud" gevoerd wordt, dat het eventueel zelfs uitbesteed wordt naar bijvoorbeeld India, waardoor het resultaat uiteindelijk niet aansluit bij de verwachtingen. Systeem ontwikkeling is een synergie tussen de business en IT waarbij beide even belangrijk zijn. Requirements zijn goed, maar geen totaal oplossing en geen vertrekpunt voor ontwikkeling. Het vertellen van verhaaltjes, hoor en wederhoor zijn veel belangrijker in mijn ogen dan het opstellen van opsommingen, dit is hooguit een referentie stuk wat erbij gehaald kan worden om te zien of de ontwikkelingen nog in lijn liggen met de opgestelde regeltjes. Deze regels kunnen best hard zijn, maar deze worden automatisch al gevolgt omdat het domein en het doel al duidelijk zijn. Ze worden onthouden door het hart omdat iedereen echt SNAPT wat de bedoeling is.

Je kunt alle requirements perfect volgen en uitvoeren en nog steeds een ruk systeem opleveren. De crux van succesvolle systeem ontwikkelingen zit niet in de beschreven zaken, maar in de minder beschreven zaken. En gebruik simpele principes die werken, die werken namelijk nog steeds als een systeem groot en complex wordt. En een complex systeem zou je niet vanuit de theorie moeten ontwikkelen, dat moet groeien door middel van evolutie.

Dit artikel is dus een logische invulling van wat zaken die logisch lijken, maar zijn in mijn ogen slechts een onderdeel van ondergeschikt belang. Hier te diep op in gaan zorgt voor het missen van de essentie.

Geef mij voorbeelden aan waarbij de goede "requirements" de crux van een succesvol project bleken te zijn, en denk dat je er niet veel zult vinden.

Nog een nabrandertje mbt het stuk van Wilco.

Door een auto als voorbeeld te nemen raak je precies de essentie voor wat ik bedoel. Je beschrijft allemaal requirements die er voor een systeem niet toe doen.

Je wilt geen auto, je wilt jezelf of iets verplaatsen. Daarin heb je bepaalde behoeften die bepalen welk vervoermiddel het beste is (of uitbesteden, je hebt helemaal geen auto nodig).

Als je auto verkoper bent en de klant wil een auto dan schotel je hem een menukaart voor. Wil hij een ander merk die jij niet levert, dan is het niet jouw klant, tenzij je aan kan geven dat jouw auto de beste keus is. Dat diesel beter is dan benzine is niet aan jou, hooguit kun je de klant de vraag stellen hoeveel kilometer hij per jaar verwacht te rijden en kun je adviseren.

Maar proberen de juiste auto te leveren vanuit de specificatie is dus een verkeerd (maar wel logisch) vertrekpunt.

Ook kun je een checklist maken welke je afvinkt als je de klant interviewt. Als de klant een auto wil dan is de logische vraag, schakel of automaat. Ik vind de analogie met een auto niet sterk. Het is immers een kant en klaar product waarin je slechts wat keuzes hebt en als je een Mercedes dealer bent zult je Mercedes auto's willen verkopen.

Dus nogmaals, regeltjes opstellen om tot een specificatie te komen is niet het pad wat je zou moeten bewandelen. Snappen wat de behoefte is volgt een heel ander traject.

Zie het als een dating site, Hoe specificeer je de perfecte vrouw voor jou? Je kunt er een mooie parabel over schrijven. Man wil een mooie vrouw, die krijgt hij, maar het is een heks die niet met je moeder over weg kan. Je wilt een mooie vrouw die lief is en goed met je moeder overweg kan. Je krijgt zo'n vrouw, maar ze kan niet koken en heeft een hekel aan kinderen en huishouden, en fin, je begrijpt waar ik naar toe wil...

@Henry,
ik heb in mijn eerste en tweede reactie gezegd dat de klant wel enigszins (of meer) invloed heeft op zijn oplossing. De klant wil zich verplaatsen, niet met een vliegtuig, niet met een trein maar hij is gek op auto's. Als de klant gek is op auto's gaan we die verder uitdenken. Een ander vervoermiddel krijg je hem niet aangesmeerd. Overigens, een auto is geen kant en klaar product. Als jij een nieuwe auto koopt en jij gaat kruisjes zetten bij de accesoires, dan staat deze auto zelden meteen klaar. De fabricage wordt ingepland ergens in de wereld en over drie maanden staat jouw auto klaar om af te halen. Dat kan ik allemaal in mijn allereerste en al niet korte reactie benoemen, maar laten we dan een keer afspreken om hier over te discussieren. De strekking moet duidelijk zijn. Je moet ergens beginnen. Ik ben overigens een improviserende en inventieve interviewer die dingen te horen krijgt die veel van mijn voorgangers bij eenzelfde klant niet te horen hebben gekregen. Op het gebied van interviewen voor mij een paar aandachtspuntjes maar geen checklist.

Een heel opvallende opmerking die je maakt is "Requirements zijn goed, maar geen totaal oplossing en geen vertrekpunt voor ontwikkeling. Het vertellen van verhaaltjes, hoor en wederhoor zijn veel belangrijker in mijn ogen dan het opstellen van opsommingen". Interviewen (en meer elicitatiemethoden) zijn voor mij middelen om requirements uitputtend helder te krijgen. Hoor en wederhoor zit daarin besloten. Door een goede opbouw van de requirements naar deelgebieden met daarom heen toelichtende tekst komt een helder verhaal naar boven, waarvan je de juistheid, goed begrip en dergelijke uiteraard goed moet verifiëren bij de stakeholder waar je je informatie hebt opgehaald. Werk je agile, dan worden veel requirements wellicht alleen uitgesproken maar het zijn en blijven requirements.

Business analyse, informatie analyse, requirements engineering en diverse overige activiteiten in in de buurt van business en systeemontwikkeling zijn niet aard- en nagelvast of eenduidig te omschrijven. Dat doet de één zus en de ander zo, het "enige" wat wij nodig hebben, is hetzelfde referentiekader. Wanneer is iets voor jou een requirement, en voor jou? Wat heb jij nodig om aan de feitelijke systeemontwikkeling te beginnen, en jij?

Zoals gezegd, het lijkt me erg leuk om eens onder vier ogen af te spreken, met eenieder hierboven voor zover ze niet onder een nickname reageren. Ik sta op linkedin, ik zie jullie reacties wel tegemoet. That is it, zover het het beeldschermdeel van deze discussie betreft.





@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".

Expert
Nicole de Swart

Nicole de Swart
Requirements expert, Reaco Academy. Expert van voor het topic .
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×