Prioriteren van Business Requirements

Prioriteren van requirements De eerste stap in het samenstellen van business requirements is het verzamelen van de eisen. De tweede stap is het prioriteren van deze eisen. Soms een lastige stap omdat de business consultant de opdrachtgever moet teleurstellen wanneer enkele requirements niet geïmplementeerd worden.

Betrokkenen prioriteren de requirements vaak op basis wat schaars lijkt te zijn: tijd of geld. Is tijd beperkend, dan krijgen requirements een hoge prioriteit die snel te implementeren zijn, is het budget beperkend dan worden 'goedkoop' te realiseren requirements gekozen.

Met deze ad hoc methode verliest een organisatie veel geld: snel te implementeren of goedkope requirements leveren vaak niet de grootste bijdrage aan de cash flow voor een organisatie. In dit artikel staat een overzicht van meer systematische methodes van prioritering, waarbij de waarde van een requirement de prioriteit bepaalt. Hoe de waarde wordt bepaald is afhankelijk van de methode; in enkele methoden wordt de waarde gevoelsmatig bepaald. Het artikel begint met de conclusie en een overzicht welke methode u kiest voor welke situatie. Wat volgt is een beschrijving van de methodes.

Met een systematische aanpak voorkomt de business consultant tevens dat de opdrachtgever teleurgesteld wordt omdat sommige van zijn requirements niet gerealiseerd worden: met een systematische aanpak zijn criteria voor de prioritering transparant. Uiteraard wel handig om als business consultant deze criteria vooraf met de opdrachtgever door te nemen.

Het artikel begint met de conclusie en volgt met een beschrijving van veel gebruikte prioritering methoden.

Conclusie

  1. Binaire vertakking (Binary search tree "BST")
  2. Numerieke kwalificatie (Numeral Assignment Technique)
  3. Planning spel (Planning Game "PG")
  4. 100 punten methode ("100P")
  5. W-Theorie of win-win theorie
  6. Requirements Triage

Bronnen

Conclusie

De business consultant heeft een aantal prioritering methodes tot zijn beschikking, waarmee de consultant op een transparante/objectieve manier de prioritering van requirements kan begeleiden. De methode die de consultant kiest, hangt af van de situatie bij de klant.

1. Binaire vertakking (Binary search tree "BST")

Uitgangspunt is het bepalen van de relatieve waarde van requirements. De consultant legt alle requirements op een stapel en kiest de eerste requirement van de stapel als startpunt (stam). Vervolgens houdt de consultant de volgende requirement tegen de stam requirement aan en wegen deelnemers af of dit nieuwe requirement belangrijker dan wel minder belangrijk is dan de stam requirement. Het resultaat is een linker loot (deelnemers vinden het requirement minder belangrijk dan de stam) of een rechter loot (deelnemers vinden requirement belangrijker dan de stam). De volgende requirement wordt vervolgens tegen de stam en de eerste loot afgewogen. Is deze bijvoorbeeld minder belangrijk dan de stam, maar belangrijker dan de eerste loot dan wordt deze requirement als rechter loot toegevoegd aan de eerste loot. Klinkt ingewikkeld? Valt wel mee (zie figuur). Als de deelnemers alle requirements geprioriteerd hebben, worden deze door de business consultant gerangschikt in een lijst, omwille van een betere presentatie.
business requirements prioritering

2. Numerieke kwalificatie (Numeral Assignment Technique)

Deelnemers kwalificeren het belang van een requirement middels een cijfer; op het eind van de exercitie worden de kwalificaties verzameld en gemiddeld. Dit gemiddelde bepaalt de prioriteit van een requirement.

Bracket, één van de grondleggers van deze methode stelt drie schalen voor: Noodzakelijk (mandatory "1"), wenselijk (desirable "2") en niet nodig (inessential "3"). Soms is het handig meer schalen te hanteren om wat sterker te differentiëren en te voorkomen dat van de 15 requirements er 14 het stempel Noodzakelijk krijgen (gemiddelde van 1). Karlsson gebruikt bijvoorbeeld vijf schalen:

  1. doet er niet toe ("klant heeft het niet nodig")
  2. niet belangrijk ("klant hecht weinig waarde aan dit requirement")
  3. belangrijk("klant vindt het requirement wenselijk")
  4. zeer belangrijk("klant vindt het noodzakelijk")
  5. noodzakelijk("klant kan niet zonder")

3. Planning spel (Planning Game "PG")

De deelnemer schrijft de requirements op een scenario kaart ("story card"). De deelnemer verdeelt de requirements vervolgens in drie groepen:
  1. noodzakelijk voor functioneren
  2. niet noodzakelijk, maar heeft veel waarde voor de klant
  3. wenselijk/nice to have.
Een technisch medewerker schat onderwijl in hoeveel tijd het kost een bepaalde requirement te implementeren. De technische medewerker stelt ook drie groepen samen, gebaseerd op onderliggend risico:
  1. Requirements waarbij inspanning precies geschat kunnen worden
  2. Requirements waarbij inspanning binnen ruime marges geschat kunnen worden
  3. Requirements waarbij inspanning niet geschat kunnen worden
De deelnemers verzamelen de "noodzakelijk voor functioneren" requirements en bepalen aan de hand van deze lijst welke functionaliteit onderdeel vormt van de volgende release of het gehele systeem. Indien nog tijd beschikbaar is wordt de categorie "niet noodzakelijk, maar heeft wel veel waarde voor de klant" toegevoegd, waarbij requirements waarvan de inspanning goed geschat kunnen worden, de hoogste prioriteit krijgen.

4. 100 Punten methode ("100P")

Deelnemers krijgen ieder 100 punten die zij mogen verdelen over de requirements. Hoe meer punten hoe belangrijker een requirement. Deelnemers zijn vrij te bepalen hoe de punten worden verdeeld: vindt een deelnemer een requirement zó belangrijk, dan kan hij 100 punten aan een dergelijk requirement toekennen. Om het geheel reëler te maken werken sommige consultants met Monopoly geld of Poker fiches. De punten worden door deelnemers individueel ingevuld. Het eindresultaat wordt aan de consultant overhandigd die de inschatting van individuele deelnemers middelt. De 100 punten methode wordt in één ronde uitgevoerd.

5. W-theorie of Win-Win Theorie

Uitgangspunt van de W- of de win-win theorie is: iedere belangrijke stakeholder dient als winnaar uit de onderhandelingen te komen in het samenstellen van een nieuw product, proces of systeem. Stakeholders zijn bijvoorbeeld klanten, propositiemanager, ontwikkelaar, etc. De win-win theorie past de consultant toe middels een cyclisch proces waarin zeven iteraties plaatsvinden (zie figuur). In iedere cyclus wordt het systeem gedetailleerder gespecificeerd. De zeven fasen in een cyclus zijn: Cyclus win-win theorie business requirements prioritering
  1. Identificeer de belangrijkste stakeholders;
  2. Identificeer win doelstellingen/requirements van de stakeholders;
  3. Breng win doelstellingen/requirements van de stakeholders op één lijn, zodat het team werkt met één set van doelen.
  4. Specificeer de belangrijkste product en proces requirements voor een (sub)systeem, condities en alternatieven.
  5. Evalueren de alternatieven aan de hand van gedefinieerde requirements en condities. Identificeer tevens grote product en proces risico's.
  6. Specificeer product en proces requirements meer in detail.
  7. Bereid de volgende cyclus voor: wie zijn de stakeholders en wat de producten en processen in scope. Onderdeel van deze fase is een go-nogo beslissing voor de volgende cyclus of het opnemen van parallelle cyclussen.
Wanneer alle cyclussen afgerond zijn (no-go voor volgende iteratie) is het systeem in voldoende mate/detail geïmplementeerd.

6. Requirements Triage

Deze methode hanteert als afweging voor het opnemen van een requirement in een oplossing de consequentie van deze beslissing: kunnen we het realiseren? En wat levert de requirement op in de totale oplossing? Deelnemers aan een sessie kunnen aan de volgende variabelen sleutelen ten aanzien van een requirement:
  1. Requirement toevoegen, verwijderen of aanpassen
  2. De opleverdatum van requirement eerder/later
  3. Ontwikkelcapaciteit toe of af laten nemen
  4. Waarde van oplossing/requirement toe of af laten nemen
  5. Kosten voor de oplossing toe of af laten nemen
  6. Kosten oplossing (incl. marketing en sales) toe of af laten nemen.
Deelnemers sleutelen net zolang aan al de requirements en bovenstaande set van variabelen totdat een samenhangende set van requirements gedefinieerd is die maximaal tegemoet komt aan de wensen van de business. Hiermee gaat het team vervolgens aan de slag. Bovenstaande bevat in hoofdlijn de kosten en opbrengsten van de oplossing.

Bronnen

Nancy R. Mead, "Requirements Prioritization Introduction" 2006, Carnegie Mellon University
Alexander Egyed, Barry Boehm "Analysis of System Requirements Negotiation Behavior Patterns" 1997, University of Southern California
Barry Boehm, Dan Port, Kevin Sullivan, "Value Based Software Engineering" University of Southern California
Alan M. Davis, Ed Yourdon, Ann S. Zweig, "Requirements Management Made Easy" 2000, Colorado Springs
Laura Lehtola "Providing value by prioritizing requirements throughout software product development", 2006, Espoo
Viggo Ahl, "An experimental comparison of five prioritization methods" 2005, Blekinge(Se)