39 / 84
3. It is achievable.
The requirement
is technically possible, given the
constraints.
4. It is traceable.
The requirement
can be traced from lower-level
requirements and can trace to higher-
level requirements.
5. It is unique.
This standard prevents
contraction between requirements.
6. It is simple and clear.
Each
requirement specifies one function.
It is also common to use specific
language when defining requirements
to demonstrate intention. Typically, we
use SHALL for amandatory requirement
and SHOULD for a nonmandatory
requirement. Nonmandatory require-
ments let us express desired system
attributes. After we have established
our requirements baseline, best
practice is to create a compliance
matrix, stating compliance for each
requirement. We can also start
establishing our verification strategy
by assigning a verification method for
each requirement. These methods are
generally Test, Analysis, Inspection,
Demonstration and Read Across.
Creating the requirements along
with the compliance and verification
matrices enables us to:
• Clearly understand the system
behavior.
• Demonstrate the verification
methods to both internal test teams
and external customers. This identifies
any difficult test methods early on
in the development and allows us to
determine the resources required. •
Identify technical performance metrics.
These spring from the compliance
matrix and comprise requirements that
are at risk of not achieving compliance.
ASSIGN ENGINEERING
BUDGETS
Every engineering project encompasses
a number of budgets, which we should
allocate to solutions identified within
the architecture. Budget allocation
ensures that the project achieves the
overall requirement and that the design
lead for each module understands the
module’s allocation in order to create an
Figure 1 - Dynamic current dominates with higher operating voltage
Figure 1 - Dynamic current dominates with higher operating voltage
New-Tech Magazine Europe l 39