Transcript CMBG Presentation Template

Requirements
Management and CM
Vendor Perspective
E. Helm, AREVA NP
Copyright © June 2012 AREVA NP Inc. All rights reserved
Contents
 Define Requirements Management (RM) in CM
and Systems Engineering terms
 Key functions of vendor RM
 RM as a focal point for vendor CM advancement
Copyright © June 2012 AREVA NP Inc. All rights reserved
2
Defining RM
“A requirement is something the product must do or
a quality it must have. A requirement exists either
because the type of product demands certain
functions or qualities or because the client wants
that requirement to be part of the delivered product.”
Mastering the Requirements Process – Second Edition, Robertson, 2006
“Requirement: Something that governs what, how
well, and under what conditions a product will
achieve a given purpose.”
ANSI/EIA 632, 1999 – Process for Engineering a System
Copyright © June 2012 AREVA NP Inc. All rights reserved
3
Design
Req’ts
Facility
Configuration
Information
Physical
Configuration
Hand-over /Turn-over
Defining RM – Nuclear CM
Design
Req’ts
Physical
Configuration
Facility
Configuration
Information
CM Equilibrium Restoration
Requirements
Hierarchy
EPRI 1022684,
Elements of PreOperational and
Operational
Configuration
Management for a
New
Nuclear Facility,
2011
Design requirements are technical requirements derived from the
design process that are reflected in the final design
Copyright © June 2012 AREVA NP Inc. All rights reserved
4
Defining RM – Nuclear CM
Beyond the Design Requirement Circle:
 How do we collect and derive them reliably?
 Who facilitates the discipline of well written
requirements?
 How are they structured during design?
 How are they reused for future work?
 How are they created and changed?
 How is requirements database linked with document
management?
Comprehensive treatment of RM is needed to navigate the
design process that supports nuclear services and new
builds.
Copyright © June 2012 AREVA NP Inc. All rights reserved
5
Defining RM – Data Structure Factors
Allocated to
the hierarchy
Represent
design bases
views
Target for only a
specific level of
the hierarchy
Clear,
concise,
valid
 CM best practice recommends specific requirements granularity
and structure to avoid corrective action (CMII)
 New build customers ask for the same in a virtual plant to support
operations
Traceability within
Within licensing
docs
Data vs. documents
for design bases
Practical level of requirements structure and granularity
in design is a win-win
Copyright © June 2012 AREVA NP Inc. All rights reserved
6
Defining RM – Systems Engineering (SE)
 SE focus is the design
and integration process
 Well known in I&C area
ANSI/EIA 632, 1999 – Process for Engineering a System
Systems Engineering Handbook, INCOSE-TP-2003-002-03.2
 SE focus is full and
structured set of reqmts
 Key benefits for new work
Systems Engr. and requirements approach are keys to
installed base and new builds design process
Copyright © June 2012 AREVA NP Inc. All rights reserved
7
Defining RM – Business Case
 Quality and Efficiency – High quality impact
analysis, well defined design review, clear
interfaces
 First-of-a-kind – Discovery of requirements in
new designs
 Data – Handed over in granular and usable
format
 Knowledge – Reusable, systematically stored,
and efficiently accessed
Copyright © June 2012 AREVA NP Inc. All rights reserved
8
Defining RM - Challenges
 Different drivers per discipline
 Intalled base needs speed and repeatability in
deriving requirements
 New builds need to be exhaustive and
correctly linked to licensing and tagged
component
RM program growth has barriers. Strong SE
requirements experience is needed.
Copyright © June 2012 AREVA NP Inc. All rights reserved
9
Key Functions – RM Process at a Glance
 Project Kick-off
• Customer needs
• Concept – environment, technical solution, existing
solutions
• Initial Operational Concept Document
 Capture Source Requirements
• Concept (PTRD, Repair Concept)
• Existing License Basis, Codes, Standards
 Customer Survey for Specific Requirements
Copyright © June 2012 AREVA NP Inc. All rights reserved
10
Key Functions – RM Process at a Glance
 Initialize Database and Technical Breakdown
Structure
 Requirements Analysis – specified
requirements
• Unambiguous
• Non-Conflicting
• Uniquely assignable to single configuration item
(system, structure, component, function)
 Record specified requirements
• Vertical traceability
• Allocation to item level
Copyright © June 2012 AREVA NP Inc. All rights reserved
11
Key Functions – Lessons Learned
 Partnership with companies
leading in Systems
Engineering
 Leading change in process is
tougher than the database
 Database schema is critical
Copyright © June 2012 AREVA NP Inc. All rights reserved
12
Key Functions – Source Requirements
 Standardize process for parsing a document
• Parsing tools are dependent on formats still only semiautomatic – requires effort
• Ownership of source documents to ensure changes are
incorporated
 Store source document blocks as database objects
• Blocks of Thought (BOT) – can be paragraphs, figures, tables,
single line in a table
 Derive requirements from the source document blocks
BOT
REQ
The minimum required RCS total loop flow rate is x
gpm for the entire load range, which corresponds
to the combined design flow rate per pump (y
gpm/pump). This value is used as an input for the
FSAR accident analysis and RCS stress analysis.
(references a, b, and c)
The RCS shall be
designed such that the
minimum required total
loop flow rate is x gpm
for the entire load
range.
Copyright © June 2012 AREVA NP Inc. All rights reserved
13
Key Functions – Requirements Facilitation
 Rational derived requirements from the source
 Need a strong facilitator
 Reuse of existing requirements maximized
 Different kinds: narrative, parametric
Copyright © June 2012 AREVA NP Inc. All rights reserved
14
Key Functions – Requirements Allocation
System
requirements
(from source BOT)
Allocated
requirements
System / Function
Product
Specifications
Copyright © June 2012 AREVA NP Inc. All rights reserved
15
Key Functions – Link to a Backbone
 Functional
 Physical
 WBS
 Supports Navigation,
reports, doc generation
 Unique target and usability
for requirement
Copyright © June 2012 AREVA NP Inc. All rights reserved
16
Key Functions – Engineering Motivation
 Change process and impact
 Lead engineers responsible for determining
affects
 How many documents will have to be opened
and analyzed for each proposed change?
Copyright © June 2012 AREVA NP Inc. All rights reserved
17
Key Functions – Link with Documents
 We still work in the document world
 Design requirements come from documents
 Link between a requirement and a document
has to be made somewhere:
• RM database
• Document database
• Integrated CMIS
 Advantages to keeping it close to the
processing of documents
Copyright © June 2012 AREVA NP Inc. All rights reserved
18
Focal Point for Vendors
 Usually in the design role
 Manages assembly of information from
concept to delivery
 In a position to reuse requirements
 Margin Management integration is a value
Copyright © June 2012 AREVA NP Inc. All rights reserved
19
Focal Point for Vendors – Transition to Data
 Enables a middle step on the way to “data”
 Impact analysis value to the project, engineer,
client – beyond the “data vision”
 Granular requirements
 High quality summary documents
representative of data
Copyright © June 2012 AREVA NP Inc. All rights reserved
20
Conclusion
 Typical Nuclear CM standards imply but don’t specify
a structured approach to requirement during the
design phase
 The Systems Engineering body of knowledge provides
the most useful reference
 The approach, discipline, and tools for building high
quality requirements in design is not obvious
 Nuclear vendors will benefit from further discussion
and break-outs on RM in future CMBG forums
Copyright © June 2012 AREVA NP Inc. All rights reserved
21
Break-out Questions – 4B Vendor Perspective
The following questions refer to Requirements Management (RM) in the
sense defined by the System Engineering (SE) Standards including INCOSE
and ANSI/EIA 632 among others:
 To what degree and for what products (if at all) do you adhere to the
system design process covered in the standards above including RM?
…for plant modification work? ...for new builds?
 Is there a programmatic interface between requirements methods and
CM? What is the nature of the interface?
 In what ways is RM distinct from CM?
 In what form do you store: system requirements, allocation to plant
functions, and traceability to source doc sections? (Ex: Docs or data, IS
system)
 What proportion of the CM program work is in the domain of RM?...for
operating plants?.....for vendor installed base work?....for new builds?
Explain.
 Recommend the title of next year’s presentation on requirements
management or whether you would like to hear one at all. Consider the
following topic areas: IB Mod RM, New builds RM, Taxonomy, detailed
overview of RM and SE standards.
22