Five Requirements Prioritization Methods

Karl Wiegers
Jun 3, 2020 · 7 min read

When customer expectations are high and timelines are short you need to make sure your project team delivers the most valuable functionality as early as possible. Prioritization is the only way to deal with competing demands for limited resources.

Stakeholders on a small project often can agree on requirement priorities informally. Large or contentious projects with many stakeholders demand a more structured approach. You need to removes some of the emotion, politics, and guesswork from the process. This article discusses several techniques teams can use for prioritizing requirements and some traps to watch out for.

Two Big Traps

In or Out

Pairwise Comparison and Rank Ordering

Rank ordering all requirements by priority is overkill, as you won’t be releasing them all individually. You’ll group them together by release or development iteration. Grouping requirements into features, or into small sets of requirements with similar priority or that otherwise must be implemented together, is sufficient.

Three-Level Scale

I like to consider the two dimensions of importance and urgency. Every requirement can be considered as being either important to achieving business objectives or not so important, and as being either urgent or not so urgent. This is a relative assessment among a set of requirements, not an absolute binary distinction. These alternatives yield four possible combinations (Figure 1), which you can use to define a priority scale:

  • High priority requirements are important because customers need the capability and urgent because they need it in the next release. Alternatively, there might be compelling business reasons to implement a requirement promptly, or contractual or compliance obligations might dictate early release. If a release is shippable without a particular requirement, then it is not high priority per this definition. That’s a hard-and-fast rule.
  • Medium priority requirements are important (customers need the capability) but not urgent (they can wait for a later release).
  • Low priority requirements are neither important (customers can live without the capability if necessary) nor urgent (customers can wait, perhaps forever).

Watch out for requirements in the fourth quadrant. They appear to be urgent to some stakeholder, perhaps for political reasons, but they really aren’t important to achieving your business objectives. Don’t waste your time implementing these — they don’t add sufficient value to the product. If they aren’t important, either set them to low priority or scrub them entirely.

Figure 1. Requirements prioritization based on importance and urgency.

On a large project you might want to perform prioritization iteratively. Have the team rate requirements as high, medium, or low priority. If the number of high-priority requirements is excessive and you can’t fit them all into the next release, perform a second-level partitioning of the high-priority ones into three groups. You could call them high, higher, and highest if you like, so people don’t lose sight of the fact that they were originally designated as high.

Those requirements rated “highest” become your new group of top-priority requirements. Then, group the “high” and “higher” requirements in with your original medium-priority group (Figure 2). Taking a hard line on the criterion of “must be in the next release or that release is not shippable” helps keep the team focused on the truly high-priority capabilities.

Figure 2. Multi-pass prioritization keeps the focus on a manageable set of top-priority requirements.

Watch for requirement dependencies when prioritizing with the three-level scale. You’ll run into problems if a high-priority requirement depends on another that’s planned for later implementation.


Must: The requirement must be satisfied for the solution to be considered a success.

Should: The requirement is important and should be included in the solution if possible, but it’s not mandatory to success.

Could: It’s a desirable capability, but one that could be deferred or eliminated. Implement it only if time and resources permit.

Won’t: This indicates a requirement that will not be implemented at this time but could be included in a future release.

The MoSCoW scheme changes the three-level scale of high, medium, and low into a four-level scale. It doesn’t offer any rationale for making the decision about how to rate the priority of a given requirement compared to others. MoSCoW is ambiguous as to timing, particularly when it comes to the “Won’t” rating: does it mean “not in the next release” or “not ever?” The three-level scale that considers importance and urgency and focuses specifically on the forthcoming release or iteration.

Agile projects often use the MoSCoW method, but I’m not a big fan of it. Here’s how one consultant described how a client company actually practiced the MoSCoW method:

All the action centers around getting an “M” for almost every feature or requirement that is captured. If something is not an “M” it will almost certainly not get built. Although the original intent may have been to prioritize, users have long since figured out to never submit something that does not have an “M” associated with it.

Do they understand the nuanced differences between S, C, and W? I have no idea. But they have figured out the implications of these rankings. They treat them all the same and understand their meaning to be “not happening any time soon.”


Give the prioritization team 100 imaginary dollars to work with. Team members allocate these dollars to “buy” items they’d like to have implemented from the set of candidate requirements. Allocating more dollars weights the higher-priority requirements more heavily. If one requirement is three times as important to a stakeholder as another, she might assign nine dollars to the first requirement and three dollars to the second.

But 100 dollars is all the prioritizers get — when they’re out of money, nothing else can be implemented, at least not in the release they’re currently focusing on. You could have different participants in the prioritization process perform their own dollar allocations, and then add up the total number of dollars assigned to each requirement. That will show which ones collectively come out as having the highest priority.

Watch out for participants who game the process to skew the results. If you really, REALLY want a particular requirement, you might give it all 100 of your dollars to try to float it to the top of the list. In reality, you’d never accept a system that possessed just that single requirement.

Nor does this scheme take into account any concern about the relative amount of effort needed to implement each of those requirements. If you could get three requirements each valued at $10 for the same effort as one valued at $15, you’re likely better off with the three. The scheme is based solely on the perceived value of certain requirements to a particular set of stakeholders, which is a limitation of many prioritization techniques.

It’s Not All Going to Fit


This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources. Karl’s latest book is The Thoughtless Design of Everyday Things.

Analyst’s corner

We are passionate about helping businesses do their job better!

Sign up for Top business analysis stories

By Analyst’s corner

A curated collection of recent stories from the Analyst's corner. Never miss an insightful article worth reading! Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids.

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids.

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store