Some requirements are more important than others. For example, the need for an online bank to support the transfer of funds between accounts is likely far more important than an Elbonian-language version of a monthly bank statement. Successful software teams will focus on building the most important features first, making the critical functionality available to their users as soon as possible and leaving the less critical features for future releases. Requirements prioritization enables your team to deliver the most bang for your organization's software buck. You must consider several factors to effectively prioritize requirements:

• Value to the business
• Cost to deliver
• Time to deliver
• Complexity to deliver
• Risks (see the tip "Manage risk: Don't let it manage you")
• Relation to other requirements
• When the requirement is needed

Potential prioritization rating scales

It doesn't really matter what prioritization rating scale you use, as long as the ratings are well-defined and applied consistently. Common rating scales include:

• High, Medium, Low
• Essential, Conditional, Optional
• Numeric (for example, 1, 2, 3)

Back to top

How to prioritize requirements

You should have either an individual or a group with the authority to set and then confirm the assigned priorities. Prioritization is often a negotiation process, one that involves a wide range of project stakeholders including your users, user management, senior management, developers, and your operations and support departments.

Most project teams will define a configuration control board (CCB) -- sometimes called a change control board or a project steering committee -- that is composed of critical and, one would hope, knowledgeable stakeholders of your system. This group meets regularly to decide on the priority and assignment (either to releases of your system or to iterations within your existing development efforts) of any new requirements.

Back to top

Why prioritize your requirements?

A list of prioritized requirements is a key input into your project scoping efforts. Early in your project, one of the hardest things that you need to do is recognize that you aren't going to be able to deliver every feature requested by your project stakeholders. Your project scope defines a boundary around what your project team will deliver. This is important because it helps to avoid "scope creep," the addition of new requirements as the project progresses. A defined project scope enables you to negotiate whether you are responsible for delivering a newly-identified requirement, to justify why a new requirement will increase the delivery time/cost, and to argue that the requirement should be delivered in a later release. Without a defined scope, your project team is in danger of never delivering because you constantly have "just one more feature" added to what you're building.

Resources

• Process Patterns -- Building Large-Scale Systems Using Object Technology by Scott Ambler. New York: Cambridge University Press, 1998.
  
  
• More Process Patterns -- Delivering Large-Scale Systems Using Object Technology by Scott Ambler. New York: Cambridge University Press, 1999.
  
  
• The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2000.
  
  
• The Unified Process Inception Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
  
  
• Managing Software Requirements: A Unified Approach by Dean Leffingwell and Don Widrig. Reading, MA: Addison Wesley Longman, Inc., 2000.
  
  
• Software Requirements by Karl Wiegers. Redmond, WA: Microsoft Press, 1999.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Potential prioritization rating scales
• How to prioritize requirements
• Why prioritize your requirements?
• Resources
• About the author
• Comments