We generally accept (and expect) that requirements will be vague. It is a reality of the business. However true this is, it is also true that poor and unclear requirements can and must be avoided!

There are many reasons for poor and unclear requirements. The major reason is that concepts are often hard to express and are easily misinterpreted. Besides not being clear they are also often incomplete. Attempting to document requirements with more and more descriptions eventually leads to a tome which, as Winston Churchill quipped, “…by its very length, defends itself against the risk of being read!”

One effective approach to solving this problem is to express requirements in a manner that describes what is needed by an example. This is the basis for Specification by Example. The problem is, just having examples of what is wanted is not good enough because we need to make sure there is clarity of the entire requirement, not just a few examples of it.

The “Given-When-Then” (GWT) method provides a way to validate the requirement with a clear description of the behavior required.

The key is to remember that each person in a conversation has a different perspective. This is especially true when people have different roles, different backgrounds.

For example, think about being given a requirement where the customer proxy says they need “X” and the developer asks, “Is that always the case?” and the customer says, “Yes.” I learned a long time ago that this wasn’t always the case so I added, “Are you sure?” but would always get “Yes!” So that didn’t seem very effective. Invariably some other case would show up.

When I shared this example with a fellow consultant, she noted that her teenage son had pointed out, “When you say ‘always’, you mean always will be, but when the customer says ‘always’, they mean always has been.”

What a great insight!

Watch this video

This video is an excerpt of a longer talk on test-first and Lean-Agile. It focuses on Acceptance Test-Driven Development (ATDD) and the value of a test-first mindset in clarifying requirements.