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 that is 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 as a means of providing both you and your client with a clear understanding of what should be expected in the final product.

The MUSCOW Method

With the flexibility of the English language, there are clearly 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 particular 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 those requirements that are absolutely necessary to develop a minimum viable product for the client. If even one of the musts is not complete, the product would be considered unfinished and not ready for use by the client or user. Musts typically describe the first version of the software that you are trying to develop.
• Should requirements (or shoulds) are requirements that are important to the system, but not necessary for the release of the first version. Shoulds might also describe a sort of phasing in of something. 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.
  • They system should meet AODA level AA compliance by January 1, 2018.
• Could requirements (or coulds) are requirements that are nice to have. That is, the successful implementation of 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 a bit odd that we need to identify the things that are system won’t do. This is especially true because our list would be infinitely long if we really sat down and enumerated everything that our system won’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, it is important to describe what our system won’t do 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 that we’ve never agreed to do. It also provides the client with a complete set of 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 simply 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 actually need to develop code. That is, you will have to put work into writing and testing the software. This likely would include developing the 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 are allowed to do it. Clearly, this would also require a method of providing feedback to the user in the event that they attempt to do this or something else they shouldn’t.

Bottom line; if your won’t requirement leads to the development of 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 possibly 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 different types of users.
• A non-administrator user must be able to edit only their own settings.
• An administrator user should be able to edit any user settings.

Review Questions