WHAT IS THE MOSCOW METHOD?
The MoSCoW method is a technique that helps categorize and prioritize all requirements that define a “future state”, that should be implemented.
The method was developed by Dai Clegg in 1994, and dedicated to supporting software development projects (where the “future state” is the shape of an application that should be implemented). Despite the origin, the method is not only limited to software projects, and can include requirements necessary when implementing changes to physical products (cars, buildings, furniture) or organizational changes (eg. changes to the bonus systems, changes to the partnership agreement, etc.).
Although this is a generic method, it is mainly used when implementing software systems and helps companies define the requested configuration of a future application that is planned to be implemented.
THE MOSCOW NAME EXPLAINED
The MoSCoW term is an acronym inherited from the statuses used in this method to prioritize requirements: Must have, Should have, Could have and Won’t have.
PRIORITIES USED IN THE MOSCOW METHODOLOGY
The priorities used in the MoSCoW method sound self-descriptive, but in practice, they need some additional explanation to use them properly and in a consistent way:
- Must Have (MUST) – This is the most obvious priority that represents the critical requirements that must be delivered from day one. The software without these requirements simply can’t be used properly and the project goals will not be achieved without them.
- Should Have (SHOULD) – This priority represents the requirements that are almost as important as “Must haves”, but users can live without them. Although it sounds similar to “Could have”, they are closer to “Must haves”. The difference is, that while “Must haves” have to be implemented from day one (software can’t exist without it), software users can live without “Should haves” for some time. The “Should haves” have to be ultimately implemented, but the company can live without it and still benefit from the 1st version of the software solution; these missing requirements will not cause critical security problems or will not bring a lot of additional work – if that happens, it means that they should be classified as “Must haves”. The “Should have” priority is often used to divide a complex project scope into phases, where only “Must haves” are implemented in the current phase, and “Should haves” are planned for the next phases. Sometimes, companies use “Should have” to address the “readiness” for future requirements or improvements (e.g. currently the software is not implemented in the cloud, but it must use the technology that is ready for future cloud deployment).
- Could Have (COULD) – This is used to address all the “nice to have” features, that will have a positive impact on the final solution (and then on users’ satisfaction/efficiency), but are not necessary and might never be implemented. Their business value is smaller than “Should haves”. These requirements are useful when comparing software from various software vendors – assuming, that all “Must have” and “Should have” requirements must be identically fulfilled by all short-listed applications, “Could haves” help differentiate these applications and choose the one that offers the most additional features, that will make the use of application more beneficiary for the company.
- Won’t have (WON’T) – At first glance, this priority looks unnecessary: Why do we collect and put into evidence the requirements that we don’t want to implement?… In fact, normally when we build a “Requirements table” we don’t include them and this is the correct approach. But there are at least 2 situations, where “Won’t” might be useful. First – imagine that you build the “Requirements table” based on the generic template or you copy it from another project. Your first task will be to review the template and eliminate those requirements that are not applicable in your limited case. And here the “Won’t” status might help, so other people would know, that you deliberately removed the requirement from the current scope. The other case is very pragmatic. In the real world, there is no one person who prepares system requirements, but many stakeholders are involved in this process. All of them might have their own requirements, sometimes these requirements represent very particular interests or they are not well evaluated in terms of the “value to money” factor. These requirements will be eliminated from the solution scope, but instead of deleting them from the requirements table, you should use “Won’t” priority to communicate the classification to the requirement requestor.
Note: You can find simplified MoSCoW method implementations, where priority names are only limited to the first words: Must, Should, Could, and Won’t.
WHAT REQUIREMENTS SHOULD BE INCLUDED IN THE REQUIREMENTS TABLE?
The understanding of requirement priorities is obviously not enough to prepare a good “Requirements table” for a planned software solution. When we think about that, we usually think about functional requirements (like “Ability to import bank account balance from the financial system”). But the complete list of requirements can’t be limited to that. Below we shortly present the categories of requirements that define the future configuration of the software:
- Functional requirements – business functions/operations supported by the system (e.g. “User can divide customer order line into sub-lines”). When you gather it, don’t forget about the reports offered by the system, automated routines that should run in the background without user interactions or documents that should be printed or imported.
- Common capabilities – generic features that should be offered by the system and could support many operations for many users (e.g. “All lists and tables presented in the user interface should be sortable by any column”)
- Non-functional requirements – these are also important for business people, but these are not functional requirements that can be easily converted to what is visible on the user interface. Here you can collect requirements like: the ability to configure the solution, flexibility in future development, expected performance (speed) etc.
- Integration requirements – this group defines all the necessary integrations supported by the software. This is not only a technical category interesting for the IT department (data exchange protocols that should be implemented), but also very important for people representing business departments – it is important to express what data should be synchronized with other systems (“from” and “to”) and define the exchange frequency. This exercise should be done for internal systems and potentially for external systems (owned by customers, suppliers, or cloud service providers)
- Technical requirements – this category defines elements like implementation technology or IT architecture compatibility (e.g. when the company is addicted to Microsoft or Oracle technologies), but it can also define
- IT administration requirements – this category belongs to the IT department and covers requirements like installation & configuration, upgrades management, user management, system data supervision, backups a
