Traceability between SSS (an acronym for a System Requirements Specification) and SRS (an acronym for a Software Requirements Specification), where the software is a part of the solution, is usually established in detailed design, and is best established by those doing the detailed design (not by someone else after the design is done). Where specification writing for subsystems (including software subsystems) is done by someone other than the designer (which is common), the designer needs to control this and take responsibility for the traceability, even if the specification writer does some of the work.
The SSDD, an acronym for System/Subsystem Design Description, describes design decisions at a conceptual level of detail of design (i.e., not fully detailed design). The SSDD does not specify system requirements, but makes reference to system requirements in explaining the design.
Whilst it is possible to formally trace a subset of SRS requirements to the content of a SSDD, it is not common to do so. This is because the SSDD is not fully detailed, and the quality of design traceability is therefore low. As well, it is expensive to trace from SRS into a SSDD. To produce a fully detailed SSDD is hugely time-consuming and therefore very expensive. As is the traceability of the requirements in the SRS and other subsystem specifications to the SSDD. So formal traceability of subsystem specifications to the SSDD is not commonly implemented.
A cost-effective means of implementing design traceability is to:
- produce an overall description of the design at a conceptual level of detail, focusing on the implementation to satisfy the system requirements that drive architecture (typically 5%-15% of the total). This is the role of an SSDD.;
- establish the direct relationships between system requirements and subsystem requirements (implementing requirements traceability between system requirements and sub-system requirements, including software requirements);
- attach to each requirement an explanation of how that requirement is met in the design. The explanation may be as little as “see child requirements”, to a link to a design artifact such as a calculation, or an Excel spread sheet, or a link to a physical and logical design database as produced by a CASE tool from designer input.
Regarding allocations of system-level requirements to subsystems for their implementation, this is covered by requirements traceability from SSS to SRS or other subsystem requirements specification(s). Allocation of a system requirement only to a software subsystem should be rare – doing so makes a statement that hardware plays no role in the solution!
Regarding allocations of solution-level functions to subsystems (including software subsystems), this is normally done in CASE tools which document the logical and physical design. In olden days where allocations were done manually in hard copy, one name for such a record was RAS (Requirements Allocation Sheet, a sheet which tabulated the allocation of solution-level sub-functions to subsystems, thereby creating a functional requirement on the subsystem).
