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,
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 😉