Requirement Quality

MoSCoW Technique And The Requirements Walkthrough

If you have studied project management or business analysis, you have likely heard of the MoSCoW technique. It is a classification method used primarily for prioritization or scope management. The idea is to rate the item under scrutiny (like a requirement), the breakdown is as follows: 

M (must have)
S (should have)
C (could have)
W (won't have).

I’ve seen analysts send out requirement lists, ask users to provide ratings and then send the list back to the analyst. Although this can work to help define requirements, there is a significant missed opportunity in that approach.

A requirements walkthrough (sometimes called a structured walkthrough) is a formal meeting where key stakeholders evaluate each requirement one at a time and make a determination about the requirement. Although it has its roots in validation, it is more of a method to facilitate a strong shared understanding of each requirement. 

The MoSCoW technique and requirement walkthrough are a nice combination and can greatly enhance requirement packages regardless if you use a RTM, user stories, KPIs or even a specification list. When one stakeholder classifies a requirement at either extreme (M or W), another stakeholder in the meeting may challenge that classification. What happens next is the most valuable aspect, they talk about it openly where other stakeholders can hear it. Even if both stakeholders never agree, the shared perspectives are now out in the open and can be addressed as needed. 

The combination of MoSCoW and requirement walkthroughs offer more value that a traditional "thumbs up" or "thumbs down" evaluation of requirements. It greatly reduces the chance that someone will "rubber stamp" requirements due to disinterest, political pressure or misconceptions about the requirement itself.

© 2016 Dwayne Wright

Bad Requirement: It Must Be Good

One clear example of a bad software development requirement is the appearance of the word "good" within it. It will generally appear in the format of "the ____ must have a good ____". What is good vs. what is bad? Is coffee good for you? Does coffee make you smarter? How much intake of coffee is good, how much is bad and what is the relative impact between? How much coffee is enough to reach the threshold of good results?

In many cases, saying something should be good is an over simplification and doesn't provide enough granularity to be actionable by the individual that depends on the requirement to guide development. How about the age old debate between "good vs. evil". If you are a good dancer, does that also make you evil if a person believes that dancing is a sin? What about if you are alone and occasionally dance in the dark like the classic Bruce Springsteen song?

The point is that software developers and testers will have a difficult time making sure that a software deliverable meets a requirement that focuses upon being "good". The best they can do is make a subjective evaluation that if it appears to be "bad", then it likely would fail to be "good". 

EXAMPLE: The note taking portion of the application must be good in order to facilitate a proper determination on the outcome of the recorded case. 

In the above example, I would go directly to the source of the requirement and ask some clarifying questions about the note taking needs for recorded cases. This would involve both the ability to create notes and the ability to reference them when needed. Taking this forward, then we might be looking at some requirement refinement such as noted below. 

  • The user shall have the ability to log and view notes alongside case records.
  • The user shall have the ability to log and view notes in a separate window to the case being examined.
  • The users notes shall always be directly attached to the case being viewed when the note was created.
  • The system shall display a visual indication to the user if the case has attached notes.

All of the above requirements can be tested both from a functional and a usability perspective. When validating these requirements, the BA can ask the requirement source of there are any other characteristics they would associate with a "good" note taking experience for logged cases. 

© 2016 Dwayne Wright