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