Test Driven Development (TDD) turns the process of writing code and designing systems around, having developers create an automated test or tests before making any changes to the system at all. If the system then fails the test, the developer makes only the changes necessary for it to pass the test, including possibly refactoring the code or addressing the design if necessary. Then the developer reruns the test.
There are many benefits to this practice. First, it encourages lean development, where only the code needed to pass the tests is written. It also encourages developing smaller pieces at a time, rather than trying to solve everything in one go. The methodology also demands the use of automated testing, which ensures that testing will be done more consistently and more completely and development metrics such as defect rates and churn can also be collected more readily.
There are also intangible benefits to this approach. Writing an automated test drives out ambiguity, and makes you think about the problem in discrete pieces. In the process of defining the test criteria, you will uncover questions and elements that may not have been apparent when you first read the requirement. The one drawback to this technique is that it almost always requires additional involvement from the customer. Requirements are rarely written at this level of detail.
Why am I discussing TDD in a requirements management blog post? While TDD is a technique for developers, it can be very valuable for requirements analysis. At this level of abstraction, it is sometimes referred to as ATDD, Acceptance Test Driven Development. Before writing a requirement statement, the analyst reviews the contextual information gathered from the stakeholders and defines the acceptance test or tests that the system must pass to satisfy the requirement. Review these acceptance test criteria with your stakeholders, and then write the requirement statement.
If you’re looking for a way to write more concise and more valuable requirements, this is an excellent technique even if analysts in your organization do not participate in quality assurance or user acceptance directly. In maintenance or improvement projects, this can be used as the first step in taking business requirements into design, as you will find yourself describing the input and the expected output. Be wary of using system specific terminology, such as ‘pop-up window’ or screen names. You shouldn’t be telling the development team how to implement the solution. Also, it’s important to note that not all business requirements can be translated easily into acceptance test criteria. Quality attributes such as Useability or Maintainability are often difficult to describe as an acceptance test for example.