Context: "Traceability is one of the basic tenets of all software safety standards and a key prerequisite for certification of software. Despite this, the safety-critical software industry is still suffering from a chronic lack of guidelines on traceability. An acute traceability problem that we have identified through observing software safety certification processes has to do with the link between safety requirements and software design. In the current state of practice, this link often lacks sufficient detail to support the systematic inspections conducted by the certifiers of the software safety documentation. As a result, the suppliers often have to remedy the traceability gaps after the fact which can be very expensive and the outcome often is far from satisfactory. Objective: The objective of this article is developing a framework to enable systematic and efficient software design inspections during safety certification. In particular, the framework enables safety engineers and certifiers to extract design slices (model fragments) that filter out irrelevant details but keep enough context information for the slices to be easy to inspect and understand. This helps reduce cognitive load and thus makes it less likely that serious safety issues would be overlooked. Method: Our framework is grounded on SysML which is rapidly becoming the notation of choice for developing safety-critical systems. The framework includes a traceability information model, a methodology to establish traceability, and mechanisms to use traceability for extracting slices of models relevant to a particular safety requirement. The framework is implemented in a tool, named SafeSlice, that supports establishing the traceability links envisaged by the methodology, automated consistency checking of these links, and automated generation of SysML design slices. Results: We provide a formal proof that our slicing algorithm is sound for temporal safety properties, and argue about the completeness of the slices based on our practical experience. We report on the lessons learned from applying our approach to two case studies, one benchmark case and one industrial case. Both case studies indicate that our approach offers benefits by substantially reducing the amount of information that needs to be inspected in order to ensure that a given safety requirement is met by the design."
The paper gives detailed analysis of the theory of traceability, worth your time to read, to find out why you should care about traceability. The one major downfall in my view is that the automation tool they present only works on Windows. Leaving those of us that prefer to do development on Linux and other platforms out in the cold.
To prevent vendor lock-in extortion I always prefer to use Open Source software where it makes sense. Traceability is one area where there is almost no applications at all that support this problem domain. The Web PHP based project TRUC - Tracking Requirements & Use Cases, is the only one that I know. Leave a comment on the ones that you know about.
A simplistic introduction to how to do traceability can be found at eHow How to Create a Requirements Traceability Matrix. Linda Westfall offers up a in more depth introduction Bidirectional Requirements Traceability . How well do you think you will do on Lind's Certified Software Quality Engineering Quiz?
Tom and Kai Gilb explain why bad or non-existent requirements are the root of failed projects, with emphasis on traceability. They have a large number of papers related to the subject, and subjects such as software quality, available for download. The manuscript for the book Evo - Evolutionary Project Management is also available for download.
When it comes to documentation I always like to look to NASA for inspiration, for example the NASA Safety and Mission Assurance Documentation Status Tree Policy, Plans and Documents section and the NASA Software Assurance section, all part of the Office of Safety and Mission Assurance (OSMA).
One paper from the NASA sites above worth pointing out is NASA Complex Electronics Guidebook for Assurance Professionals. One of the things that it wants to accomplish is to stop organizations that were implementing software functions in FPGAs and ASICs to avoid the need to follow the software assurance/safety standards for:
- Field Programmable Gate Arrays (FPGA)
- Complex Programmable Logic Device (CPLD)
- System-on-chip (SoC)
- Blurring the hardware/software line
It is also an excellent management introduction to those topics, if you are still trying to convince your boss to starting using some modern technologies like FPGA's.