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:

• M – MUST have this
• S – SHOULD have this if at all possible
• C – COULD have this if at all possible
• W – WON'T have this time but WOULD like in the future

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.

Requirements Catalog
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.

• Requirement ID – Tracks the requirement through design, development and implementation activities.
• Source – Identifies the business area or user who requested the requirement, particularly helpful as time goes by and the inevitable questions arise about the relevance or interpretation of a requirement.
• Owner – Identifies the requirements "owner" who will be responsible for ensuring the correct documentation of the requirement and for signing off on its acceptance testing.
• Priority – Prioritizes requirements to balance their attributes, such as cost, time to develop, payback, risk, etc. Failure to prioritize them can result in a design that is over-budget, late – and ineffectual.
  
  A MoSCoW Analysis provides a simple way for users to prioritize their service requirements.

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.

• Web site hosting services
• Ability to securely accept credit card transactions
• Online shopping cart
• Customer database accessible to customer service representatives
• Customer service support during U.S. business hours
• Technical support (full support during U.S. business hours; skeleton support other times)
• Interfaces to inventory control and shipping systems
• Performance monitoring and reporting

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.

• Ability to accept other forms of payment than standard credit cards
• Integration of customer database into Service Desk system
• 7 x 24 customer service support
• 7 x 24 full technical support
• Customer coupons for special discounts
• Load balancing during busy times

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.

• Cross-sell capability
• Customer database marketing reporting

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.

• "Live Chat" customer service capability
• Proactive customer contact related to warranty issues
• Ability for authorized business users to update product information without IT assistance
• Ability for authorized business users to create discount coupons without IT assistance
• Customer product reviews on website

Summary

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.