In software development, we use requirements to state what must (or must not) be a part of the outcome of a project. We also use requirements to define the purpose of testing (e.g. “what is it that you expect to accomplish by testing”). Requirements show up in all the major development frameworks, albeit sometimes wearing different names (VSTS uses “Product Backlog Items” for Scrum, “User Stories” for Agile, and “Requirements” for CMMI).
However, consequences are rarely listed as part of the documentation in any of the models I have seen. I’m not sure why this is the case, but I can venture a couple of guesses: 1) The word “consequences” has a negative connotation that creates friction amongst teams. 2) Adding consequences makes it clear that someone will be held accountable for a failure to meet requirements. Lots of people avoid accountability when they can.
I have always preached that “A requirement without a consequence is just a desire.” For proof, simply consult the dictionary:
- Requirement: “a thing demanded or obligatory; a need or necessity”
- Desire: “a strong feeling of wanting to have something or wishing for something to happen”
- Consequence: “the effect, result, or outcome of something occurring earlier; an act or instance of following something as an effect, result, or outcome.”
In other words, if your requirements are a necessity and not just something you wish for, you’d better incorporate consequences into them.
The phrase “a requirement without a consequence is just a desire” is simple, straight-forward and should be common sense to anyone in the IT and/or DevOps industries. However, I am still shocked at how many companies and dev shops fail to incorporate consequences for failure into their requirements.
I believe that the culture changes in DevOps needed to allow proper use of requirements and consequences must start at the top. CIOs and CTOs don’t need to get directly involved in the development processes in order to send a clear message: teams must manage development impartially, communicate to everyone what they can (and cannot do), define the rewards they will get for proper work and, importantly, establish the penalties for improper work.
External agencies and consultants tend to manage these boundaries better than internal teams. Third parties take a painstaking approach to defining requirements and managing changes to them because the labor they employ is a variable cost vs. internal teams who are fixed cost employees. Also, it’s more likely for a business to extract penalties for failed projects from consultants because that’s politically easier than holding internal resources accountable.
No one wins when a development or testing project fails. However, building a process where no one can lose removes accountability and greatly increases the odds of failure. Requirements with no consequences are no requirements at all. Be sure to specify the consequences of failure when you develop your requirements and you will greatly improve the odds of a successful project.
(Thanks to Ian Heller for his editing skills on this post)
Testing the Testing Strategy 