I’m currently working on “Product assistance” for an aircraft constructor and my usual tasks are Requirements writing or update.
However, the specifications that I write are not used directly by the developers’ team. On the contrary, these high level specifications are translated into a technical requirement specification which is used by the developers’ team.
For any system, the process might be divided into multiple layers and each layer might write its own specification.
The business team writes a very high level specification. The Product team writes a high level specification with some details about the final system, but without any specificity about the implementation. While the Project team writes a detailed technical specification.
Of course, all these specifications are inter-related.
In a usual "Test Driven Requirement" (TDR) approach we should create the tests at the same time that we write the specification. Moreover, the tests are used to better understand and to better explain the requirements.
In this TDR approach we might use a tabular form in order to describe the tests. Then, it should be possible to write a fixture (code) that would execute the test on the System Under Test (SUT). This is the process described by Fitnesse or GreenPepper, for example.
The problem here is that a specification created by the Business team is very far from the SUT; then it is not possible to write any fixture.
The fixture is suitable for specifications that are going to be developed directly, without any other intermediary level.
If we consider TDR as only writing tests to clarify, improve and complete the requirement specification; then it is possible to use it at any level of abstraction. However, we loose all the advantages about test reusability, non-regression, continuous validation, completion measurement, etc. that a tool such as Fitnesse or GreePepper would provide.
Indeed, TDR shows all its power when working on a specification that is going to be used directly by the development team.
D. GARDUNO
Posts
