The "MoSCoW Analysis" sounds as though it is straight out of a James Bond or Jason Bourne spy movie. However, it is actually a very clever mnemonic that aids in prioritizing requirements for user services and Service Management tools in the Service Design phase of the IT Service Management (ITSM) Lifecycle.
The MoSCoW Analysis very simply categorizes the requirements for a technology into four ascending categories:
The only problem is, depending on your affinity for the modal verb form of the English language, you may completely overlook the subtle differences among the Must-Should-Could-Would phrases.
This DITY decrypts the MoSCoW Analysis into a less alliterative, but more illustrative, structure to help users and ITIL practitioners easily define the requirements for the changes they are considering.
The roots of the MoSCoW analysis lie in business analysis and software development techniques that help stakeholders prioritize their requirements. Sources credit Dai Clegg of Oracle UK Consulting as the developer of the MoSCoW acronym to use in Rapid Application Development (RAD) projects.
The mix of upper- and lower-case letters serve to focus on the operative words of Must, Should, Could and Won't/Would.
The MoSCoW Analysis resides in two places in the Service Design phase, the Requirements Engineering activity and the selection of Service Management tools. To better understand how to use the tool, it is helpful to first look at these two areas.
The ITIL Service Design publication introduces the MoSCoW Analysis as it discusses the Requirements Catalog in the context of Requirements Engineering. ITIL recognizes Requirements Engineering as a structured discipline that reasonably assures an organization of a complete and accurate set of requirements.
ITIL describes a simple Requirements Catalog template consisting of four major entries.
Service Management Tools
A bit farther along in the Service Design book, ITIL emphasizes that IT should follow its own advice and document a Statement of Requirements (SoR) during the selection process for Service Management tools. It suggests using the same MoSCoW Analysis to evaluate the features of each tool under consideration.
Applying the MoSCoW Analysis
The section below applies the MoSCoW Analysis to a project to create an on-line ordering system for a mythical manufacturing and distribution company.
MUST HAVE – This is a key requirement without which the service has no value.
SHOULD HAVE – This is an important requirement that must be delivered, but if time is short, could be delayed for a future delivery. The service still has value without these features.
COULD HAVE – This requirement would be useful to have if it does not cost too much or take too long to develop, but it is not central to the service.
WON'T HAVE/WOULD LIKE (or want) TO HAVE NEXT TIME – This requirement is not needed now, but will be needed in the future, where it may be upgraded to a MUST HAVE.
No matter whether your planning is done with a sophisticated tool or on the conference room whiteboard, the need to categorize and prioritize requirements is key to an on-time, cost-effective service delivery that meets the user's requirements for creating value.
Just remember the acronym – MoSCoW.