2 November 2006

De trend is dat design- en ontwikkelprojecten almaar ingewikkelder worden. Het werken in gedistribueerde teams of met uitbesteding vergroot ook nog eens de afstand tussen opdrachtgevers en uitvoerders. Requirementsengineering en -management bieden processen en technieken om eisen te formuleren en deze te volgen en te beheren. Maar, zo benadrukken Harry Julsing en Pete Davies van Mithun Training & Consulting, het gaat veel meer om de mensen dan om de processen.

Een requirement is een eis. Requirementsmanagement is het beheer van eisen en requirementsengineering het formuleren van deze eisen. In een ontwerp- en ontwikkelproces zijn de requirements de eisen waaraan een product moet voldoen. Het requirementsmanagement moet waarborgen dat alle processtappen daadwerkelijk in dienst staan van een geformuleerde requirement. Requirementsengineering moet ervoor zorgen dat de requirements het gedachte product ook daadwerkelijk, eenduidig, compleet, correct en consistent beschrijven.

Het doel van requirementsmanagement en -engineering is dat er precies wordt ontworpen en ontwikkeld wat de bedoeling is, niet meer en niet minder. Ontwikkelaars zijn heel snel geneigd om direct te denken en te praten in mogelijke technische oplossingen in plaats van zich eerst te concentreren op het wat en waarom. Hoe de ontwikkelaars het probleem denken op te lossen is een tweede en staat los van de productrequirements.

Iedereen weet dat hoe later een ontwerpfout wordt ontdekt, hoe moeilijker en duurder het wordt om die fout te herstellen. Softwareprojecten hebben veelal een vergelijkbare complexiteit maar toch wordt het belang van requirementsmanagement en -engineering onderschat bij de ontwikkeling van softwaresystemen. Volgens docent Pete Davies en directeur Harry Julsing van Mithun Training & Consulting is het gedrag van de ontwikkelaars echter belangrijker dan de technieken en tools. De basiskennis is meestal wel aanwezig, het begrip van het belang van goede requirements niet.

Uit een studie bij de Amerikaanse ruimtevaartorganisatie Nasa blijkt dat het het effectiefst is om 10 tot 15 procent van de projectkosten te reserveren voor de requirements. Dan is de budgetoverschrijding het kleinst.

Requirementstechnieken zijn afkomstig uit de lucht- en ruimtevaart en uit de defensie-industrie. Het gaat daar om grote en langdurige projecten, gecompliceerde producten en dikwijls meerdere contractanten. Requirementsmanagement en -engineering zijn dan ook niet iets van de laatste paar jaar. ’Het had niet die naam, maar requirementsengineering hoorde bij de analysefase van gestructureerde analyse en design‘, vertelt Davies. ’Het ging erom wat de applicatie moest presteren en niet hoe dat vervolgens moest worden geïmplementeerd. In de geschiedenis van de software-industrie is het accent meer en meer verschoven van de techniek naar het gebruik. In de begintijd ging het vooral om het programmeren zelf, maar tegenwoordig is de rol van de eindgebruiker veel belangrijker. Het zijn uiteindelijk de belanghebbenden, de ’stakeholders‘, die bepalen in welke mate een applicatie voldoet en niet de ontwikkelaars.‘

Julsing vult aan: ’Een van onze klanten produceert klimaatsystemen en door requirementstechnieken toe te passen gingen ontwikkelaars beter communiceren met de klanten en klantvertegenwoordigers zoals productmanagement. Je zag dat onze training echt een gedragsverandering tot stand bracht.‘

Davies: ’Ontwikkelaars zijn van nature gericht op de techniek. Zij zijn er vooral in geïnteresseerd hoe je iets oplost. Dat is echter niet het belangrijkste. Het gaat om het ’wat‘. Uit de geschiedenis is gebleken dat het wat helemaal geen triviale zaak is. Technieken van de laatste tien tot vijftien jaar zoals DSDM (Dynamic Systems Development Method) en Agile Development zijn ook duidelijk pogingen om de gebruikers en belanghebbenden beter bij het ontwikkelproces te betrekken.‘

Behoeften

Requirementstechnieken verhogen de kwaliteit van het ontwikkelproces. ’Je kunt de verzameling requirements ook zien als een contract tussen een opdrachtgever en een ontwikkelteam‘, legt Davies uit. ’Requirements leggen vast wat er gemaakt gaat worden en dat wordt tijdens de ontwikkeling voortdurend gecontroleerd. Met name voor missiekritische applicaties is dat essentieel. In sommige gevallen moet je zelfs via een audit aan regelgevende instanties bewijzen dat je product aan de eisen voldoet. Als je medische toepassingen produceert voor de Amerikaanse markt, moet je ontwikkelproces voldoen aan regels van de Food and Drug Administration. Anders laten ze je product eenvoudigweg niet toe.‘

De requirements vormen ook een uitdrukking van de behoeften van de gebruiker. Davies: ’In veel hightechbedrijven hebben de ontwikkelaars te weinig oog voor die eindgebruiker. Je ziet dat vooral bij de niet-functionele requirements zoals usability. Vaak kan ook de communicatie tussen ontwikkelaars en productmanagement en marketing veel beter. Juist bij het opstellen van de requirements is die communicatie belangrijk. In dat stadium is het nog gemakkelijk om fouten te voorkomen. Herstellen in latere fasen van de ontwikkeling wordt al maar moeilijker en duurder.‘

Boerenverstand

Het opstellen van de requirements is allerminst een eenvoudige vingeroefening. Om dat te illustreren begint Davies zijn cursussen meestal met een voorbeeld dat niets met software te maken. ’Ik vraag de cursisten om de requirements voor hun leaseauto te formuleren‘, vertelt hij. ’Je krijgt dan antwoorden zoals een twee liter auto, een groene auto en een veilige auto. Ik vraag dan of de bestuurder wel past in die twee liter, of de ruiten ook groen moeten zijn en of ik de motor en de wielen mag verwijderen om de veiligheid te verhogen. Dat klinkt misschien nogal vergezocht, maar dat komt omdat je van een aantal aannamen uitgaat die voor jou vanzelfsprekend zijn, maar dat is niet voor iedereen zo.‘

Daar ligt volgens Davies een enorme bron van misverstanden en ontwerpfouten. ’Zodra je met grotere en heterogene ontwikkelteams gaat werken, die bovendien niet vertrouwd zijn met de omgeving waarin de applicatie moet functioneren, moet je heel voorzichtig te werk gaan. Zelfs als het concept leaseauto voor iedereen duidelijk is, dan nog zijn de genoemde requirements te vaag. Een eis als een twee liter cilinderinhoud is zelfs helemaal geen requirement. Waarom twee liter? Is een 1500 cc motor met dezelfde prestaties minder goed? De echte requirements zijn de prestaties van de auto en daarvoor heb je een bepaald vermogen nodig. Dat is dus een requirement, maar niet hoe de ontwerpers dat realiseren.‘

Door een oplossing te specificeren blokkeer je andere mogelijke oplossingen. Davies: ’Je ziet het bij de milieuwetgeving van Californië waarin voorwaarden zijn gesteld aan katalytische uitlaatsystemen. Andere oplossingen om uitstoot te verminderen zijn hierdoor bij voorbaat onmogelijk gemaakt.‘

Reden voor fouten in softwareprojecten

Veiligheid is wel een requirement maar daarbij stuit je op een tegenstrijdigheidprobleem. Een absoluut veilige auto is geen auto meer, dus hoe gaat het compromis eruit zien dat je in de praktijk moet sluiten? Een klassiek voorbeeld uit de software is de tegenstelling tussen beveiliging en gebruiksgemak. Davies: ’In veel bedrijven eisen de systeembeheerders dat gebruikers elke drie maanden hun wachtwoord veranderen. Het probleem is dat niemand die veranderingen kan bijhouden en mensen dus hun wachtwoord gaan opschrijven. Je maakt iets veiliger op het ene punt, maar vergroot je risico weer ergens anders. Je moet dus prioriteiten stellen.‘

Of denk aan een bedrijf dat zijn legacy-systemen geschikt maakt voor internet. Vooral interactie met de gebruiker krijgt hier veel aandacht. Requirements voor het berekenen van btw zijn helder en eenvoudig en daarom makkelijker te formuleren dan de requirements voor een internettransactiesysteem. Dat is veel complexer en daarom is het moeilijker te testen of het systeem voldoet aan alle eisen.

Tien jaar geleden moesten echter alle boekhoudsystemen in Engeland worden aangepast, omdat de btw ineens in halve procenten moest worden berekend. ’Als daarmee in de requirements rekening was gehouden, had het helemaal niets of relatief weinig gekost‘, stelt Julsing. ’Voor een fabrikant die een product op de markt brengt, gaat het in zulke gevallen niet alleen om de directe kosten maar vooral om de indirecte. Denk aan verlies aan omzet, verlies marktaandeel aan de concurrentie door vertraagde marktintroductie en schade aan reputatie.‘

Requirementsengineering en -management zijn geen exacte wetenschappen. Davies: ’Het gaat erom hoe het communicatiegat te dichten tussen eindgebruikers en ontwikkelaars, vooral als de verschillen groot zijn door zaken zoals taal, cultuur en afstand zoals bij offshoring. Dan is het zaak om de communicatie zo helder en eenvoudig mogelijk te houden. Het gaat uiteindelijk om het elementair gebruik van ons gezonde boerenverstand.‘

Pete Davies geeft cursussen over requirementsengineering en -management voor Mithun Training & Consulting (info@mithun.nl). Harry Julsing is directeur van deze Amersfoortse trainingsorganisatie.