THE SINGAPORE ENGINEER - Institution of Engineers Singapore

SYSTEMS COVER ENGINEERING
STORY
So the V does work!
The Systems Engineering V diagram shows all the previously
mentioned principles of design verification being differentiated
from product verification, iteration equalling the first design
verification and definition parameters at one level becoming the
requirements at the next level down.
These principles easily map onto the traditional Systems
Engineering V. Viewed in this way, it is an enhancement of the
traditional V and more closely reflects the way a product evolves
from requirements, through iterations of definitions, to an
eventual product.
Any ‘suspicious linkages’ now include the verification evidence
that should be interrogated to confirm (or otherwise) the
‘suspicion’ and quantify the non-compliance. The number of links
needing maintaining is also potentially reduced. Another major
advantage is that the verification evidence is now visually part of
the process rather than an ‘addition’.
The chosen information model
As indicated above, the Requirements Management process
within Rolls-Royce was intended to be applicable outside
the purely technical domain and thereby embrace business
requirements, supply chain requirements etc equally well. It also
had to be applicable at all levels from ‘the top’ layer down to the
component layer.
Inspecting the Systems Engineering V diagram, there is a very
clear fractal. This was chosen as the information model - it is
simple, completely scaleable between layers and scaleable
across a whole enterprise and can be represented by a cluster
of documents and/or modules in a formal Requirements
Management tool.
CODIFICATION IN A FORMAL PROCESS
Clearly, the complete process of managing requirements consists
of more than just the above information model. However,
applying the above information model across a complete
enterprise will ‘govern’ the Requirements Engineering aspect.
Before the Requirements Engineering starts, requirements will
need to be elicited and validated. The lifecycle also has to include
the management of non-compliance. All aspects are shown in
the process diagram.
The process
As can be seen, the process is conveniently divided into three
distinct phases, all of which are codified in a formal, controlled
Rolls-Royce Global Quality Procedure.
Stakeholder Analysis and Requirements Capture
There are many ‘elegant’, formal Systems Engineering tools
that should be used, as appropriate, for this stage. These are
not detailed here but merely acknowledged as potentially
fundamental to this stage of the process.
Requirements Engineering.
In terms of the cascade, this is described in detail in the
discussion around the Information Model. The method by
which new requirements are derived as solutions to complex
requirements is again, fundamentally dependent on formal
Systems Engineering techniques.
Documentation Structure
Being pragmatic, it was accepted that it would be a cultural
shift too far to manage all requirements only in a formal tool,
including sign-off. It was therefore accepted that documentation
would be expected. A document structure already existed
Diagram showing the fractal cluster at the systems level.
24 THE SINGAPORE ENGINEER April 2012