+ All Categories
Home > Documents > Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP...

Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP...

Date post: 29-Jan-2016
Category:
Upload: whitney-melissa-webb
View: 238 times
Download: 0 times
Share this document with a friend
Popular Tags:
22
Requirements Management and CM Vendor Perspective E. Helm, AREVA NP ight © June 2012 AREVA NP Inc. All rights reserved
Transcript
Page 1: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Requirements Management and CM

Vendor Perspective

E. Helm, AREVA NP

Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 2: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

2

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

Page 3: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

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

3Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 4: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Defining RM – Nuclear CM

4

Physical Configuration

Design Req’ts

Design Req’ts

Physical Configuration

Requirements HierarchyEPRI 1022684, Elements of Pre-Operational and OperationalConfiguration Management for a NewNuclear Facility, 2011

CM Equilibrium Restoration

Design requirements are technical requirements derived from the design process that are reflected in the final designDesign 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

Page 5: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Defining RM – Nuclear CM

5

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.

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

Page 6: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Defining RM – Data Structure Factors

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

6

Represent design bases views

Represent design bases views Clear, concise, validClear, concise, valid

Allocated to the hierarchy

Allocated to the hierarchy Target for only a specific

level of the hierarchyTarget for only a specific

level of the hierarchy

Traceability within Within licensing

docs

Traceability within Within licensing

docs

Data vs. documents for design bases

Data vs. documents for design bases

Practical level of requirements structure and granularity in design is a win-win

Practical level of requirements structure and granularity in design is a win-win

Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 7: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Defining RM – Systems Engineering (SE)

SE focus is the design and integration process

Well known in I&C area

7

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

Systems Engr. and requirements approach are keys to installed base and new builds design process

Systems Engineering Handbook, INCOSE-TP-2003-002-03.2

ANSI/EIA 632, 1999 – Process for Engineering a System

Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 8: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

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

8Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 9: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Defining RM - Challenges

Different drivers per discipline Intalled base needs speed and repeatability in

deriving requirementsNew builds need to be exhaustive and

correctly linked to licensing and tagged component

9

RM program growth has barriers. Strong SE requirements experience is needed.

RM program growth has barriers. Strong SE requirements experience is needed.

Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 10: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

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

10Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 11: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

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

11Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 12: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Key Functions – Lessons Learned

Partnership with companies leading in Systems Engineering

Leading change in process is tougher than the database

Database schema is critical

12Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 13: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Key Functions – Source Requirements

Standardize process for parsing a document• Parsing tools are dependent on formats still only semi-

automatic – 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

13

BOTThe 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)

BOTThe 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)

REQThe RCS shall be

designed such that the minimum required total loop flow rate is x gpm

for the entire load range.

REQThe 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

Page 14: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Key Functions – Requirements Facilitation

Rational derived requirements from the source Need a strong facilitatorReuse of existing requirements maximizedDifferent kinds: narrative, parametric

14Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 15: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Key Functions – Requirements Allocation

15

System requirements (from source BOT)

Product Specifications

Allocated requirements

System / Function

Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 16: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Key Functions – Link to a Backbone

Functional Physical WBSSupports Navigation,

reports, doc generationUnique target and usability

for requirement

16Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 17: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Key Functions – Engineering Motivation

Change process and impactLead engineers responsible for determining

affectsHow many documents will have to be opened

and analyzed for each proposed change?

17Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 18: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Key Functions – Link with Documents

We still work in the document worldDesign requirements come from documentsLink 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

18Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 19: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

Focal Point for Vendors

Usually in the design roleManages assembly of information from

concept to delivery In a position to reuse requirementsMargin Management integration is a value

19Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 20: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

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 requirementsHigh quality summary documents

representative of data

20Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 21: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

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

21Copyright © June 2012 AREVA NP Inc. All rights reserved

Page 22: Requirements Management and CM Vendor Perspective E. Helm, AREVA NP Copyright © June 2012 AREVA NP Inc. All rights reserved.

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


Recommended