Software-ontwikkeling of elk ander project dat te maken heeft met meerdere requirements, budgettaire beperkingen en krappe deadlines maakt het vaak noodzakelijk om de requirements van belanghebbenden te prioriteren. Op een gegeven moment is het meestal noodzakelijk om beslissingen te nemen over welke eisen eerst moeten worden geïmplementeerd en welke kunnen worden uitgesteld tot een latere release.

Er zijn talloze methoden ontwikkeld voor het prioriteren van eisen. Terwijl sommige het beste werken op een klein aantal requirements, zijn andere beter geschikt voor zeer complexe projecten met veel beslissers en variabelen. Deze lijst van requirements prioriteringstechnieken geeft een overzicht van veel voorkomende technieken die kunnen worden gebruikt bij het prioriteren van requirements.

Ranking

Wanneer je requirements rangschikt op een ordinale schaal, geef je ze elk een verschillende numerieke waarde op basis van hun belang. Bijvoorbeeld, het cijfer 1 kan betekenen dat de eis het belangrijkst is en het cijfer n kan worden toegekend aan de minst belangrijke eis, waarbij n het totale aantal eisen is. Deze methode werkt het beste als je te maken hebt met een enkele stakeholder, omdat het moeilijk kan zijn om de perspectieven van verschillende stakeholders op elkaar af te stemmen over wat de prioriteit van een requirement zou moeten zijn; het nemen van een gemiddelde kan dit probleem echter tot op zekere hoogte aanpakken.

Numerical Assignment (Grouping)

Deze methode is gebaseerd op het groeperen van requirements in verschillende prioriteitsgroepen, waarbij elke groep iets vertegenwoordigt waar stakeholders mee in verband kunnen worden gebracht. Bijvoorbeeld, kunnen de vereisten in kritieke prioriteit, gematigde prioriteit en facultatieve prioriteit worden gegroepeerd. Stakeholders kunnen requirements ook classificeren als verplicht, zeer belangrijk, tamelijk belangrijk, niet belangrijk, en doet er niet toe om hun belang te beschrijven.

Deze groepen moeten duidelijk worden gedefinieerd, zodat stakeholders niet een verschillend begrip van elk hebben tijdens de prioriteringsoefening. Om te voorkomen dat belanghebbenden alle eisen in één categorie plaatsen, moet het percentage eisen dat in elke groep kan worden geplaatst, worden beperkt. Een nadeel hiervan is echter dat requirements in elke groep dan dezelfde prioriteit krijgen en er geen unieke prioriteit per requirement wordt toegekend.

MoScoW Techniek

In plaats van getallen, gebruikt deze methode vier prioriteitsgroepen: MOETEN hebben, ZOU MOETEN hebben, KUNNEN hebben, en WIL NIET hebben. Met deze techniek kunnen belanghebbenden op een collaboratieve manier requirements prioriteren. Het acroniem staat voor:

• MUST (Verplicht)
• SHOULD (Van hoge prioriteit)
• COULD (Bij voorkeur, maar niet noodzakelijk)
• WOULD (Kan worden uitgesteld en voorgesteld voor toekomstige uitvoering)

De beslissingen van belanghebbenden over de prioriteiten van requirements worden gecategoriseerd zoals hierboven is weergegeven. Zie MoSCoW : Techniek voor het prioriteren van eisen voor meer informatie hierover.

Bubble Sort Technique

Om requirements te prioriteren met behulp van bubble sort, neemt u twee requirements en vergelijkt deze met elkaar. Als u ontdekt dat één vereiste een hogere prioriteit dan de andere zou moeten hebben, verwisselt u hen dienovereenkomstig. Je gaat dan op deze manier verder tot de allerlaatste requirement goed gesorteerd is. Het resultaat is een lijst van eisen die zijn gerangschikt.

Honderd Dollar Methode

Deze eenvoudige methode is nuttig overal waar meerdere belanghebbenden democratisch moeten stemmen over welke eisen het belangrijkst zijn. Alle belanghebbenden krijgen een conceptuele 100 dollar, die zij over de vereisten kunnen verdelen. Zo kan de belanghebbende ervoor kiezen om alle 100 dollar aan één enkele vereiste te geven, of hij kan de punten gelijkmatiger verdelen. Hoe hoger het bedrag dat aan elke eis wordt toegekend, hoe hoger de prioriteit van de eis. Aan het eind wordt het totaal geteld en worden de eisen gesorteerd op basis van het aantal ontvangen punten.

Deze techniek moet alleen worden gebruikt wanneer u een kleine groep eisen hebt om te prioriteren en wanneer u dezelfde set eisen hebt om te voorkomen dat respondenten hun resultaten beïnvloeden door meer dollars toe te wijzen aan hun favoriete eis.

Met deze techniek kan het echter moeilijk zijn om bij te houden hoeveel er is toegewezen en welk bedrag er nog over is om over te beschikken.

Analytic Hierarchy Process (AHP)

Deze beroemde methode voor het prioriteren van requirements is ontworpen door Thomas L. Saaty. De methode beschrijft in feite een volledig raamwerk voor het nemen van juiste beslissingen op gebieden zoals bedrijfsleven, gezondheidszorg, overheid, en vele anderen. In essentie, ontbinden de belanghebbenden hun doel in kleinere sub-problemen, die gemakkelijk kunnen worden begrepen en geanalyseerd (in de vorm van een hiërarchie).

Zodra de hiërarchie is gebouwd, evalueren de besluitvormers de elementen door paren met elkaar te vergelijken. Het totale aantal vergelijkingen dat bij AHP wordt aanbevolen is n × (n-1)/2 (waarbij n het aantal eisen is) op elk hiërarchisch niveau. De deelnemers vellen (soms op basis van gegevens) een oordeel over het relatieve belang van elk element. Aan elk element van de hiërarchie kunnen dan numerieke waarden (gebaseerd op prioriteiten) worden toegekend.

Deze methode is niet geschikt voor een groot aantal requirements, omdat het aantal requirements bepalend is voor het aantal vergelijkingen dat moet worden gemaakt.

Five Whys

Het komt vaak voor dat stakeholders een bepaalde feature willen implementeren om redenen die niet zijn gebaseerd op logische argumenten of de zakelijke belangen van het bedrijf. Met vijf waarom’s vraagt de analist de stakeholder herhaaldelijk (vijf keer of minder) waarom de eis noodzakelijk is, totdat het belang van de eis is vastgesteld. De antwoorden onthullen of de eis echt noodzakelijk is of kan worden geannuleerd/uitgesteld zodra de prioriteit is vastgesteld.

Conclusie