of the aircraft and the project, but the
presence of multiple levels of requirements and abstraction is common.
Returning for a moment to the question of what it means to be safe, a portion of that answer could be summed
up as “no surprises.” The software
should perform such that all of the requirements are fulfilled. Further, there
should be an absence of unintended function. That is, the software should do
only what is specified in the requirements: no more, no less. You do not
want to be learning about a hidden,
extra feature of the software during an
emergency at 30,000 feet.
traceability
To say that “the system should have
an absence of unintended function,”
prompts the question: unintended
by whom? As requirements are developed at lower levels, the requirements
statement must include more details
and specifics. Lower-level requirements should and must provide additional value to the implementers,
or they would just be restatements of
their parent requirements. How can
you differentiate between something
that has been added to a lower-level
requirement and something that is
just a decomposition or elaboration of
a higher-level requirement?
Managing the relationships between levels of requirements (and other project artifacts) is done through a
system called traceability. Traceability
is a mapping between requirements or
other project artifacts that provides a
navigable relationship between two or
more items. For example, a high-level
software requirement can be traced to
one or more low-level requirements.
Where such a mapping shows a decomposition and elaboration of the higher-level item (and no new behavior), no
additional safety analysis is necessary.
If a lower-level item cannot be directly
traced to a higher-level item, then the
possibility exists that this lower-level
item has introduced an unintended
function. In such a case, the lower-level
(unmapped) item should be subjected
to a safety assessment.
Traceability provides a means of
following the mappings from the
highest level of requirements down
through each level of abstraction to
the lowest level. From the lowest levels
of software requirements traceability
continues to software design artifacts,
source code, verification methods and
data, and other related artifacts. You
should be able to start with a system-
level requirement and follow each
related requirement in turn through
the traceability mapping down to the
related code and verification data.
Reviews and independence
Each requirement and other project
artifact must be subject to review, and
the review should be based on crite-
ria identified in the project planning
documents. Additionally, depending
on the criticality of the software as de-
fined by its Software Level Definition,
the review of a specific artifact might
need to be done with independence, de-
fined in DO-178B as the “separation of
responsibilities, which ensures the ac-
complishment of objective evaluation.
For software verification process activi-
ties, independence is achieved when
the verification activity is performed by
a person(s) other than the developer
of the item being verified, and a tool(s)
may be used to achieve an equivalence
to the human verification activity. For
the software quality assurance process,
independence also includes the author-
ity to ensure corrective action.”
The DO-178B guidance does not
specify how reviews must be per-
formed. Some organizations hold
meetings with several (or many) re-
viewers, collect minutes, and sign the
review as a group. Anyone who has
witnessed or participated in a group re-
view will likely attest that the efficacy of
such a review is highly dependent upon
the acumen of those doing the review
and the culture of the organization
holding the review. In short, the danger
here is that if everybody is responsible,
then nobody is responsible.
Verocel, a company that provides
software verification services, takes a
different approach to organizing re-
views. Instead of assigning groups of
engineers to a given review, it assigns
a single engineer who is solely respon-
sible for the completeness and correct-
ness of the artifact and its review. It is
not unusual for the assigned engineer
to solicit assistance from other mem-
bers of the group or even the origina-
tor of the artifact to answer questions,
provide further analysis or insights, or
obtain clarifications. In the end, how-
ever, only one signature appears on the
review checklist, and responsibility for
the quality of the artifact and its review
rests with the one person who signed.
mechanics of artifact
organization and traceability
There are practical considerations in
the organization of project artifacts and
the traceability between them. Often,
projects have hundreds or even thousands of requirements. How should
these items be managed? How can the
traceability between them be maintained? Again, DO-178B provides a set
of objectives but is silent on how these
objectives should be met. It is up to the
development team to provide details for
how each objective will be met in the
project planning documents, including
artifact organization and traceability.
The development team and the certification authority (or its representative)
must agree on these plans.
Several commercial offerings are
available for requirements management. Some organizations use word processors and spreadsheets (along with
some specific procedures) to meet these
objectives. Verocel found all of these
approaches wanting and developed its
own requirements and artifact management system with a relational database
as its backing store. This system, called
Vero Trace, manages requirements text
directly and holds references to other
artifacts such as design components,
source files, test procedures, and test results, which are maintained in the CM
(configuration management) system.
VeroTrace fulfills the navigable traceability objective. Once again, DO-178B
is not prescriptive on these matters.
A valid organizational and traceability system could conceivably be created
with little more than a stack of paper
index cards. As a practical matter, large
software development projects require
automation of some type to manage the
project artifacts, their review state, and
their associated traceability.
a Good Requirement
The DO-178B objectives for a good requirement are related to: (a) compliance
with system requirements, (b) accuracy
and consistency, (c) compatibility with
the target computer, (d) verifiability, (e)
conformance to standards, (f) traceabil-
