It surprises me to hear staunch agile followers still using the word “requirement”. When questioned, they will respond, “…a story is a requirement.” It isn’t. Early in my reading of agile I came across this analysis of the word “requirements”:
“Software development has been steered wrong by the word “requirement”, defined in the dictionary as “something mandatory or obligatory.” The word carries a connotation of absolutism and permanence, inhibitors to embracing change. And the word “requirements” is just plain wrong. Out of one thousand pages of “requirements”, if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80%? Not “requirements”; they weren’t really mandatory or obligatory.”
(I am leaving out the reference to this quote so there is no bias. If you don’t recognize the quote or the style of writing it is worth your time trying to find the source.)
In agile, instead of requirements you have user stories. It takes quite some time to make the transition from requirements to stories. To me, after reading the previous quote, Mike Cohn’s statement about stories was essential: “A story is a reminder to have a conversation.” Of course it is difficult to create stories. Mike Cohn has written a book about that.
Alas, “requirements” are even more entrenched in the software testing world. Interestingly, in 1999, a great tester wrote a wonderful article about requirements. In that he wrote:
There are at least four alleged truisms about testing a product against requirements. Most of the testing textbooks on my bookshelf promote these principles, and each principle reflects some truth about the dynamics of testing.
- Without stated requirements, no testing is possible.
- A software product must satisfy its stated requirements.
- All test cases should be traceable to one or more stated requirements, and vice versa.
- Requirements must be stated in testable terms.
When we think in terms of risk, however, I believe a richer set of ideas emerges.
(I am again leaving out the source to avoid bias. You can easily search for the pdf article. )
If you haven’t realized it by now, keep in mind there are no “requirements” in waterfall!!
In the “waterfall” world (pre-agile), there has been some good work on “requirements”. Making the transition from that world to a world with “user stories” leaves many questions open. I still believe, with a good agile coach, and a good testing coach, teams are better off making that transition. However, writing stories and trying to determine what might go wrong can require a lot of work.