THE SINGAPORE ENGINEER - Institution of Engineers Singapore

SYSTEMS COVER ENGINEERING
STORY
Deployment of Requirements Management
in Rolls-Royce
Mr Lee Glazier, Chief of World Class Systems, Rolls-Royce plc, UK , was tasked, in October
2007, with deploying Best Practice Requirements Management across the whole company.
In this article, he describes the issues associated with the existent state of Requirements
Management practice, information model options and selection, and formal codification in
a quality process. The article also discusses the importance of recognising uncertainty, and
change leadership methods used in deployment including process and tool training, support
aids and the methodology selected to continue the deployment across Rolls-Royce.
BACKGROUND
Rolls-Royce is a global business providing power systems for
use on land, at sea, and in the air. The company has a balanced
business portfolio with positions in the civil and defence
aerospace, marine and energy markets. It operates in five
segments - Civil Aerospace, which is engaged in the development,
manufacture, marketing and sales of commercial aero engines
and aftermarket services; Defence Aerospace, which is engaged
in the development, manufacture, marketing and sales of military
aero engines and aftermarket services; Marine, which is engaged
in the development, manufacture, marketing and sales of marine
propulsion systems and aftermarket services; Energy, which is
engaged in the development, manufacture, marketing and sales
of power systems for the offshore oil and gas industry, electrical
power generation and aftermarket services; and Nuclear,
which will play a key role in the UK’s nuclear reactor new build
programme, with the largest nuclear skills base in the UK, and an
existing nuclear certified supply chain of 260 companies.
This complex organisation presented particular challenges both
in terms of scope (38,000 employees) and diversity of product/
service. A further complication was presented by the intention
that Requirements Management was to also embrace the ‘nontechnical’
domains.
EXISTENT STATE
Before 2007, Rolls-Royce Requirements Management was
formalised and mature in two main areas. Within Defence
Aerospace, Requirements Management was very formalised
for joint projects, for example, the F136 Engine for the F-35
Joint Strike Fighter with General Electric. Also, the Controls
departments had good, formalised and mature Requirements
Management. Additionally, there were good, localised examples
across the whole enterprise. There was no explicit requirements
elicitation or management process beyond the definition of a
range of requirement and definition documents in one top level
engineering process.
PROBLEM WITH EXISTENT STATE AND
RESULTANT ORGANISATIONAL DECISION
The most obvious issues with the above state are around
22 THE SINGAPORE ENGINEER April 2012
consistency and governance. There are significant effects
stemming from these issues - tools, training, resourcing, process,
documentation etc that all add costs to a business.
In 2007, Rolls-Royce appointed a Chief of Requirements
Management with the role and objective of deploying Best
Practice Requirements Management across the complete
enterprise.
INFORMATION MODELS
Clearly, to be successful in a company-wide deployment, with
a majority of employees who were inexperienced in formal
Requirements Management tools and process, the chosen
information model, principles, process and tools needed to be
simple but effective.
Is suspicion sufficient?
The classic information model shows requirements linked to
derived requirements or definitions. This provides traceability
effectively between the solution and the requirement. If a formal
Requirements Management tool is used, for example DOORS,
then any change within the landscape will generate suspicious
links. This is not helpful. Senior Management is not particularly
interested in hearing that a particular change now makes an
engineer ‘suspicious’ that the original requirement may now not
be met. They want to know whether the requirement will be
met, and if not, how big will be the non-compliance. A further
issue with this classic information model is the complexity of
linkages created when a number of requirements result in a
large number of the same set of derived requirements - a ‘some
to many’ relationship. In this circumstance, the value of suspicious
links becomes questionable. In this case also, the number of links
that needs maintaining can become prohibitively large.
All requirements need to be complied with - do they
all need to be managed?
All requirements need to be complied with. Does this mean they
all need to be managed? The answer must be ‘yes’. However, at
first glance, the opposite may appear true and that depends on
levels of abstraction. At the system level, one is unlikely to be
devoting much attention to the requirements of screw threads