Traceability Analysis
In general, traceability
analysis is the process of linking requirements for a system element to
other system elements (higher or lower in the hierarchy), and to the
various implementations of the requirements (design, physical
components, test procedures). For complex electronics, traceability
analysis is performed to verify that the complex electronics
requirements are correct and complete, that the design model and other
design artifacts implement those requirements, and that all
requirements are verified.
The various elements of
traceability for complex electronics are shown in the figure below. The
elements in black are the most common items traced and are suitable for
all complex electronics. The elements in blue show additional traceability analyses that may be
performed for moderate CE. The green traces are reserved for the most critical complex
electronic devices.
Traceability analysis
has multiple uses, depending on the depth of the analysis. At a
minimum, it is used to ensure that the requirements for the system
element (e.g., a complex electronic device) are correct and complete
(no missing requirements), and that the final implementation of the
system element meets those requirements.
Tracing requirements is
one of the most useful analyses that can be performed. Tracing will
help find requirements errors (e.g., missing, incomplete, wrong), which
are often the most costly and hardest errors to find. Other benefits of
tracing are:
- A good trace will allow you to easily
identify areas of the system that are impacted by changes. This
process is part of a Change Impact Analyses.
- When a change is required, the trace
will identify the parts of the complex electronics that have to be
re-tested.
- Requirements tracing can be used to
ensure complete test coverage of all requirements.
- Tracing will show where the various
requirements are implemented in the design, which can be used to
determine the testing strategy. Requirements implemented in a
single “module” may be tested at a low level (the device), whereas
requirements implemented in multiple “modules” may require a
higher level test. Requirements that are implemented across the
design are most likely very important, and should undergo
additional testing.
- Maintenance is easier, because the areas
affected by a change are clearly identified.
- The design is driven by the
requirements. Any additions or changes to the design that are not
required will be identified.
- A traceability analysis can be used to
help discover the root cause of faults or failures in the system.
Forward and Backward Tracing
Tracing comes in two
basic types:
- Forward tracing, from higher level requirements into
lower level/derived requirements, and eventually into design
(including HDL modules) and test or verification plans.
- Backward tracing from lower-level elements all the way up
to higher-level requirements.
Forward tracing is the
more common form of traceability analysis. It is used to make sure all
requirements are completely and correctly implemented in the system
element (such as the complex electronics). A forward trace can be used
to identify the down-stream elements that are affected by a change in a
higher-level parameter. For example, if a complex electronics
requirement changes, a forward trace will identify the HDL model
elements and test plans that are affected.
Backward tracing is used
to ensure that additional functionality was not added to the system
(i.e., that all system aspects are driven by the requirements). A
backward trace starts at the lower level element (e.g., the HDL model)
and traces each part up to a requirement. If some function cannot be
traced, then either it should be removed, or a requirement is missing.
Forward tracing of
requirements is the minimal implementation of Traceability Analysis.
Critical systems should perform both types of tracing. The number of
“layers” to trace through can also be varied with the complex
electronics classification. Low classification devices may only perform
a forward trace from requirements to a HDL behavioral model to test
procedures. Moderate classification devices should trace further into
the HDL model, to specific structures and internal elements. Tracing
can go even lower, into the netlist or other design representation.
Inputs to a Traceability Analysis
Generically, the inputs
to a traceability analysis are the documents describing both ends of
the trace. For example, tracing the requirements into the tests will
need the requirements document and the test plan (or plans).
Documentation from previous traceability analyses can be used as a
starting point, but remember to verify that the documents used in that
analysis have not changed.
The table below lists
the types of information necessary for various traceability analyses.
The list is not complete, but provides a good starting point. While the
information is presented as a forward trace, the same documents are
necessary for a backward trace.
|
Trace FROM
|
Trace TO
|
Documents
|
|
CE Requirements
|
Design
|
CE Requirements or
specification;
HDL model, circuit
drawings, and other design documents.
|
|
CE Requirements
|
Tests
|
CE Requirements or
specification;
Test plans and/or
procedures.
|
|
System Requirements
|
CE Requirements
|
System requirements,
safety analyses, interface specifications;
CE Requirements or
specification
|
|
Design
|
Tests
|
HDL model, circuit
drawings, and other design documents;
Test plans and/or
procedures.
|
Tracing Process
The process of
requirements, design, etc. tracing is conceptually very simple. You
start with the two documents at both ends of the trace (what you are
tracing from and what you are tracing to). For each item in the from document, you locate a
corresponding item in the to document.
This works for both a forward and backward trace, with just the from and to items reversed.
Making the connection
between items will involve a certain amount of judgment. A to item (requirement) may be
implemented across multiple locations in the from item (design). Backward
tracing can be even more difficult, as each element is mapped to one or
more higher level elements, or to a part of a higher level element.
You may be provided with
a traceability matrix by the development organization. If so, then part
of your work is done. However, you still need to verify that the
tracing is correct, complete, and sufficient. Pay particular attention
to items that trace into large portions of the complex electronics.
Either these items are very important (vital to the functionality of
the device) or the tracing was done at a very high level and is
insufficient for this analysis.
While the process
described below is manual in nature, many requirements management tools
can be used to automate the analyses. Tools reduce the effort needed to
trace requirements. However, they still require a human to determine if
a trace is valid.
Step 1: Gather
the appropriate documentation for the trace. For a CE requirement to HDL model
trace, you will need the CE requirements, the model code, and any
supporting documents.
Step 2: Prepare
a Traceability Matrix. While there are many ways to document the trace, a
Traceability Matrix is commonly used. This matrix lists the items being
traced (including a unique identifier) and the locations where they
trace to. You can combine multiple layers of tracing (e.g.,
requirements to design to test) in one matrix, but be aware that deep
traces can get complicated. A single requirement may trace to multiple
locations in the design, and each design location may trace to one or
more tests. For complicated systems, a requirements management tool or
a database may be a better way to manage the information generated. An
example Traceability Matrix is shown below.
Step 3:
Determine the from items to trace. Populate the TM with these items. Documents may have additional
information that does not need to be traced. For requirements, all shall statements, and potentially
any will or should statements, need to be
traced. For the design, the tracing can be done at the block or module
level or down to individual statements. The complexity and criticality
of the complex electronics should be used to determine what level to
trace at.
Step 4: Search
through the to documentation for the connection to each from item. This is a manual and
time-consuming process which requires judgment to determine the
connection. You can use the developer organization matrix, if one is
available, as a starting place. When making the connection (trace),
look for similar functionality, names, and wording. Examine inputs and
outputs of the complex electronics.
Step 5: Record
each trace in the Traceability Matrix.
Step 6: Identify
items that do not trace, incorrectly trace (in the developer matrix),
or do not sufficiently trace. It is a rare traceability analysis where all of the
items trace without any problems. One common problem in a
developer-provided traceability matrix is incorrect tracing. Often it
is simply a typographic error. However, it may also indicate that the
requirement is ambiguous (and therefore hard to implement correctly) or
that there is a problem in the design, test, or other artifact.
Items that do not trace
in a forward trace are considered missing
(not implemented). In a backward trace, these items are additional (not required),
sometimes called “gold plating”. Additional items identified in a
backward trace may actually be required; in which case the requirement
is what is missing.
Insufficient tracing is
often a sign of ambiguous or high-level requirements. An insufficient
trace results when you can see some
of the from item
in the to documentation,
but not all of it. For example, a requirement to send out a pulse once
a second may trace to a pulse generation module, but the timing factors
may not be implemented (or may not be obvious).
Step 7: Resolve
any tracing issues. Any issues, problems, or questions generated by the
traceability analysis should be resolved. If the issue is the result of
a misunderstanding, consider whether any documentation (or requirement)
should be updated to prevent future misunderstandings. If there is an
error, use the project-specific mechanism to initiate corrective
action. Document the resolution of the issues and questions along with
the traceability analysis.
Example Traceability Matrix
|
ID
|
Requirement
|
Model (design)
|
Low-Level Verification
|
Requirement
Verification
|
|
R123
|
CE shall output a 5
volt pulse every second.
|
pulse.vhd, lines
33-87; power.vhd, lines 93-111
|
Test P1, steps 3-6
|
Test Device, section
3.2, steps 5-11
|
|
R124
|
The pulse shall be of
100 nanoseconds duration, +/- 5%
|
pulse.vhd, lines 55-66
|
Test P1, step 5
|
Test Device, section
3.2, steps 9-10
|
Outputs from a Traceability Analysis
The primary output is
the Traceability Matrix (if used) or other representation showing the from and to traces. A report should
accompany the Matrix that includes:
- Documents used in the tracing.
- Tracing methodology
- Issues found (e.g., missing or
additional traces, insufficient traces), along with the issue
resolution (if known).
|
