Requirements Review
Once the
requirements for the complex electronic device are defined, they need
to be reviewed by a variety of people. Each person will bring a
viewpoint to the review that will identify gaps or errors in the requirements
set. At a minimum, the requirements should be reviewed by the following
personnel. Some of the roles in the list may be met by a single person,
or a role may be shared by multiple people.
- An engineer
knowledgeable about the system and planned operations
- An engineer
knowledgeable about complex electronics*
- An assurance person
knowledgeable about the system and complex electronics
- A system safety
engineer, for complex electronics that are part of, or interact
with, a safety-related system element.
*If the
requirements were written by the engineer who will design the complex
electronics, another engineer familiar with the hardware and design
issues should be a reviewer, to provide an independent point of view
and an additional set of eyes to the review.
The
requirements review can be a formal review (such as part of the
Preliminary Design Review), an informal review, or the result of many
individual reviews. Regardless of the method chosen, the results should
be documented and the requirements should go through a revision cycle
if changes are necessary. Any safety-related requirements, or those
that impact higher-level requirements, need to be assessed by the
appropriate personnel. Sometimes, the review of lower-level
requirements will expose gaps in the set of higher-level requirements.
Those gaps need to be assessed, and new requirements added, by the
systems engineering team.
The Requirements
Review checklist can be used as an aid when reviewing the Complex
Electronics requirements. The results of the feasibility assessment
should also be included in any review package (i.e. the set of
documents that will be reviewed). The review package will include some
or all of these documents:
- Complex Electronics
Requirements Specification
- System specification
(Requirements)
- Sub-system
specifications (requirements) for all sub-systems that the complex
electronics interacts with
- Interface specifications
or control documents
- Operations concepts
- Preliminary Hazard
Analysis
- Failure Modes and
Effects Analysis
- Fault Tree Analysis (if
the complex electronics is a possible cause of or contributor to a
failure)
The requirements
document should include more than just the individual requirements. A
summary of the system architecture puts the complex electronics into
context. Any configurations, system states, or operational scenarios
that affect the complex electronics should be discussed in the
document. The environment the device will operate in, such as deep
space, high altitude, or the lab down the hall, should be included as
part of the system overview.
A good
specification (requirements document) for complex electronics will
contain:
- A description of how the
device fits into the larger system. A block diagram is very
helpful.
- A description and list
of all the major functions the device will perform. A block and/or
flow diagram can be used to show this information.
- A description of the
device and interfaces, such as:
- Chip
physical information (size, type, number of pins, etc.)
- I/O
pin mapping and description (output drive capability, input
threshold level)
- Timing estimates for:
- Setup
and hold times for input pins
- Propagation
times for output pins
- Clock
cycle time
- High-level estimates and
goals
- Gate
count estimate
- Power
consumption target
- Constraints on the
device
- Other requirements or
criteria the device must implement
- Design-related choices
(may be in a management plan)
- Tools
that will be used at all stages of development
- Hardware
Description Language chosen
|
