When you first sit down with a client or user to talk to them about the system that they want you to design, you will often hear them discuss system functionality prefaced by phrases such as:

• “it absolutely has to…”,
• “it would be really good if…”, or
• “it would be nice if…”

Your job is to capture the functionality mentioned and to classify each thing the system is to do based on how important it seems to be to the client. Ultimately, the goal is to use this list to provide you and your client a clear understanding of what should be expected in the final product.

The MUSCOW Method

With the flexibility of the English language, there are many ways that a client or user can let you know that a particular piece of functionality is important. To simplify our work and eliminate the many labels that could be used to qualify the importance of a requirement, we use the MUSCOW method of categorizing.

The MUSCOW method, which stands for Musts, Shoulds, Coulds, and Won’ts, is a way for us to categorize our requirements so that we broadly know what needs to be developed first.

• Must requirements (or musts) are necessary to develop a minimum viable product for the client. If even one of the musts is incomplete, the product would be considered unfinished and not ready for use by the client or user. Must requirements typically describe the first version of the software being developed.
• Should requirements (or shoulds) are important to the system, but not necessary for version one. Shoulds might also describe things that are phased in over time. For example, you may opt to phase in levels of AODA compliance by describing the following requirements:
  • The system must meet AODA level A compliance by January 1, 2014.
  • The system must meet AODA level AA compliance by January 1, 2021.
  • The system should meet AODA level AA compliance by January 1, 2018.
• Could requirements (or coulds) are “nice to have”. These requirements won’t make or break the software; however, their presence will likely add something valuable to the user experience or the system design.
• Won’t requirements (or won’ts) are requirements that describe things that the system won’t do.

Won’t Requirements

Initially, it might seem odd that we must identify what the system won’t do. This is especially true because our list would be infinitely long if we sat down and enumerated everything our system wouldn’t do. Our software likely won’t make breakfast, do our homework, pick up our groceries, or allow us to travel through time.

So why do we describe what our system won’t do? And what qualifies as a good set of won’ts? Further, how do we determine them?

First and foremost, describing what our system won’t do is important because it puts a boundary or set of limitations on what we are doing. This helps protect us from having a client come back to us after we’ve seemingly completed the work to insist that we add functionality we’ve never agreed to. It sets expectations of what the system will and won’t do.

Beyond that, won’ts help us prevent scope creep.

When you create your list of won’ts, you should consider them in context to the project you are working on. Is the content of the won’t requirement related to the project at all? Is it reasonable to think that someone might assume that the won’t would be a necessary component of the final software?

For example, if you were developing a mobile app to allow users to identify birds based on a quick recording of their song, which of the following won’ts are likely not necessary?

• The system won’t be able to convert a recording of a bird into a ringtone.
• The user won’t be able to map the location of the bird.
• The user won’t be able to look up the retail value of the bird.
• The system won’t allow you to edit/resample the song using standard sound mixing tools.

Finally, be careful how you draft your requirements. It can be easy to draft a requirement as a won’t, when it could be redrafted as a must, should, or could. Consider the following example of a bad won’t requirement:

• The system won’t allow a non-administrator user to edit the settings of another user.

Why is this a bad requirement?

To achieve this requirement, you need to develop code. You will have to put work into writing and testing the software. This likely would include building structures to support a set of typical users (in this case, non-administrators and presumably administrators), each with their own unique set of permissions. You will likely also need to develop code that will check the permissions whenever any user attempts to do something (such as change another user’s settings) to determine if they can do it. This would also require a method of providing feedback to the user if they attempt to do this or something else they shouldn’t.

Bottom line; if your won’t requirement leads to developing code, then it’s not a “won’t” requirement and should be redrafted as a must, should, or could.

In this particular case, we could replace “The system won’t allow a non-administrator user to edit the settings of another user” with:

• The system must include different permission levels to manage the types of users.
• A non-administrator user must be able to edit only their settings.
• An administrator user should be able to edit any user settings.

Review Questions