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