1 August 2005
Traceability on test systems
By Filipe Altoe
As test systems grow in size, the development of a complete system requirement document takes on prime importance. A complete system requirements document is one that is free of ambiguities, describes all system functionality, and has requirements you can identify and test during the acceptance phase of the project life cycle.
Once you compile a system requirement document, one of the biggest challenges imposed upon the project team is to make sure it accounts for every requirement during the system architecture, implementation, and testing phases of the project lifecycle. That is the exact void filled by the traceability technique.
A user should apply traceability on all phases of any test system. It carries different names that match each one of the phases:
- Traceability on software requirements
- Traceability on hardware requirements
- Traceability on hardware design document
- Traceability on software design document
- Traceability on code modules
- Traceability on unit test plans
- Traceability on system test plans
Software, hardware requirements
The system requirements document details all requirements with which the system must comply. It is extremely useful to break those requirements down into a subset of documents, which different teams will execute upon. One of those is the software requirements document. This document must contain all requirements the system software will implement.
Similarly, a document containing all requirements of the hardware subsystems will go to the hardware experts who will execute such subsystem. The combination of the software and hardware requirements documents must provide coverage for every single requirement of the original system requirement document.
Design phase
Once you define these requirements, design documents will show how to implement the system. Usually, large test systems require a hardware design document and a software design document. Each one of the documents must have traceability to the software and hardware requirements documents to ensure you can account for the document requirements in the hardware and software architecture.
Traceability on that level guarantees no system feature stays out during the design phase. The later in the project lifecycle you find a lack of functionality, the more difficult and expensive it becomes to include that functionality in the system. It is extremely "cost-ineffective" to design software or hardware systems without traceability to their correspondent requirements that guarantee complete requirements coverage.
Once you design the software, you can then implement modules. Documents given to the software developers need to include all the requirements from the software requirement document the module will implement. That will help developers get a tangible set of functions the module must execute.
Unit, system test plans
Once developers code their modules, they need some sort of test routine to ensure their modules work. The most effective way to develop the test routine is to write tests for the module and make them traceable to the code module requirements. Traceability on unit test plans will guarantee you are testing every single requirement for the module.
You can apply the same methodology for the entire system. Test routines for the completed integrated system must work as the acceptance test for the system. Such test routines must provide complete coverage for each and every requirement of the system requirements document. Applying traceability to the system test plan will ensure you accomplish such coverage.
The different types of traceability can ensure complete traceability of all requirements from the system requirements document throughout the entire project life cycle. This practice reduces the risk of high cost fixes due to functionality missed during the system design and provides a high confidence level the delivered test system will implement exactly what has been defined by its complete set of requirements.
Behind the byline
Filipe Altoe is an engineering team leader at the Minneapolis office of VI Engineering, Inc., headquartered in Detroit. VI Engineering is a registered member of Control and Information System Integrators Association (CSIA). His e-mail is faltoe@viengineering.com.
Return to Previous Page
Read questions answered by our experts or join the email list.

