Using MoSCoW As A Requirement Category Type

©2015 Dwayne Wright

If you haven't stumbled across this acronym before, MoSCoW stands for Must, Should, Could and Won't. This is one of those techniques that someone reads about and immediately wants to use it in their work product. The most common occurrence of its use that I've come across is when a group is prioritizing brain storming content. However, it an be used in a variety of ways with mixed results.

One time, I ran across MoSCoW being used in a Business Requirements Document (BRD) and I noticed something odd when I was transposing this data into a Requirements Traceability Matrix (RTM). It involved instances where the MoSCoW category conflicted with the main verb of the requirement.  

The main verb in a requirement is generally "must" or "shall" and it is very hard to know the distinction between the two if the business analyst mixes them in the same requirement document. If there isn't a distinction, then the business analyst should use one of them and stop using the other. This brings up a key point that many business analyst miss when crafting requirement documentation. 

I have seen a business analyst mix main verbs because they didn't want to overuse one. If all the requirements say "must", they feel they should substitute it occasionally for "shall", "needs to", "will", "would", "should" or other creative derivative. You don't interject different main verbs for your requirements in an attempt to mitigate boredom in the reader. If the audience of the requirements is NOT a business analyst, developer or tester, they are probably going to be bored reading a bunch of requirements anyway. 

Mixing different verbs opens up conflict such as ...
This requirement says "must" and this one says "shall", so the "shall" is more of a desire and not a requirement. If the item in question is a desire, it should not be listed among requirements.

Earlier in this discussion, I mentioned a situation where I became cognizant about the potential of a main verb and MoSCoW conflict. In this situation, I was building a RTM from BRD content. This BRD was created by a previous BA and they had limited requirement documentation experience. As I copied each requirement from the PDF into the Excel document, I noticed about 25% of 200+ requirements in the BRD didn't fall into the “Must” category of the MoSCoW type. In fact, about 5% of the requirements fell into the “Won’t” category.  

Although the RTM quickly became the primary resource for requirements, the BRD would still be a point of reference from time to time. When this happened, the primary reason was because of a perceived unfulfilled requirement. The discussion would go something like ...

STAKEHOLDER: Why is requirement XYZ not represented in the RTM, Design Document, Testing Plan or another document?
BA: Because it states in the BRD that it has a MoSCoW category as a W.
STAKEHOLDER: What does that mean?
BA: The W means we won't be doing it, (then the BA describes MoSCoW to the stakeholder).
STAKEHOLDER: Why was it classified as something we won't do?
BA: (answer varied because the BA may not know)
STAKEHOLDER: (often regardless of the BA response) I think we need to talk about this. 
BA: The requirements in the BRD are baselined and locked, so any change will need to go through the change control process.
STAKEHOLDER: We have to go through the change control process in order to discuss it?
BA: Well no ... (response varies)

The above discussion happened repeatedly, sometimes with the same stakeholder on the same requirement. This could have been avoided and was a constant drag on the project.

I think that using MoSCoW as a requirement category can have strong value. If used improperly, it can also become a big distraction. Obviously, there is NEVER a situation where a "must have" requirement lies within requirements documentation, if you know you are NOT going to do it. Make sure that your action verb is the correct one to use in the situation in which you are using it.