TDD and Meaningful Requirements

Both Craig Brown and Richard Puttick were kind enough to comment on my previous post about meaningful requirements. The post is an extension of a conversation I was a part of with Robert Martin several years ago about Test-Driven Development. The group quickly concluded that unit tests were essentially executable specifications, provided that things like boundary conditions, known negatives, etc. were also fully tested. By extension, user acceptance testing (UAT) were effectively executable requirements, provided that they were tested with the same comprehensiveness as unit tests should be conducted.

Going just one step further, it should be pretty clear that in UAT, not only can the functional expectations be specified in terms of tests and measured against the results, the operational expectations can also be specified in terms of tests and measured against results. These functional and operational expectations are nothing more than functional and technical requirements, both of which can be tested at the same time. This also leads to practice of combining functional and technical requirements into the same statement, which also aids traceability.

We have needlessly complicated our lives and increased opportunities for defect injection by separating functional and technical requirements. A demonstrated good practice, TDD, clearly illustrates how the separation of functional and technical requirements are not only a worst practice, it's not necessary at all.