Follow Us on Twitter

Prioriteren van requirements in een ICT project

Gepubliceerd in

Juli 2013 - Het moment waarop een nieuw ICT project gaat starten, gaat vaak gepaard met een gevoel van lichte wanhoop. De context en kadering van het project is nog niet bekend, klant en leverancier kennen elkaar nog niet en er zijn nog zoveel vragen!

Waar moeten we beginnen, wat is belangrijk, hoe gaan we faseren, en hoe gaan we de witte plekken op de kaart invullen?

Niet alle eisen en wensen die bij projectaanvang en tijdens de loop van het project naar voren komen kunnen gerealiseerd worden. Geld, mankracht en tijd zijn beperkt. Het juist inschatten van de noodzaak en prioriteit van requirements is een belangrijke succesfactor voor elk project. Mijn ervaring is dat prioriteren een uitdagende taak kan zijn. Gelukkig zijn er technieken en methodes die daar bij kunnen helpen.

Dit Whitebook geeft een overzicht van deze technieken en best practices. Alhoewel het uitgangspunt vanuit een traditionele aanpak is, hoeft de werkwijze in een Agile project niet veel anders te zijn.

Voorbereidingsfase

Dit is de fase waarin geïnventariseerd moet worden. Het eerste doel is om te weten waar de informatie gehaald kan worden, waar de ingangen bij het bedrijf zijn. Wie is de sponsor (wie betaalt, en wat verwacht die voor zijn geld?), wie zijn de stakeholders (de belanghebbenden), en wie de key users? Deze personen moeten eerst aangewezen zijn voordat je ook maar iets aan requirements op kan stellen.

Het is van belang om in deze fase al te verifiëren of de key users voldoende kennis bezitten, of ze beslissingsbevoegd zijn, en of zij representatief zijn voor de gehele projectscope.

Houd in de gaten of ze voldoende tijd beschikbaar zijn voor het project.

Betrek de eindverantwoordelijke (sponsor) erbij en stem de afkadering en de mogelijke consequenties van de gemaakte beslissingen met hem af.

Probleemdomein

Oplossingsgericht denken is zonder twijfel een goede eigenschap, maar in de beginfase van een requirementsanalyse kan het er voor zorgen dat essentiële stappen overgeslagen worden.

Om goed te begrijpen wat er speelt, is het verstandig om stil te staan bij de probleembeschrijving en die grondig te onderzoeken. Om de “vraag achter de vraag” boven water te krijgen, “genereer” ik vragen door te beginnen met het ezelsbruggetje van de 7 W-s: Wie, Wat, Welke, Waar, Waarom, Wanneer, Waarmee. En als bonus “Hoe”.

Bijvoorbeeld: Wie…. levert de brondata aan? Waarom… worden aanvragen door 3 mensen beoordeeld? Hoe voorkom je dat onbevoegden kerncijfers aanpassen?

Dit zijn open vragen, die niet met ja of nee beantwoord kunnen worden. Alhoewel het antwoord al informatief kan zijn, geven ze aanleiding om verder te vragen. De stelregel is dat bij de 3e open vraag de echte motivatie boven water komt.

Deze fase is hét moment om al bestaande requirements kritisch door te nemen en waar nodig en mogelijk aan te passen. Ik ben vooral alert op requirements die worden omschreven als een oplossing. Dit zijn vaak requirements die "hoe" beschrijven in plaats van "wat".

Het probleemdomein en het oplossingsdomein

Samenvattend worden de volgende doelen gehaald in de probleemfase:

  • Duidelijk krijgen wie de "stakeholders" zijn;
  • Kennis opdoen van jargon en definities en een gezamenlijk begrip krijgen van de betekenis.;
  • Begrip vormen van de requirements en eisen, en van de achterliggende motivaties;
  • Opdrachtkader en requirements aanscherpen en waar nodig aanpassen.

Oplossingsdomein

Waar het Probleemdomein nog over de behoeften (needs) gaat, gaan we in het Oplossingsdomein echt kijken naar Features (functies, mogelijkheden) en Requirements (systeemeisen).

Detaillering van de wensen voor verschillende soorten requirements

Om requirements aan het licht te brengen, zijn vele technieken. Deze zijn uitvoerig beschreven in boeken en cursussen. In de volgende paragrafen beschrijf ik wat minder conventionele prioriterings- en workshoptechnieken die daarom niet minder effectief zijn. En ik wil wat dieper ingaan op Kwaliteitseisen, aangezien het belang om die te onderkennen niet altijd gezien wordt en ze in toenemende mate van belang worden.

Prioritering (MoSCoW)

MoSCoW wordt in veel boeken en cursussen uitvoerig besproken. Toch is het de moeite waard om die hier te benoemen, vooral omdat het vaak mis gaat in de interpretatie.

De letters M, S,C, W in MoSCoW staan voor: Must Have, Should Have, Could Have, en Will not have. Van die laatste wordt vaak gedacht dat die voor "Would Have"staat, een soort "Nice to have". Dat is echt niet het geval, de "leuk om te hebben" categorie is al "Could Have"; de requirements waar we best zonder kunnen, maar als er tijd over is, is het een prettige toevoeging. Onderwerpen in de categorie Will not have worden gewoon niet gerealiseerd. Althans, en dat is het tweede misverstand, niet in deze fase. Will not haves kunnen altijd geparkeerd worden, en in een volgende fase alsnog opgepakt. Zij zullen, net als Could Haves, opnieuw geëvalueerd worden en in veel gevallen een hogere prioriteit toegewezen krijgen. Het mag duidelijk zijn dat de Must Haves en een groot deel van de Should Haves in de eerste release terecht komen. Het is dus belangrijk voor ogen te houden dat die voor een belangrijk deel de omvang van de uiteindelijk scope zullen bepalen.

Ik merk dat ik altijd veel aandacht moet besteden aan het op één lijn krijgen van de definities van de 4 prioriteiten. De Must Have is vaak wel snel duidelijk, alhoewel het goed is om te blijven vragen bij deze status: 'heb je het wel écht nodig? Wat zou het gevolg zijn voor je bedrijfsproces als je tóch zonder dit onderdeel moest doen? Hoe kan je dit anders oplossen?'.

Het tweede aandachtspunt is dat deelnemers bang zijn dat de WIll not haves in een "zwart gat" verdwijnen. De angst is dat hun 'stokpaardjes' vergeten worden, in een volgende iteratie geen hogere prioriteit krijgen of dat er helemaal geen volgende release komt. Zolang die vrees niet erkend wordt, zal een prioriteringssessie onnodig verzanden in pogingen om onderdelen zo hoog mogelijk te prioriteren.

Workshoptechnieken

1) de Monopoly-sessie
Dit is een nuttige workshop als het inzetten van MoSCoW niet het gewenste resultaat heeft, of om gebruikers bewust te maken van de noodzaak tot prioriteren.

Geef elke gewenste functie of deelsysteem een kostprijs. Verdeel namaakgeld onder de deelnemers. Zorg ervoor dat de verdeling zo is, dat in ieder geval niet alles aangeschaft kan worden, en dat één persoon een zeer beperkt aantal functies kan kopen. Dit dwingt de deelnemers ten eerste om een keuze te maken uit de gewenste opties, maar ook om samen te werken (overtuigen, onderhandelen, concessies doen) om tot een optimaal resultaat te komen.

2) De rechtbank sessie.
Deze techniek kan gebruikt worden voor onderwerpen waar de meningen sterk uiteenlopen of de standpunten gepolariseerd zijn. Kies zo'n onderwerp uit, en verdeel de deelnemers in twee (willekeurige) groepen. Groep 1 is de aanklager, groep 2 de verdediging. Groep 1 gaat een lijst opstellen met tegenargumenten, groep 2 hetzelfde met vóórargumenten.

Vervolgens presenteren de 2 groepen de standpunten. De standpunten van de ander gehoord hebbende, gaan zij terug om met de nieuwe informatie een 'eindpleidooi' op te stellen. Ook deze worden weer gepresenteerd. Tenslotte benoemt elke groep de sterkste argumenten van de andere partij.

De kracht van deze workshopmethode is dat deelnemers moeten nadenken over alle consequenties van een standpunt, ook als die niet in het voordeel van hun voorkeur uitvalt.

Kwaliteitseisen

Kwaliteitseisen worden ook wel non-functionele requirements genoemd. Ze zeggen meer over de kwaliteit van het systeem (hoe werkt het) dan over de werking (wat doet het). Alhoewel kwaliteitseisen niet altijd kwantitatief te meten zijn, zijn ze erg belangrijk voor de acceptatie van het eindproduct. Voorbeelden van kwaliteitseisen: Performance, Veiligheid, Gebruikersvriendelijkheid, Eenvoud. Maar ook : Escrow, Documentatie, Fouttolerantie of Emotionele Factoren.

Er wordt wel gesteld dat grote blunders in softwareproducten tegenwoordig niet meer het gevolg zijn van bugs of softwarefouten, maar van het niet onder controle hebben van de kwaliteitseisen. Een webserver die niet goed beveiligd is, de kaartjesautomaat met ondoorgrondelijke menu's, of bedrijfskritische software die niet performt, allemaal hebben ze één ding gemeen: ze zijn als product zo goed als waardeloos en er is geen testcase die dit kan voorspellen.

Kwaliteitseisen zijn een integraal en niet te onderscheiden onderdeel van het product, en er kan alleen aan voldaan worden door vanaf de ontwerpfase duidelijk voor ogen te hebben welke eisen belangrijk zijn, en hoe daaraan voldaan kan worden.

Agile development

Waren informatie-analyse en ontwikkeling in een watervalproject nog afzonderlijke projectfases met een duidelijk begin en eind, in een agile project is daar geen sprake meer van. Agile analyse heeft een aantal kenmerken die bekend zijn uit de Agile methodiek:

Incrementeel.
Functionaliteit wordt in kleine stukjes beschreven en ontwikkeld. De onderdelen zijn zo klein dat ze in uren of dagen gerealiseerd kunnen worden. Voortschrijdend inzicht is goed, beter daarop te anticiperen dan het proberen ‘uit te bannen’

In hoge mate iteratief.
Zoveel informatie als nodig is voor deze fase van ontwikkeling wordt ontsloten. Dus niet meer, maar zeker niet minder. Dit geeft ook ruimte aan voortschrijdend inzicht.

Communiceren.
Ook hier geldt de agile gedachte: bij voorkeur face to face communicatie, zo min mogelijk interactie via papier of mail. Er is nauwe communicatie tussen ontwikkelaars, analisten en stakeholders. “Korte lijnen” moeten letterlijk genomen worden.

Verken en verlicht het probleemdomein
De essentie van een goede analyse is dat de “needs” van de stakeholders bekend zijn. Iedereen die betrokken is bij het project moet hiervan op de hoogte gebracht worden. Een duidelijk begrip van én overeenstemming over deze needs is cruciaal voor het slagen van een project.

Goed is goed genoeg
De beste code levert niet altijd het beste product. Zo is het ook met informatievergaring. Google heeft een fraaie stelregel: “besteed geen energie aan het vooraf bedenken wat er mis kan gaan, die kun je beter steken in de problemen die daadwerkelijk optreden.” In termen van use cases: beschrijf een Happy Day Scenario, en alleen de meest waarschijnlijke alternatieve scenarios en excepties, maar ga niet tot de bodem.

Alhoewel er met deze werkwijze geen formele informatieanalyse-fase meer bestaat, is er toch sprake van een projectlifecycle. De eerste fase wordt soms “Iteratie 0” genoemd, en bestaat uit het kort inventariseren van requirements, en een rudimentaire architectuurbeschrijving. Beide onderdelen zouden niet meer dan een paar dagen mogen kosten.

Het zwaartepunt van prioriteren in een Agile omgeving verplaatst van het begin van het project naar de backlog en de sprintplanning. De backlog is de werkvoorraad van een project. Hier vindt een eerste globale schifting plaats van de belangrijkste taken. De taken die zowel een hoge prioriteit hebben, alswel goed aansluiten bij een logische volgorde van het op te pakken werk, worden meegenomen in het sprintplanningsoverleg. Hier vindt een meer gedetailleerde inschatting van de hoeveelheid werk en de benodigde taken. Ook hier wordt weer gekeken wat in deze fase echt belangrijk is (MoSCoW!), en wat misschien kan vervallen of naar achteren geschoven.

Conclusie

Elk project heeft zijn eigen uitdagingen. Door stappen in de juiste volgorde te nemen, kan structuur aangebracht worden en het overzicht behouden worden. Een goede prioritering is daarin onmisbaar. Met de juiste (workshop)technieken is het mogelijk stakeholders en beslissers hierbij te helpen en bewust te maken.

Bij de Agile manier ligt het zwaartepunt iets anders, maar de principes veranderen niet en de technieken kunnen net zoals in een klassiek traject gebruikt worden. Uiteindelijk zal dat leiden tot een beheersbaar project met succes als resultaat.

 

Bronvermeldingen en verwante artikelen:
Dean Leffingwell, Don Widrig; Managing Software Requirements, a Use Case Approach
Diomidis Spinellis; Code Quality (2006, Addison Wesley)
Five Pitfalls of Requirement Writing
http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/Ar... " target="_blank" title="Agile Business Analysis: Interview with Scott Ambler"> Agile Business Analysis: Interview with Scott Ambler
Development Phases Examined: Why Requirements, Analysis, and Design Phases No Longer Make Sense (If They Ever Did)
Is the Business Analist an endangered species with the growth of Agile?

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.