THE SINGAPORE ENGINEER - Institution of Engineers Singapore

SYSTEMS COVER ENGINEERING
STORY
Complete landscape of requirements and definitions documentation.
is developed, the level of uncertainty associated with the status
needs to be understood. Other work carried out by the writer,
in Rolls-Royce, beyond the scope of this article, has formalised
this in guidance documentation. This process has not been
detailed here, as it needs to be aligned with an organisation’s
internal trading processes. However, the principles will be the
same whereby requirements will be traded, relaxed and/or
more effort applied to achieving compliance.
The issue of uncertainty is an important consideration in
planning activities in the development of a complex system 5 .
The information model described above gives a good
framework for the assessment of uncertainty. Uncertainty
can come in many forms.
• Uncertainty in the requirement - either the stakeholder has
not fully defined the requirement, or there is knowledge
that it is likely to change, or it is new or novel and not fully
understood, or it is challenging the bounds of feasibility.
• Uncertainty in the evidence - there is uncertainty as to
whether the evidence has the appropriate level of pedigree
to show that the requirement has been/will be met - the
means of producing the evidence may be new or outside
calibration.
• Uncertainty in the solution - the solution type may be novel
or new, and so compliance with the requirements and/or the
impact on other aspects of the system (particularly interfaces /
interactions with other parts of the system) may be uncertain.
With a technical review of a system, this framework again
gives an opportunity to assess from a Systems Engineering
perspective. The first issue should be an examination of the
requirements - when viewed from a system perspective, are
they complete, understood, and are the implications and key
challenges clear? Are they stable? Without positive indications
on these issues, further review of the solution is immaterial.
Secondly, the evidence should be reviewed. Why do we think
that the solution meets the requirement? The level of evidence
should be tailored to the degree of certainty required at the
particular project lifecycle stage, but if the evidence does not
support the fact that the requirements can or have been met,
then a clear indication for the rest of the review is defined. Only
finally is the solution examined - to test whether the evidence
presented matches the expectation (based on experience etc)
generated by considering the solution. Without this structure it
is too easy to jump straight to reviewing the solution, without
understanding what it is required to be done.
CHANGE LEADERSHIP
The above process has been developed to be simple and
scaleable. Creating compliant solutions can be a difficult task.
Therefore, any support process needs are not to be seen as
26 THE SINGAPORE ENGINEER April 2012