De informatiebron voor het Nederlandse ICT-resellerkanaal   Adverteren | Mobiel | Contact  
Channelweb
 Zoek
Nieuwsbrief
Reacties
Bedrijvengids
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   
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet het redactionele gedachtegoed van Channelweb.

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:
27 januari 9:27
BIT moet niet controleren, maar excelleren
26 januari 15:19
Nog eenvoudiger je data opslaan en terughalen
26 januari 10:24
ACI en de transformatie van het datacenter
23 januari 14:35
Jagers en verzamelaars in ICT-land
23 januari 11:47
Telefooncentrales geliefd doelwit van hackers
22 januari 14:33
Het echte zakelijke voordeel van Flash komt nog
22 januari 9:01
2015: De zorgcloud komt er aan
21 januari 11:38
Moderniseer nu zakelijke applicaties
20 januari 15:19
2015: Onmiddellijk en permanent beschikbaar
20 januari 11:06
Cloudtechniek is zegen voor IT-afdeling
16 januari 9:13
Extra opties bij stoppen Windows Server 2003/R2

  


Adverteren  |   Disclaimer  |   Privacy  |   Cookiebeleid  |   Algemene Voorwaarden  |   IT Banen  |   Computable  |   Channelweb  |   IT Knowledge Base  |   Marqit.nl



Alle rechten voorbehouden © Marqit