Aan eisen moet je eisen stellen

Aan vrijwel alle producten en diensten worden
eisen gesteld.  Een willekeurig voorbeeld: de EN
1836 is een Europese norm die is opgesteld voor
zonnebrillen.  Als het welbekende CE teken op een
zonnebril prijkt, dan is er sprake van protectie
tegen de zon.  Dat mag wat lacherig klinken maar
dat is het niet: gradient filters tijdens het
autorijden, eclips filters voor directe observatie
van de zon, wanneer mag het antireflectie heten,
wat is de toegestane afgifte van metalen als
nikkel bij stalen monturen, etc.

We kennen nog veel meer voorbeelden waar aan van
alles en nog wat eisen worden gesteld om een
bepaald kwaliteitsniveau te halen, of bepaalde
prestaties van een dienst of product af te
dwingen.  Die kant moeten we ook op in het veld
van de IT.  Het goede nieuws is dat er bakken met
standaards en richtlijnen zijn, ook voor
maatwerkapplicaties.  Het slechte nieuws is dat
hele volksstammen dit niet blijken te weten.

Elk IT-intensief systeem begint met eisen en
wensen.  Sommige probleem eigenaren zijn
behoorlijk ervaren en kunnen redelijk goed eisen
formuleren.  Anderen zijn weer minder bedreven in
het opstellen van de eigen wensen.  Idem dito
geldt dat voor de IT-dienstverleners.  Alhoewel ze
ongetwijfeld verstand van IT hebben, wil dat nog
niet zeggen dat ze daarmee ook het applicatie
domein doorgronden.

De IEEE Computer Society, een zeer omvangrijke
internationale beroepsorganisatie van ons veld,
biedt hier uitkomst met de zogheten IEEE
Recommended Practice for Software Requirements
Specifications.  Het gaat om de IEEE 830 waar
sinds de eerste uitgifte in 1984 verschillende
updates van zijn verschenen.  In de IEEE 830
worden eisen aan eisen gesteld.  Niet alleen aan
de inhoud ervan maar ook de kwaliteit ervan.  De
standaard is gericht op het specificeren van
software eisen voor te ontwikkelen systemen maar
kan ook worden toegepast bij het selecteren van
kant-en-klaar producten op de markt.

Iedereen mag en kan zich bemoeien met het
opstellen van dit soort normen.  Dit gaat op
vrijwillige basis en met gesloten beurs.  Als je
wat aan te merken hebt op een reeds vastgestelde
standaard is het ook niet te laat: je kunt
bezwaren en aanvullingen kenbaar maken en daar
wordt iets mee gedaan.  We spreken dus niet over
ivoren toren standaards maar richtlijnen voor en
door professionals.  Dus geen ellenlange
discussies over wat nu precies voor een banaan
"free from malformation or abnormal curvature"
betekent.  Dit ging om de EU richtlijn EC 2257/94
waar eisen voor meererlei uitleg vatbaar bleken.

Ook in de IT-wereld zie je vaker dan eens eisen
die ambigu zijn, en waar van alles mee mis is.
Dat is op zich niet zo erg, als het maar opgelost
wordt voordat overgegaan wordt tot ontwerp en
bouw.  Daar biedt de IEEE 830 uitkomst, en het
zou voor bananenrichtlijnen ook wel eens uitkomst
kunnen bieden.  Een vrij simpele eis die aan het
opstellen van eisen wordt gesteld is dat het een
gezamenlijk proces moet zijn.  In de woorden van
de standaard: ``Customers usually do not
understand the software design and development
process well enough to write a usable SRS.'' en
omgekeerd: "Suppliers usually do not understand
the customer's problem and field of endeavor well
enough to specify requirements for a satisfactory
system."

Iets anders dat ultra belangrijk is, is dat een
eis van voldoende kwaliteit moet zijn.  Concreet
betekent dit de volgende zaken: correct, niet
ambigu, compleet, consistent, gerangschikt naar
belangrijkheid en/of stabiliteit, verifieerbaar,
aanpasbaar en traceerbaar.  Populair gezegd eisen
moeten SMART zijn.  Dit is van zeer groot belang
omdat de software requirements speficicatie de
basis is voor het voorlopig ontwerp, het
definitief ontwerp,  het uitvoerings ontwerp, de
constructie, project monitoring, verificatie en
validatie, en bij opleiding, training en oefening.
Het is daarmee van levensbelang dat die eisen zelf
aan eisen voldoen.  Omdat de eisen voor allerlei
doelgroepen van belang zijn, kan de vorm waarin je
ze representeert er niet een zijn waar ambiguiteit
is weggenomen bijvoorbeeld door eisen in pseudo
code op te stellen.  Dat zou voor de ontwikkelaar
wel helpen maar dat werkt voor de normale
gebruiker juist weer contraproductief.

Net als met de bananenrichtlijn zijn we heel snel
geneigd aan te nemen dat een ander wel zal snappen
wat je met "abnormal curvature" bedoeld.  Maar die
eis is niet verifieerbaar.  Een voorbeeld van wat
wel verifieerbaar is, is "cucumbers are allowed a
bend of 10mm per 10cm of length".  Een eis als "de
interface moet gebruikersvriendelijk zijn", is
tevens niet verifieerbaar omdat we niet weten wat
gebruikersvriendelijk precies betekent.  Dus daar
moet je de mouwen opstropen om precies uit te
leggen wat daaronder verstaan wordt.

Daarom is het een aanrader om bij het in de markt
zetten van IT-intensieve systemen te eisen dat na
gunning het eisen en wensenpakket moet worden
vastgesteld volgens de IEEE 830.  Net als bij een
zonnebril weet je dan dat er dan sprake zal zijn
van voldoende kwaliteit van het eisen en
wensenpakket en dat daarmee niet alleen alle
doelgroepen bereikt worden gedurende de
totstandkoming en de operationele fase maar ook
dat risico's danig beperkt worden doordat de eisen
zelf van goede kwaliteit zijn.

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in AG II.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.