De informatiebron voor het Nederlandse ICT-resellerkanaal   Adverteren | Mobiel | Contact  
CRN
 Zoek
Nieuwsbrief
Reacties
Bedrijvengids
CRN Mobiel



Nieuws aanmelden
Heb je nieuws voor ICT-resellers? Gebruik het aanmeldformulier.
Agendapunt melden
RSS-feed Volg ons via Twitter

 
Opinie
 Terug Mail aan een vakgenootPrintvriendelijke versie   

Over oneisen en nonwensen

Lijstjes met eisen en wensen zijn vaak als Paris Hilton: fraai, nietszeggend en je hebt er weinig aan. Het klinkt natuurlijk goed, in kaart brengen wat de gebruiker nu echt wil van het systeem, maar in de praktijk is het vaak een ritueel dansje. Het hoort erbij, we doen het even, maar niemand weet nog waar het echt voor dient.

Paris Hilton

Lijstjes met eisen en wensen kunnen een nuttige bijdrage leveren aan de automatisering, maar alleen wanneer deze eisen en wensen niet uit louter platitudes voor de vorm bestaan. En veel te vaak doen ze dat helaas wel. Neem nu een voorbeeld dat ik recent zag (ik zal geen namen noemen). De lijst met eisen en wensen begon met flexibel, schaalbaar en nog enkele van dit soort doodoeners.

Zo'n lijstje kun je net zo goed niet maken. Wat is het probleem? Het probleem is dat deze eigenschappen niets zeggen over het te bouwen systeem. Wat, zul je misschien vragen? Er staat toch dat het systeem flexibel en schaalbaar moet zijn? Ja, dat staat er wel, maar dat zegt niets over het te bouwen systeem omdat dat wenselijke eigenschappen zijn voor íéder te bouwen systeem. Eisen die een eigenschap van het te bouwen systeem aangeven, zijn alleen zinvol wanneer de negatie van die eigenschap ook zinvol kan zijn als eigenschap. En niemand wil een rigide systeem. Dus: opschrijven dat het te bouwen systeem flexibel moet zijn, is een open deur intrappen. Het voegt niets toe. We weten niet meer dan voorheen.

Rugdekking verschaffen

Waarom schrijven mensen dan dergelijke lijstjes met eisen en wensen, en is het maken van zo'n lijst het uitgangspunt van ieder ict-traject? Dat doen mensen om zichzelf in te dekken. Helaas is een groot deel van alles wat er in eisen-en-wensenland gebeurt niets meer of minder dan rugdekking verschaffen. Er mislukken nu eenmaal veel ict-projecten: bij de overheid, maar ook elders, al houden commerciële bedrijven de stront wat liever onder de klep, en loopt de beerput met mislukte ict-projecten daardoor wat minder in het oog. Dus hoe voorkomt je dat een mislukt project je aangewreven wordt? Uiteraard door van álles, maar dan ook van álles wat maar mis kan gaan van tevoren vast te leggen dat het er wel in had moeten zitten. Is het project mislukt omdat het systeem te rigide is? Niet mijn schuld: ik had opgeschreven dat het juist wel flexibel moest zijn.

Hoe moet het dan wel? Eisen moeten concreet zijn. Verifieerbaar en liefst meetbaar. Eisen moeten verifieerbaar zijn wanneer het ja/nee-eisen betreft: het systeem heeft het wel of het systeem heeft het niet. Draait op iOS: dat is verifieerbaar. Alle documenten op te slaan als pdf: verifieerbaar. Een roze rand met bloemetjes om het systeem. Ook verifieerbaar. Wanneer het geen ja/nee-eisen betreft moeten ze meetbaar zijn. 10 petabyte aan ruwe data op kunnen slaan. In twee uur onder de knie te krijgen door een eindgebruiker die er niet eerder mee gewerkt heeft. 99,9 procent uptime. Dat is meetbaar.

Welles, nietes

Maar hoe verifieer of meet je of een systeem flexibel is? ‘Ik vind het best flexibel.' ‘Nou, ik niet.' U voelt het lijk al drijven. Niet-verifieerbare en niet-meetbare eisen en wensen leiden alleen maar tot een eindeloos welles-nietes spelletje.

‘Altijd wenselijke' eisen hebben alleen zin wanneer ze voorkomen in een gewogen lijstje.
Dus: 1) Flexibel, 2) ... 10) Schaalbaar. Dit zegt wel iets. Namelijk dat het systeem vooral flexibel moet zijn, en dat dit eventueel ten koste mag gaan van de schaalbaarheid. Alleen zo kun je met dergelijke ‘altijd wenselijke' eigenschappen iets zinnigs uitdrukken. Het doet denken aan het aloude voorbeeld, ‘Fast. Good. Cheap. Pick two'. Je kunt snel een goed systeem maken, maar dat kost geld. Je kunt goedkoop en snel iets maken, maar het zal nog rammelen. Je kunt het goedkoop en goed, maar dat duurt even. ‘Altijd wenselijke' eigenschappen zijn alleen zinvol wanneer het geen eisen zijn, maar items in een prioriteitenlijst: wat heeft voorrang wanneer er keuzes gemaakt moeten worden? Software ontwikkelen zit vol met trade-offs, en nadenken over wat echt belangrijk is en wat niet, is goed. Maar prioriteitenlijstjes zijn geen eisen: het werkt alleen wanneer er ook echt zaken op staan die een lage prioriteit hebben.

De eerste eis die aan alle lijstjes met eisen en wensen gesteld moet worden: als het tegendeel nooit wenselijk is, hoort deze eis of wens niet thuis op een lijstje met eisen en wensen. Bestel u dus alleen nog een systeem dat ‘robuust' of ‘gebruikersvriendelijk' moet zijn wanneer u ook regelmatig eist dat een systeem ‘gammel' of ‘gebruikersvijandig' is.

Marc de Graauw, freelance consultant

 


Marc de Graauw 
 
 
 
 Reageer op dit artikel 
 
Meer Opinie:
22 april 12:55
Genoeg redenen om cybercrime in te perken
22 april 11:53
Wat is Heartbleed en hoe bescherm je jezelf?
18 april 12:58
Nederlandse overheid smoort innovaties
18 april 11:42
Kabinet moet ICT als topsector waarderen
17 april 13:54
Mobiele kennis en kunde borgen in een MCC
17 april 11:00
Open brief aan alle cloudleveranciers
15 april 10:33
Zoekend Microsoft verbreedt horizon
14 april 9:54
Onderbouw beslissingen wat minder
11 april 13:58
Wat ben ik?
11 april 10:20
Storage-ontwikkelingen gaan hard
10 april 13:13
Half miljard redenen om cybercrime in te perken

  


Adverteren  |   Disclaimer  |   Privacy  |   Cookiebeleid  |   IT Banen  |   Computable  |   CRN  |   Tweakers.net  |   IT Knowledge Base  |   Autotrack.nl  |   Carsom.nl

Alle rechten voorbehouden © De Persgroep