Prioritizing Requirements with the MuSCoW Method

When you first meet with a client or user, they will often describe the functionality they want using phrases such as:

• “It absolutely has to…”
• “We really need…”
• “It would be great if…”
• “It would be nice if…”
• “Maybe someday we could…”

As software designers, one of our responsibilities is to capture these needs and translate them into a structured list of requirements.

However, not every requirement has the same level of importance.

Some functionality is essential.

Some functionality is desirable.

Some functionality is optional.

And some functionality may be intentionally excluded from the project altogether.

To help organize these different levels of importance, software teams often use the MuSCoW Method.

What Is the MuSCoW Method?

The MuSCoW Method is a categorization framework that groups requirements into four categories:

• Must
• Should
• Could
• Won’t

These categories help teams decide what needs to be developed first, what can be delayed, and what falls outside the scope of the project.

More importantly, they help establish shared expectations between the software team and the client.

A well-categorized set of requirements makes it easier to answer questions such as:

• What must be completed before the system can be used?
• What features can be postponed if time becomes limited?
• What functionality would add value but is not essential?
• What functionality is explicitly outside the scope of the project?

Must Requirements

Must requirements describe the functionality that is essential to the success of the project.

If even one Must requirement is missing, the system is incomplete.

In many cases, Must requirements define the minimum viable product (MVP) – the smallest version of the system that still solves the client’s problem.

For example:

A registered user must be able to log into the system.

A volunteer coordinator must be able to view volunteer applications.

The system must store submitted customer records.

Without these capabilities, the system would fail to satisfy its core purpose.

When resources are limited, Must requirements receive the highest categorization.

Should Requirements

Should requirements are important, but the system can still function without them.

These requirements often represent enhancements, refinements, or functionality that may be introduced in later versions.

For example:

A volunteer coordinator should be able to export volunteer information to a spreadsheet.

The system should provide email notifications when an application is submitted.

Should requirements add value, but their absence does not prevent the software from being used.

In some projects, Should requirements become future development goals once the Must requirements have been completed.

Could Requirements

Could requirements are often described as “nice-to-have” features.

These requirements may improve the user experience, increase efficiency, or provide additional convenience, but they are not critical to the success of the project.

For example:

A volunteer coordinator could customize dashboard colours.

The system could display user activity statistics.

Users could save personalized report templates.

If time, resources, or budget become constrained, Could requirements are often the first features removed from the development plan.

The Relative Importance of Requirements

The categories form a hierarchy:

1. Must
2. Should
3. Could

This hierarchy helps teams make difficult decisions when resources are limited.

If a project is running behind schedule, a team may postpone a Could requirement.

If additional time is needed, they may postpone some Should requirements.

Must requirements, however, generally remain non-negotiable.

The Most Misunderstood Category: Won’t

Students are often surprised to learn that we deliberately document functionality that the system will not include.

At first, this seems strange.

After all, the list of things a system will not do is nearly infinite.

For example, a volunteer management system probably will not:

• Make breakfast
• Predict lottery numbers
• Drive a car
• Allow time travel

Clearly, documenting these statements would not be useful.

So why do Won’t requirements exist?

Why Won’t Requirements Matter

Won’t requirements help define project boundaries.

They communicate functionality that has been intentionally excluded from the project.

This is important because clients, users, and developers often make assumptions about what a system should do.

If those assumptions are never discussed, misunderstandings can occur later.

A client may believe a feature was included.

A developer may believe it was excluded.

A Won’t requirement makes that decision explicit.

In this way, Won’t requirements help establish scope and protect both the client and the development team from misunderstandings.

Won’t Requirements Help Prevent Scope Creep

One of the most common challenges in software development is scope creep.

Scope creep occurs when additional functionality is gradually added to a project without corresponding increases in time, budget, or resources.

Individually, each request may seem small.

Collectively, they can dramatically increase the complexity of a project.

Won’t requirements help manage this risk by clearly identifying functionality that is outside the agreed-upon scope.

They establish boundaries before development begins.

What Makes a Good Won’t Requirement?

A good Won’t requirement should satisfy two conditions:

1. It should be related to the project.
2. It should describe functionality that someone might reasonably expect to exist.

For example, imagine you are developing a mobile application that identifies birds from recordings of their songs.

Which of the following Won’t requirements are useful?

Potential Won’t Requirement A

The system won’t convert bird songs into smartphone ringtones.

Potential Won’t Requirement B

The user won’t be able to map the location of identified birds.

Potential Won’t Requirement C

The user won’t be able to look up the retail value of a bird.

Potential Won’t Requirement D

The system won’t provide audio editing tools for modifying recordings.

Some of these are more useful than others.

The best Won’t requirements address features that users or clients might reasonably expect to be present.

Features that no one would ever expect are generally not worth documenting.

A Common Mistake

One of the most common mistakes students make is writing Won’t requirements that actually require development effort.

Consider the following requirement: The system won’t allow a non-administrator user to edit the settings of another user.

At first glance, this may seem like a reasonable Won’t requirement. However, implementing this behaviour requires code.

To satisfy this requirement, the system must:

• Support different user roles;
• Store permissions;
• Verify permissions when actions are performed;
• Restrict access when permissions are insufficient; and
• Provide feedback when access is denied.

In other words, significant functionality must be developed.

If you need to build it, it is not a Won’t requirement.

Rewriting the Requirement

Instead of describing functionality that prevents an action, we should describe the functionality that must exist.

For example:

The system must support multiple user permission levels.

A non-administrator user must be able to edit only their own settings.

An administrator user should be able to edit any user’s settings.

These requirements describe the functionality that must be developed and tested.

They belong in the Must or Should categories because they require implementation effort.

A Simple Rule

When deciding whether a requirement belongs in the Won’t category, ask yourself:

Would satisfying this requirement require us to write code?

If the answer is yes, it is probably not a Won’t requirement.

Won’t requirements should define what functionality is outside the scope of the project.

Must, Should, and Could requirements describe the functionality that must actually be designed, implemented, and tested.

Why This Matters

The MuSCoW Method is more than a categorization tool.

It is a communication tool.

It helps clients understand what they can expect from the final product.

It helps development teams make informed decisions when resources are limited.

And it helps establish realistic project boundaries before development begins.

Throughout CIS3750, you will use MuSCoW categorization to organize requirements, manage scope, and make design decisions.

The goal is not simply to create a list of features.

The goal is to create a shared understanding of what will be built, what might be built, and what has intentionally been left outside the scope of the project.