Herkent u dit?Bij een gemeentelijke instelling is de herinrichting van een straat door de betreffende ambtenaar voortvarend ter hand genomen. Er zijn meer parkeerplaatsen in de straat nodig en dus is met dat doel een nieuwe straat-indeling ontworpen.Een bestratingsbedrijf krijgt opdracht om de nieuwe straatindeling te realiseren. De werkzaamheden be-ginnen. Om bewoners en winkeliers tegemoet te komen in de overlast die de werkzaamheden met zich meebrengen, wordt de straat alvast openge-steld voordat de werkzaamheden zijn afgerond. De nieuwe lantaarnpalen zijn nog niet geplaatst, en de oude konden nog niet worden weggehaald, omdat de straat anders onverlicht zou zijn. Met als resul-taat een situatie zoals weergegeven in figuur 1.De doelstelling ‘meer parkeerplaatsen’ is natuurlijk dui-delijk. De eisen aan ‘goede straat verlichting’ zijn echter vergeten. Hierdoor is onvoldoende aandacht besteed aan het eindproduct, waardoor de eisen ten aanzien van de volgorde waarin de taken werden uitgevoerd niet goed zijn geïnventariseerd. De straat is precies volgens plan aangepast en toch voldoet het eindresultaat (nog) niet. Uiteraard is het probleem op te lossen, maar daarvoor wordt dan wel een extra inspanning verricht, waarbij de juist aangelegde parkeerplaats opnieuw wordt openge-broken.

Figuur 1: Meer parkeerplaatsen?

We hebben Requirements nodig om projecten te doen slagen. Projecten slagen door een goed product dat vol-doet aan de (business) doelstellingen: op tijd en tegen gebudgetteerde kosten op te leveren. Dan moet require-ments engineering, het proces om tot requirements te ko-men, echter wel op de juiste manier worden uitgevoerd.

De Big HittersWe hebben gezien dat we voor veranderingen die we wensen te realiseren projecten nodig hebben. En die

Requirements Engineering

28 XR Magazine oktober 2011

Requirements zijn de Big Hitter…

Jan Willem Knop

…voor succesvolle projecten!

We willen maximaal rendement uit onze IT-investeringen. De realiteit is dat de meeste IT-projecten

mislukken. En dat is al vrij lang zo in de IT-wereld. Je kunt je daarom afvragen of IT-projecten wel suc-

cesvol kunnen zijn. In dit artikel beschrijven we hoe een goed ingericht requirements proces de Key

Success Factor is voor geslaagde IT-projecten. We laten dat zien aan de hand van een “Big Hitter” voor

succesvolle projecten en hoe requirements daarin een rol spelen.

Reageren op dit artikel? Klik hier.

Bedreigingen voor succesvolle toepassing van requirementsRequirements zijn dus cruciaal voor het succes van pro-jecten. Echter, de meeste projecten mislukken. Besteden we dan te weinig aandacht aan de Big Hitters?Met experts hebben we een workshop gehouden over succesvolle toepassing van requirements, vanuit verschil-lende rollen. De workshop ging over de problemen die

we bij onze klanten regelmatig tegenkomen en die suc-cesvol requirements engineering bedreigen. In figuur 2 zijn de problemen samengevat in een aantal uitspraken.We lichten er in dit artikel een probleem uit: “Zelf geen requirement(s) aandragen”. In de praktijk zijn er belang-hebbenden die vinden dat ze zelf geen requirements hoeven aan te dragen. Het is immers de verantwoorde-lijkheid van de requirements engineer om requirements naar voren te brengen. Ze redeneren dat de requirements engineer de expert is.Gezien het aantal verschillende soorten belanghebben-den die normaliter een rol spelen in IT-projecten is het onmogelijk dat de requirements engineer over alle do-meinkennis beschikt van deze belanghebbenden. Door dit toch te verwachten van de requirements engineer is het risico dat er onvolledige en onjuiste requirements ko-men erg groot. Indien de belanghebbenden hun eigen

projecten moeten we op de juiste manier uitvoeren om het gewenste resultaat te bereiken, zonder extra kosten zoals het opnieuw moeten openbreken van de straat om de lantaarnpaal te kunnen verplaatsen.Voor IT-projecten is het eveneens van groot belang dat we die op de juiste manier uitvoeren. Aart J. van Dijk heeft in zijn promotieonderzoek naar Succes and Failure Factors in ICT projects: A Dutch Perspective onderzoek gedaan naar de factoren van IT-projecten die bepalend zijn voor een succes-volle afloop.In zijn studie beschrijft Van Dijk deze factoren, de zogenoemde Big Hitters. De studie vat succes-factoren samen die onder ande-re naar voren zijn gebracht door Capers Jones, John Smith en Peter Noordam. Van Dijk be-toogd in zijn onderzoek dat je, wanneer je aandacht geeft aan deze Big Hitters, je grote kans maakt op een succes. Maar ook dat wanneer je één Big Hitter verwaarloost de kans dat je project niet succesvol wordt haast een zeker-heid is.

De zeven Big Hitters zijn:1. Goed projectmanagement2. Realistische deadlines3. Goede communicatie4. Sterk en compleet requirements document5. Voldoende betrokkenheid van toekomstige

gebruikers6. Betrokkenheid en commitment van senior

management7. Voldoende professionaliteit (professionals)

Als je naar de lijst met Big Hitters kijkt, zie je dat requirements, het onderwerp van dit artikel expli-ciet genoemd is. En ze spelen ook een cruciale rol bij alle an-dere Big Hitters. Requirements leveren bijvoorbeeld een grote bijdrage aan goede communi-catie. Als ze zodanig beschreven zijn dat ze door alle belangheb-benden eenduidig geïnterpre-teerd worden, verbetert dit de onderlinge communicatie over de requirements.Ook de CHAOS rapporten van The Standish Group bevestigen keer op keer dat requirements een belangrijke, zo niet de be-langrijkste rol spelen bij het al dan niet slagen van projecten.

29oktober 2011 XR Magazine

Wanneer je één van de zeven Big Hitters verwaarloost is de kans zeer groot dat je

project niet succesvol wordt

Figuur 2: De meest voorkomende problemen bij requirements engineering

belang niet vertegenwoordigen zal het eindresultaat van het project niet voldoen aan de wensen en eisen van de gebruikers. Zo getuigt ook onderstaand voorbeeld:

De ‘hippe’ spijkerbroekTijdens een presentatie over requirements maakte een deelnemer vanuit de zaal de opmerking dat hij een keer, toen hij een kledingwinkel bezocht, aan een verkoopster vroeg om een hippe spijkerbroek. Hij ging er van uit dat die verkoopster voldoende wist om op basis van die in-formatie de juiste spijkerbroek voor hem te kunnen uit-zoeken. De requirements ten aanzien van de spijkerbroek werden dus aan de verkoopster overgelaten, stelde hij. Volgens hem gold dit ook voor de requirements engi-neer. Deze zou met een enkele opdracht de resterende requirements prima zelf kunnen bedenken. Toen ik hem vervolgens vroeg: ‘Zou je de hippe spijkerbroek die de verkoopster voor je heeft uitgezocht daarna ook ongezien afrekenen zonder dat je hem mag omruilen?’, was het ant-woord een duidelijk: ‘nee’! Met andere woorden, zoals je het bepalen van de maat, kleur, prijs, het model, merk van je hippe spijkerbroek niet overlaat aan de verkoopster, zo doe je dat ook niet met de requirements ten aanzien van de requirements engineer. Bij de vraagsteller viel het kwartje; hij gaf aan dat hij in toekomstige projecten zijn belangen voortaan zelf ging vertegenwoordigen.

Aanpak voor succesvolle requirementsAan de hand van de problemen die onze experts bij klan-ten tegenkomen rond het requirements proces zijn we gaan analyseren hoe we die kunnen aanpakken zodat we requirements engineering (proces, documentatie etc.) op een succesvolle manier kunnen toepassen. Op basis van alle problemen bij requirements engineering hebben we een vijftal aandachtspunten afgeleid (zie figuur 3). Be-steed je voldoende tijd en aandacht aan deze punten dan zal requirements engineering succesvol zijn.Wanneer je deze aandachtspunten gebruikt met een blik gericht specifiek op jouw project en bedrijfscultuur dan zal jouw project succesvol zijn. Laten we er een voorbeeld uit halen.

Organiseer je procesEen van de gevonden aandachtspunten is de inrichting van het requirements proces. Hoewel er veel theorie be-schikbaar is over requirements, blijft het bovenal men-senwerk. Een standaard requirements engineering pro-ces is een goed uitgangspunt, en om dit proces effectief te doorlopen is het belangrijk dat de verschillende par-tijen goed samenwerken. Op het moment dat meerdere mensen samenwerken om iets te bereiken, zoals binnen een project, is een duidelijke rolverdeling nodig.Een rolverdeling zorgt voor houvast. Iedereen binnen het

30 XR Magazine oktober 2011

Figuur 3: Aandachtspunten voor succesvol requirements engineering

Reageren op dit artikel? Klik hier.

Organiseerje proces

Leg require-ments vast

Start methet probleem

Weespragmatisch

Betrek debusiness

Succesvolrequirementsengineering

project weet van tevoren wat er van hem of haar verwacht wordt. Hiermee schep je duidelijkheid en voorkom je communicatieproblemen met de bijbehorende ergernis-sen.Het is bijvoorbeeld cruciaal voor het succes van requi-rements engineering om bij de kick-off van een project het proces, de rollen en de bijbehorende taken en ver-antwoordelijkheden toe te lichten aan het projectteam en de belanghebbenden. Dit geeft iedereen de tijd om goed na te denken over zijn/haar rol in het proces. Als er men-sen zijn die niet de juiste rol hebben gekregen, of geen mandaat hebben om namens hun afdeling requirements aan te dragen dan kan dit maar beter vroegtijdig helder zijn. Zodat tijdig de benodigde maatregelen genomen worden, zoals het wisselen van rollen of het aanvragen van mandaat. Het toepassen van de RACI (of RASCI), zie figuur 4 voor een voorbeeld, voor requirements enginee-ring tijdens de kick-off helpt bij het scheppen van deze duidelijkheid.Al met al leidt deze rolverdeling tot het oplossen van een deel van de in figuur 2 genoemde problemen. Hoe je dat doet is zoals eerder aangegeven een kwestie van goed kijken naar jouw organisatie of project (zie kader).Hiermee hebben we een aandachtspunt behandeld. In volgende artikelen gaan we in op de andere aandachts-punten voor succesvol requirements engineering.

31 oktober 2011 XR Magazine

Jan Willem Knop is als Product Manager / Consultant werkzaam bij Valori.www.valori.nl

Opd

rach

tgev

er

Bel

angh

ebbe

nde

Proj

ectm

anag

er

Req

uire

men

ts e

ngin

eer

1. Voer review uit C C A R

2. Kick off A C R R

3. Inventariseer losse eisen A A I R

4. Voer kwaliteitscontrole uit C C A R

5. Schrijf het eisendocument C C A R

6. Review het eisendocument A R I C

7. Schrijf het evaluatierapport C C A R

Precies volgens plan!Dit artikel is gebaseerd op het boek ‘Precies volgens Plan!’ geschreven door Mark Hoogveld, Jan Willem Knop en Marcel Schaar. Het boek gaat ook op de andere Big Hitters in en laat zien hoe het inrichten van een requirements proces hier invloed op heeft.In het boek ‘Precies volgens Plan!’ geven we meer concrete tips en adviezen waardoor requirements engineering succesvol uitgevoerd en geïmple-menteerd kan worden in een organisatie. In iedere organisatie! En uiteindelijk is ‘succesvol’ require-ments engineering vooral ook een kwestie van keuzes maken die passen bij jouw organisatie. Die keuzes maak je met al de mensen die het moeten doen. Requirements engineering is tenslotte men-senwerk.Ben je door het lezen van dit artikel benieuwd naar de andere tips in het boek, neem dan contact op met Valori of ga naar www.valori.nl.

Figuur 4: Rolverdeling belangrijke rollen in RE proces