Na het lezen van het artikel ‘Verbetering begint met requirements’ in de Computable van 23 september, viel mij een aantal zaken op waar ik graag op wil reageren.
Allereerst wil ik opmerken dat de heer Vellekoop een kwestie aansnijdt die mijns inziens zeer onderbelicht is. Het is ook mijn ervaring dat requirements in het algemeen flinke verbeteringen kunnen gebruiken. De punten die in het artikel worden aangestipt kunnen daar een bijdrage aan leveren. Vooral de gedachte rond de verschillende ‘niveaus’ is wezenlijk. De relevantie van die niveaus wordt echter niet duidelijk. Daarnaast wordt voor drie niveaus een definitie gegeven die tegelijkertijd neigt naar een soort criterium dat gebruikt kan worden om te bepalen of een eis op een bepaald niveau thuishoort. Hoewel impliciet genoemd, mist er een duidelijk kader waarbinnen requirements gebruikt worden.
Voor de eenvoud beperk ik mij tot de meest generieke zaken. Requirements zijn allereerst een min of meer formeel communicatiemiddel tussen opdrachtgever en opdrachtnemer. Daarbij hebben requirements een tweeledig gebruik: ze vormen de basis voor de ontwikkeling van een systeem en de acceptatie van dat systeem. Dit alles heeft tot doel om op een bewuste, inzichtelijke wijze tot een betere kwaliteit te komen. Een belangrijke randvoorwaarde is dat de requirements voor alle doelgroepen volstrekt helder zijn. Omdat er meestal op het grensvlak van business en ict wordt geopereerd, is het duidelijk dat dit een uitdaging op zich is.
In het bewuste artikel wordt ook een omschrijving gegeven van drie niveaus. Het ontgaat mij wat het doel van deze niveaus is en wat de betekenis van een requirement op ieder niveau is. Vanuit het kader van systeemontwikkeling pleit ik dan ook voor een ander concept. Ieder niveau beschrijft een bepaald systeem in meer of minder detail. Een chip wordt op het hoogste niveau beschreven met wiskundige functies, op een middelmatig niveau middels transistoren en op een laag niveau middels plakken silicium. Zo kan een afdeling worden beschreven middels een procesbeschrijving of op een ander niveau middels mensen, procedures, machines en applicaties. Cruciaal is dat ieder niveau hetzelfde systeem beschrijft. Het detailniveau en de terminologie verandert, maar het onderwerp niet. Ieder niveau beschrijft hetzelfde systeem. Het is voor een opdrachtgever voldoende om een systeem op één niveau te beschrijven. Beschrijvingen waarin niveaus door elkaar heen worden gebruikt zijn meestal ambigu, en daarmee een basis voor onheil.
Hoe kun je er voor zorgen dat een verzameling requirements een systeem begrijpelijk en op het juiste niveau beschrijft? Het gaat te ver om dit in zijn volledigheid te beschrijven. Het is niet mogelijk om met enkele simpele regels goede requirements op te stellen. Toch licht ik een tipje van de sluier op, daarbij aanmerkend dat geen van deze tips absolute waarheden zijn.
1. Beschouw een te ontwikkelen systeem/product als een black-box. Doe alleen uitspraken over het gedrag aan de buitenkant van het systeem.
2. Stel een contextdiagram op.
3. Laat elke requirement beginnen met ‘Het systeem dient…’. Zo kun je de black-boxbenadering afdwingen.
4. Wees eenduidig in het gebruik van termen. Houd een begrippenlijst bij ‘voor dit niveau’. Stem deze lijst af met de doelgroepen.
5. Gebruik alleen termen die in hetzelfde semantische kader vallen (en dus op hetzelfde niveau). Als er bij de beschrijving van een financieel systeem de term ‘database’ opduikt is dat reden tot argwaan, omdat deze term op een ander beschrijvingsniveau thuishoort.
6. Gebruik alleen deze gedefinieerde termen voor requirements.
Er is voldoende literatuur over requirements te vinden. De beschreven concepten komen daar meestal wel in voor. Toch blijkt het merendeel van de specificaties er helaas aan voorbij te gaan. Met deze eenvoudige hulpmiddelen kan de bruikbaarheid van requirements behoorlijk worden opgekrikt. Er liggen dan ook nog voldoende mogelijkheden om het rendement van de ict te verhogen.
Ignas van Megen, senior system engineer
