by Ralph Dale-Jones
The importance of requirements to any product are quite obvious: clearly without any, there is no likelihood of a product; with only a vague set, it is unlikely the product will resemble what was intended, and with imprecise requirements, it is more than likely that the product will not work in the way that was envisaged.
Writing, managing and ensuring that requirements are mapped to the final product is not an easy task. It is particularly difficult when multiple interacting systems are involved; high level requirements must span the whole system, followed by individual system requirements which then map further down the product life-cycle to individual components.
The more time spent writing clear requirements, the more likely it is that the end product will function as it should. A popular process of developing a product from a set of requirements is the V-model, shown below, using the development of a DLNA project as an example.
On the left-hand side of the V-diagram are the requirements; on the right are the systems that test the requirements. At the highest level, work begins on the guidelines developing a feature, such as HTML-5 or Live Streaming; such requirements must span multiple devices and must not compromise existing features, an objective that becomes more and more difficult as the number of features grow.
On the V-diagram, guideline implementation is tested during certification of a device or set of devices; the documents and processes associated with certification must be updated and implemented to reflect the new guidelines.
At the next level down on the left hand side of the V-diagram is the test case specification; these are the test cases that must be implemented by the test tools in order to prove that the product implements the guideline correctly. The counterpart of the test case specification is, strangely enough, a set of tests that ensure that the test tools correctly implement the testing requirements of the specification. Finally, at the bottom level of the V-diagram is the detailed software design which maps to White box testing, such as Unit or Grey box tests.
The purpose of the V-diagram is to ensure that the requirements are mapped correctly, right through from the highest level to the lowest level; the means of enforcing this is the comprehensive set of testing on the right hand-side of the V-diagram. In the V-process an indication of a poor set of requirements is the so called out-of-phase error, which happens when an error is found which is traced to a level higher than the level of testing: for example, a guideline error found during software testing.
The amount of work involved in developing and testing requirements is not small but it will ensure traceability throughout the development and will result in a product that is more likely to resemble the one that was specified at the start of the project. The time spent on writing strong requirements and test specifications leads to considerable time and money saved in the later phases of the project. There will be fewer Guideline clarifications, code updates, side effects and especially fewer bugs.