University of Toronto Need to select what to implement Customers usually ask for way too much Why Prioritization is needed Balance time to market with amount of functionality Basic Trade offs Department of Computer Science Basics of Prioritization Lecture 20 Requirements Prioritization University of Toronto Department of Computer Science Decide which features go into the next release Cost Value Approach For each requirement feature ask Sorting Requirements by cost value How important is this to the customer Estimating Relative Costs Values using AHP How much will it cost to implement How risky will it be to attempt to build it What if stakeholders disagree Visualizing differences in priority Resolving Disagreements Perform Triage Some requirements must be included Some requirements should definitely be excluded That leaves a pool of nice to haves which we must select from 1 Easterbrook 2004 University of Toronto 2 Easterbrook 2004 University of Toronto Department of Computer Science A Cost Value Approach Department of Computer Science Estimating Cost Value Source Adapted from Karlsson Ryan 1997 Calculate return on investment Assess each requirement s importance to the project as a whole Absolute scale e g dollar values Requires much domain experience Assess the relative cost of each requirement Relative values e g less more a little somewhat very Compute the cost value trade off Value percent 30 25 Two approaches Much easier to elicit Prioritization becomes a sorting problem High priority Comparison Process options Basic sorting for every pair of requirements i j ask if i j E g bubblesort start in random order and swap each pair if out of order requires n n 1 2 comparisons Medium priority 20 15 Construct a Binary Sort Tree Requires O n log n comparisons 10 Contruct a Minimal Spanning Tree Low priority 5 5 10 15 20 25 for each pair Ri Ri 1 get the distance between them Requires n 1 comparisons 30 Cost percent Easterbrook 2004 3 Easterbrook 2004 4 1 University of Toronto University of Toronto Department of Computer Science Some complications Hierarchical Prioritization Hard to quantify differences Group Requirements into a hierarchy E g A goal tree easier to say x is more important than y E g A NFR tree than to estimate by how much Department of Computer Science Not all requirements comparable Only make comparisons between branches of a single node Better train system E g different level of abstraction E g core functionality vs customer enhancements Comparison set 1 Requirements may not be independent No point selecting between X and Y if they are mutually dependent minimize costs serve more passengers Stakeholders may not be consistent improve safety E g If X Y and Y Z then presumably X Z Different cost value assessments for different types of stakeholder more frequent trains increase train speed 5 Easterbrook 2004 University of Toronto Comparison set 2 add new tracks Stakeholders might not agree Department of Computer Science minimize operation costs increase safe distance minimize development costs clearer signalling Comparison set 4 Comparison set 3 6 Easterbrook 2004 University of Toronto Analytic Hierarchy Process AHP Department of Computer Science AHP example estimating costs Source Adapted from Karlsson Ryan 1997 Create n x n matrix for n requirements Req1 Req2 Req3 Req4 For element x y in the matrix enter 1 if x 3 if x 5 if x 7 if x 9 if x use the and y are of equal value is slightly more preferred than y is strongly more preferred than y is very strongly more preferred than y is extremely more preferred than y intermediate values 2 4 6 8 if compromise needed Req1 1 1 3 2 4 Req2 3 1 5 3 Req3 1 2 1 5 1 1 3 Req4 1 4 1 3 3 1 Normalise columns Req1 Req1 26 26 of ofthe thecost cost Req2 Req2 50 50 of ofthe thecost cost Req3 Req3 9 9 of ofthe thecost cost Req4 Req4 16 16 of ofthe thecost cost Result and for y x enter the reciprocal Estimate the eigenvalues Req1 Req2 Req3 Req4 E g averaging over normalized columns Calculate the sum of each column Divide each element in the matrix by the sum of it s column Calculate the sum of each row Divide each row sum by the number of rows This gives a value for each reqt giving the estimated percentage of total value of the project Easterbrook 2004 Source Adapted from Karlsson Ryan 1997 7 Easterbrook 2004 Req1 0 21 0 18 0 18 0 48 Req2 0 63 0 54 0 45 0 36 Req3 0 11 0 11 0 09 0 04 Req4 0 05 0 18 0 27 0 12 Source Adapted from Karlsson Ryan 1997 Sum the rows sum sum 4 1 05 0 26 1 98 0 50 0 34 0 09 0 62 0 16 8 2 University of Toronto University of Toronto Department of Computer Science Plot ROI graph Department of Computer Science Other selection criteria Repeat AHP process twice ROI ratio is not the only way to group requirements Once to estimate relative value Once to estimate relative cost Use results to calculate ROI ratio Above average value Below average cost High priority x x x 20 Value percent Value percent 25 15 10 x x 5 5 10 15 20 25 25 x Above average cost Below average value 15 10 5 30 9 Percentage of total value 10 8 6 4 15 20 Easterbrook 2004 25 15 x x 20 x 10 5 30 x Low Risk Exposure 5 10 15 20 25 30 Relative Loss 10 Source Adapted from Park et al 1999 Department of Computer Science Visualizing stakeholder satisfaction 10 Stakeholders M1 3 M2 M3 M4 M5 M6 2 M7 M8 Variation coefficient M9 right hand scale M10 Level of disagreement for each feature x Risk Exposure 25 University of Toronto Department of Computer Science Visualizing Value by stakeholder 12 10 High 30 Cost percent Source Adapted from Karlsson Ryan 1997 University of Toronto x x 5 Low priority x x 20 Cost percent Easterbrook 2004 Above average in both cost and value 30 Medium priority 30 Relative Probability Graph showing correlation between stakeholder s priorities and the group s priorities Can also be thought of as influence of each stakeholder on the group 1 2 0 Easterbrook 2004 0 Source Adapted from Regnell et al 2000 18 Features labeled A Q Z 11 Easterbrook 2004 Source Adapted from Regnell et al 2000 12 3 University of Toronto University of Toronto Department of Computer Science Can also weight each stakeholder Weight each stakeholder E g to reflect credibility Resolving Stakeholder Conflict Result Causes of Conflict Deutsch 1973 The priorities have changed E g to reflect size of constituency represented Department of Computer Science control over resources preferences and nuisances tastes or activities of one party impinge upon another values a claim that a value
View Full Document
Unlocking...