DOC PREVIEW
Toronto CSC 340 - Lecture 20 - Requirements Prioritization

This preview shows page 1-2-3-4-5 out of 15 pages.

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

Unformatted text preview:

University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Basics 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3A 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Estimating 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 comparisonsUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Some 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6Hierarchical 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Analytic 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 1997University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8131/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 costResultUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9Plot ROI graphCost (percent)Value (percent)Low priorityMediumpriorityHighpriority5 10 15 20 25 3051015202530xxxxx Do 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© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10Other 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


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?