Roger L. Cauvin said,

December 13, 2005 at 8:21 am · Edit

Scott, I fully agree specifications directly testable in practice are important for testers and developers, and that someone on the team should formulate these specifications. Where we differ is in calling these specifications “requirements” when the underlying motivator – what I in this thread have called the “real requirement” – is something unambiguously testable in principle.

By the way, I don’t agree that “controls must be at least 10 pixels apart” is a requirement. My belief is that true user interface requirements generally specify how easy it is to accomplish functional goals, not designs or design guidelines. See “Mistake 5″ in my article, “How to Guarantee Product Failure”. The link is http://www.cauvin-inc.com/articles/ProductFailure.htm.

tynerblain said,

December 12, 2005 at 8:38 pm · Edit

Roger,

Thanks for the comment and insight. I completely agree that it is the responsibility of someone on the development team (coder or tester) to design the particular tests – or in the car example, a quality engineer.

However, part of the validation of a requirement is that it can be implemented – or it shouldn’t be a requirement. One component of validating a requirement is assessing the language of the requirement, to determine if you can unambiguously identify it as being complete. The QE needs to manage the design of the test, but as part of accepting the requirement from the requirement writer, the QE should make sure that he knows how to test it.

Collaboration and iteration are key to writing great requirements – feedback from the QE is what helps the requirement writer rewrite the requirement. And that feedback cycle is important, because the requirement writer will then have to get signoff from the stakeholders that the rewritten requirement is sufficient – perhaps they only need 80% confidence.

Also, the design engineers need to know when they’re done. Do they have to build a Yugo, or a Volvo? Without an objective criteria as an input to their design process, you can reasonably expect that they will design something you don’t want.

You make an excellent point about “losing sight of the real requirement” – I will post in depth on this topic soon. The goal (or “Goal”) is high reliability for the car, and presumably someone has done an ROI analysis that says that 7 years without breakage is more profitable than 6 or 8. This should absolutely be documented. A supporting functional requirement should include the actionable details.

Thanks again for the comments, and keep posting good stuff to your blog – I enjoy it. Oh yeah – Tyner Blain is the company – I’m Scott :)

Roger L. Cauvin said,

December 12, 2005 at 5:36 pm · Edit

Tyner, you’re quite right that you can rewrite requirements so that they are directly testable. Unfortunately, in some cases you then lose sight of the real requirement.

As I mentioned in my post, the seven year requirement is, in principle, testable. It just takes seven years to test it. It is testability in principle that ensures the requirement is clear and unambiguous. (You are right that driving habits and such would also need to be included.)

The seven year requirement is not practical to test directly, however. Thus, as you suggest, we must devise a test that is reasonably expected to simulate (or predict) what will happen in seven years. But that is the job of the tester, not the requirements analyst. For testability in practice is not what ensures a good requirement. Testability in practice is important .. er .. for testing!