Knowledge

Requirement prioritization

Source 📝

77:. Its basic idea is that for all pairs of (candidate) requirements a person assesses a value or a cost comparing the one requirement of a pair with the other. For example, a value of 3 for (Req1, Req2) indicates that requirement 1 is valued three times as high as requirement 2. Trivially, this indicates that (Req2, Req1) has value ⅓. In the approach of Karlsson and Ryan, five steps for reviewing candidate requirements and determining a priority among them are identified. These are summed up below. 49:
candidate software requirements for a product are gathered and organized. Finally, in the release planning activity, these requirements are prioritized and selected for a release, after which the launch of the software product can be prepared. Thus, one of the key steps in release planning is
27:
of a software product should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first. Several methods for assessing a prioritization of software requirements exist.
94:
A software engineer uses AHP to calculate each candidate requirement’s relative value and implementation cost, and plots these on a cost-value diagram. Value is depicted on the y axis of this diagram and estimated cost on the
40:
there exist several sub processes. First of all there is portfolio management where a product development strategy is defined based on information from the market and partner companies. In product roadmapping (or
98:
The stakeholders use the cost-value diagram as a conceptual map for analyzing and discussing the candidate requirements. Now software managers prioritize the requirements and decide which will be implemented.
62:
is the cost-value approach. This approach was created by Joachim Karlsson and Kevin Ryan. The approach was then further developed and commercialized in the company Focal Point (that was acquired by
66:
in 2005). Their basic idea was to determine for each individual candidate requirement what the cost of implementing the requirement would be and how much value the requirement has.
230: 283:
A Reference Framework for Software Product Management. Scientific Report. Department of Information and Computing Sciences, Utrecht University, The Netherlands, 2006
217: 106:. As mentioned earlier, release planning is part of this process. Prioritization of software requirements is a sub process of the release planning process. 81:
Requirement engineers carefully review candidate requirements for completeness and to ensure that they are stated in an unambiguous way.
91:
Experienced software engineers use AHP’s pairwise comparison to estimate the relative cost of implementing each candidate requirement.
45:), themes and core assets of products in the portfolio are identified and roadmap constructions are created. In 303: 260: 102:
Now, the cost-value approach and the prioritizing of requirements in general can be placed in its context of
298: 135: 103: 37: 20: 85: 70: 147: 84:
Customers and users (or suitable substitutes) apply AHP’s pairwise comparison method to assess the
181:
RICE Scoring Model for quick prioritization (RICE score = (Reach * Impact * Confidence) / Effort)
46: 42: 220:." Product focused software process improvement. Springer Berlin Heidelberg, 2004. 497-508. 8: 246:
Karlsson, J. & Ryan, K. (1997). A Cost-Value Approach for Prioritizing Requirements,
141: 278: 165: 178:
ICE Scoring Model for quick prioritization (ICE score = Impact * Confidence * Ease)
69:
The assessment of values and costs for the requirements was performed using the
292: 173: 153: 74: 58:
A good and relatively easy to use method for prioritizing software product
24: 59: 159: 63: 184:
Software Engineering Risk: Understanding and Management (SERUM)
109:
The release planning process consists of the sub processes:
281:, R. Nieuwenhuis, J. Versendaal and L. Bijlsma (2006). 216:
Lehtola, Laura, Marjo Kauppinen, and Sari Kujala. "
218:Requirements prioritization challenges in practice 129: 290: 235:Engineering and managing software requirements. 229:Berander, Patrik, and Anneliese Andrews. " 190:Value Oriented Prioritization Method (VOP) 237:Springer Berlin Heidelberg, 2005. 69-94. 170:Planning Game combined with AHP (PGcAHP) 291: 261:"ICE Scoring Model for Prioritization" 164:100-point method (100P) also known as 53: 248:IEEE Software September/October 1997 13: 271: 73:(AHP). This method was created by 14: 315: 23:for determining which candidate 130:Other prioritization techniques 31: 253: 240: 223: 210: 88:of the candidate requirements. 1: 203: 122:Validate release requirements 50:requirements prioritization. 285:. Submitted for publication. 193:Minimal Spanning Tree (MST), 7: 231:Requirements prioritization 136:Quality Function Deployment 119:Define release requirements 104:Software product management 38:Software product management 21:Software product management 10: 320: 71:Analytic Hierarchy Process 17:Requirement prioritization 148:Ordinal priority approach 113:Prioritize requirements 47:requirements management 43:technology roadmapping 304:Software requirements 116:Select requirements 54:Cost-value approach 299:Product management 199:Numeral Assignment 142:Binary Search Tree 279:Sjaak Brinkkemper 277:I. van de Weerd, 196:Bubble Sort (BS), 166:Cumulative voting 311: 265: 264: 257: 251: 244: 238: 227: 221: 214: 319: 318: 314: 313: 312: 310: 309: 308: 289: 288: 274: 272:Further reading 269: 268: 259: 258: 254: 245: 241: 228: 224: 215: 211: 206: 132: 56: 34: 19:is used in the 12: 11: 5: 317: 307: 306: 301: 287: 286: 273: 270: 267: 266: 252: 239: 222: 208: 207: 205: 202: 201: 200: 197: 194: 191: 188: 185: 182: 179: 176: 171: 168: 162: 157: 151: 145: 139: 131: 128: 127: 126: 125:Prepare launch 123: 120: 117: 114: 100: 99: 96: 92: 89: 86:relative value 82: 55: 52: 33: 30: 9: 6: 4: 3: 2: 316: 305: 302: 300: 297: 296: 294: 284: 280: 276: 275: 262: 256: 249: 243: 236: 232: 226: 219: 213: 209: 198: 195: 192: 189: 186: 183: 180: 177: 175: 174:MoSCoW Method 172: 169: 167: 163: 161: 158: 155: 154:Planning game 152: 149: 146: 143: 140: 137: 134: 133: 124: 121: 118: 115: 112: 111: 110: 107: 105: 97: 93: 90: 87: 83: 80: 79: 78: 76: 72: 67: 65: 61: 51: 48: 44: 39: 29: 26: 22: 18: 282: 255: 247: 242: 234: 225: 212: 108: 101: 75:Thomas Saaty 68: 60:requirements 57: 35: 32:Introduction 25:requirements 16: 15: 293:Categories 204:References 160:PROMETHEE 64:Telelogic 250:, 67-74. 95:x-axis. 187:EVOLVE 150:(OPA) 144:(BST) 138:(QFD) 156:(PG) 233:." 36:In 295:: 263:.

Index

Software product management
requirements
Software product management
technology roadmapping
requirements management
requirements
Telelogic
Analytic Hierarchy Process
Thomas Saaty
relative value
Software product management
Quality Function Deployment
Binary Search Tree
Ordinal priority approach
Planning game
PROMETHEE
Cumulative voting
MoSCoW Method
Requirements prioritization challenges in practice
Requirements prioritization
"ICE Scoring Model for Prioritization"
Sjaak Brinkkemper
Categories
Product management
Software requirements

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.