DOC PREVIEW
Toronto CSC 340 - Lecture 20 - Requirements Prioritization

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© Easterbrook 20041Lecture 20:Requirements Prioritization Why Prioritization is needed Basic Trade-offs Cost-Value Approach Sorting Requirements by cost/value Estimating Relative Costs/Values using AHP What if stakeholders disagree? Visualizing differences in priority Resolving DisagreementsUniversity of TorontoDepartment of Computer Science© Easterbrook 20042Basics of Prioritization Need to select what to implement Customers (usually) ask for way too much Balance time-to-market with amount of functionality Decide which features go into the next release For each requirement/feature, ask: How important is this to the customer? How much will it cost to implement? How risky will it be to attempt to build it? 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.University of TorontoDepartment of Computer Science© Easterbrook 20043A Cost-Value Approach Calculate return on investment Assess each requirement’s importance to the project as a whole Assess the relative cost of each requirement Compute the cost-value trade-off:Cost (percent)Value (percent)Low priorityMediumpriorityHighpriority5 10 15 20 25 3051015202530Source: Adapted from Karlsson & Ryan 1997University of TorontoDepartment of Computer Science© Easterbrook 20044Estimating Cost & Value Two approaches: Absolute scale (e.g. dollar values) Requires much domain experience Relative values (e.g. less/more; a little, somewhat, very) Much easier to elicit Prioritization becomes a sorting problem 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 Construct a Binary Sort Tree Requires O(n log n) comparisons Contruct a Minimal Spanning Tree for each pair (Ri, Ri+1) get the distance between them Requires n-1 comparisons2University of TorontoDepartment of Computer Science© Easterbrook 20045Some complications Hard to quantify differences easier to say “x is more important than y”… …than to estimate by how much. Not all requirements comparable E.g. different level of abstraction E.g. core functionality vs. customer enhancements Requirements may not be independent No point selecting between X and Y if they are mutually dependent Stakeholders may not be consistent E.g. If X > Y, and Y > Z, then presumably X > Z? Stakeholders might not agree Different cost/value assessments for different types of stakeholderUniversity of TorontoDepartment of Computer Science© Easterbrook 20046Hierarchical Prioritizationminimizecostsserve morepassengersimprovesafetyadd newtracksincreasesafe distancemore frequenttrainsincreasetrain speedminimizeoperationcostsminimizedevelopmentcostsclearersignalling Group Requirements into a hierarchy E.g. A goal tree E.g. A NFR tree Only make comparisons between branches of a single node:Bettertrain systemComparison set 1Comparison set 2Comparison set 3Comparison set 4University of TorontoDepartment of Computer Science© Easterbrook 20047Analytic Hierarchy Process (AHP) Create n x n matrix (for n requirements) For element (x,y) in the matrix enter: 1 - if x and y are of equal value 3 - if x is slightly more preferred than y 5 - if x is strongly more preferred than y 7 - if x is very strongly more preferred than y 9 - if x is extremely more preferred than y (use the intermediate values, 2,4,6,8 if compromise needed) …and for (y,x) enter the reciprocal. Estimate the eigenvalues: 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 projectSource: Adapted from Karlsson & Ryan 1997Source: Adapted from Karlsson & Ryan 1997University of TorontoDepartment of Computer Science© Easterbrook 20048131/31/4Req41/311/51/2Req33513Req2421/31Req1Req4Req3Req2Req10.120.040.360.48Req40.270.180.05Req40.090.110.11Req30.450.540.63Req20.180.180.21Req1Req3Req2Req1NormalisecolumnsSumtherows0.160.620.090.340.501.980.261.05sum/4sumAHP example - estimating costsSource: Adapted from Karlsson & Ryan 1997Req1 - 26% of the costReq2 - 50% of the costReq3 - 9% of the costReq4 - 16% of the costResult3University of TorontoDepartment of Computer Science© Easterbrook 20049Plot ROI graphCost (percent)Value (percent)Low priorityMediumpriorityHighpriority5 10 15 20 25 3051015202530xxxxx Repeat AHP process twice: Once to estimate relative value Once to estimate relative cost Use results to calculate ROI ratio:Source: Adapted from Karlsson & Ryan 1997University of TorontoDepartment of Computer Science© Easterbrook 200410Other selection criteria ROI ratio is not the only way to group requirementsCost (percent)Value (percent)Above average costBelow average valueAbove averagein both cost and value5 10 15 20 25 3051015202530xxxxxRelative LossRelative ProbabilityHigh Risk ExposureLow Risk Exposure5 10 15 20 25 3051015202530xxxxxAbove average valueBelow average costSource: Adapted from Park et al, 1999University of TorontoDepartment of Computer Science© Easterbrook 200411Visualizing “Value by stakeholder”10 Stakeholders:M1M2M3M4M5M6M7M8M9M100%2%4%6%8%10%12%Variation coefficient(right hand scale)“Level of disagreementfor each feature”1203Percentage of total valueSource: Adapted from Regnell et al, 200018 Features (labeled A-Q +Z)University of TorontoDepartment of Computer Science© Easterbrook 200412Visualizing stakeholder satisfaction Graph showing correlation between stakeholder’s priorities andthe group’s priorities Can also be thought of as “influence of each stakeholder on the group”Source: Adapted from Regnell et al, 20004University of TorontoDepartment of Computer Science© Easterbrook 200413Can also weight each stakeholder Weight eachstakeholder E.g. to reflectcredibility? E.g. to reflect size ofconstituencyrepresented? Example:Result:(The priorities have changed)Source: Adapted from Regnell et al, 2000University of


View Full Document

Toronto CSC 340 - Lecture 20 - Requirements Prioritization

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download Lecture 20 - Requirements Prioritization
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 20 - Requirements Prioritization and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 20 - Requirements Prioritization 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?