Prioritizing Requirements

In the previous chapter, we categorized our requirements using the MoSCoW Method.

By this point, we should have a good understanding of:

• What functionality is essential;
• What functionality is important but not critical;
• What functionality would be nice to have; and
• What functionality falls outside the scope of the project.

However, categorization only tells us how important a requirement is.

It does not tell us when that requirement should be developed.

To answer that question, we need to prioritize our requirements.

Importance Versus Priority

Students often assume that importance and priority mean the same thing.

They do not.

A requirement may be extremely important but not need to be implemented immediately.

Similarly, a requirement may be less important overall but need to be completed early because other functionality depends on it.

Think of it this way:

• Categorization asks: How important is this requirement?
• Prioritization asks: When should we work on this requirement?

Both perspectives are important.

Categorization helps define the scope of the project.

Prioritization helps organize the development process.

Categorization is informed by what the client and user needs.

Prioritization is informed by the developers.

The Challenge of Ranking Requirements

Imagine that your team has been asked to build a new social networking platform with functionality similar to Facebook.

The system must support:

• User accounts
• Privacy settings
• Messaging
• Content sharing
• Data security
• Facial recognition login
• Notifications
• Search functionality
• And dozens of other features

Now imagine that you have identified 150 requirements.

Which requirement should be ranked number 1?

Which should be ranked number 2?

What about number 37?

Or number 92?

As the number of requirements grows, ranking every requirement from 1 to N becomes increasingly difficult.

More importantly, it often leads to unnecessary debates.

One team member may believe a requirement deserves to be ranked 10th.

Another may believe it should be ranked 11th.

A third may argue for 12th.

While these discussions can be interesting, they rarely produce meaningful differences in project outcomes.

Using Priority Bins

Rather than assigning every requirement a unique rank, we group requirements into broader priority categories.

In CIS3750, we use five priority bins:

Using bins makes prioritization faster, simpler, and more practical.

Instead of debating whether a requirement should be ranked 14th or 15th, the team focuses on a more useful question:

Does this requirement belong in the same priority group as these other requirements?

This approach encourages discussion about relative importance while avoiding unnecessary precision.

A Team-Based Process

Prioritization works best when it is collaborative.

For each requirement:

1. Read the requirement aloud.
2. Have each team member independently assign a priority bin.
3. Ask team members to record any assumptions, concerns, or questions.
4. Share rankings with the group.
5. Discuss differences in perspective.
6. Agree on a final priority.

The goal is not simply to produce a number.

The goal is to understand how different people are interpreting the requirement.

What If Everyone Agrees?

If every team member assigns the same priority, that is often a sign that the requirement is well understood.

However, do not immediately move on.

Take a moment to discuss why everyone selected the same priority.

Shared reasoning is often just as valuable as identifying disagreement.

You may discover assumptions that everyone is making without realizing it.

What If Everyone Disagrees?

Disagreement is not a problem.

In fact, disagreement is often where the most valuable conversations occur.

When team members assign different priorities, ask questions such as:

• Why did you choose that priority?
• What assumptions influenced your decision?
• Are you considering a dependency that others missed?
• Are you interpreting the requirement differently?

These conversations frequently uncover misunderstandings, missing requirements, hidden dependencies, or opportunities for clarification.

The purpose of prioritization is not simply to assign numbers.

The purpose is to improve the team’s understanding of the problem.

Prioritization Reveals Hidden Assumptions

One of the most valuable aspects of prioritization is that it forces teams to explain their thinking.

Consider a requirement that one team member ranks as a 10 and another ranks as a 40.

Why might this happen?

Perhaps:

• One person assumes the feature is critical to users.
• Another assumes it is optional.
• One person sees a dependency.
• Another does not.
• One person believes the client emphasized the requirement.
• Another interpreted the conversation differently.

These differences often reveal assumptions that should be discussed before development begins.

For this reason, always discuss the reasoning behind a priority assignment, even when the final priority seems obvious.

Connecting Categorization and Prioritization

Categorization and prioritization are closely related.

As a general rule, higher-priority bins tend to contain more Must requirements, while lower-priority bins tend to contain more Could requirements.

However, there is no universal formula.

Every project is different.

For example, one project might contain:

• Must requirements in bins 10, 20, and 30;
• Should requirements in bins 30 and 40;
• Could requirements in bins 40 and 50.

Another project may organize requirements very differently.

What matters is that the relationship between categories and priorities remains logical and consistent.

Managing Overlap Between Categories

In practice, it is helpful to keep overlap between categories relatively small.

Ideally, categories overlap by at most one priority bin.

For example:

Notice that:

• Must and Should overlap only at 30.
• Should and Could overlap only at 40.

This structure provides flexibility while maintaining a clear distinction between levels of importance.

Why is this useful?

Later in the design process, we will begin examining dependencies and development order.

When categories overlap excessively, it becomes more difficult to reason about the logical flow of requirements.

A limited amount of overlap helps maintain clarity.

There Is No Perfect Priority List

Students often worry about assigning the “correct” priority.

In reality, prioritization is rarely exact.

Different teams may arrive at slightly different results.

Different clients may value different features.

Priorities may even change as a project evolves.

The goal is not perfection.

The goal is to create a prioritization structure that:

• Reflects the needs of the client;
• Supports logical development;
• Helps manage resources effectively; and
• Encourages meaningful discussion within the team.

If your prioritization process helps your team better understand the project, then it has already been successful.

Activity: Evaluating Categories and Priorities

The following diagrams illustrate different ways requirements might be categorized and prioritized.

For each example:

1. Determine whether the categorization and prioritization make sense.
2. Identify any potential issues.
3. Explain your reasoning.

As you evaluate each diagram, consider:

• Are the priority assignments logical?
• Is there excessive overlap between categories?
• Do the categories reflect the intended importance of the requirements?
• Would the structure help or hinder development planning?

Remember that the goal is not simply to assign numbers.

The goal is to create a prioritization scheme that helps the team understand what should be built first and why.