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

2. 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

3. 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 3 Copyright © June 2012 AREVA NP Inc. All rights reserved

4. Defining RM – Nuclear CM 4 Facility Configuration Information Physical Configuration Design Req’ts Hand-over /Turn-over Facility Configuration Information Design Req’ts Physical Configuration Requirements Hierarchy EPRI 1022684, Elements of Pre- Operational and Operational Configuration Management for a New Nuclear Facility, 2011 CM Equilibrium Restoration 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

5. 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. Copyright © June 2012 AREVA NP Inc. All rights reserved

6. 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 Clear, concise, valid Allocated to the hierarchy Target 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 Copyright © June 2012 AREVA NP Inc. All rights reserved

7. 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 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

8. 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 8 Copyright © June 2012 AREVA NP Inc. All rights reserved

9. 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 9 RM program growth has barriers. Strong SE requirements experience is needed. Copyright © June 2012 AREVA NP Inc. All rights reserved

10. 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 10 Copyright © June 2012 AREVA NP Inc. All rights reserved

11. 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 11 Copyright © June 2012 AREVA NP Inc. All rights reserved

12. Key Functions – Lessons Learned Partnership with companies leading in Systems Engineering Leading change in process is tougher than the database Database schema is critical 12 Copyright © June 2012 AREVA NP Inc. All rights reserved

13. 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 BOT 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) BOT 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) REQ The RCS shall be designed such that the minimum required total loop flow rate is x gpm for the entire load range. REQ 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

14. Key Functions – Requirements Facilitation Rational derived requirements from the source Need a strong facilitator Reuse of existing requirements maximized Different kinds: narrative, parametric 14 Copyright © June 2012 AREVA NP Inc. All rights reserved

15. 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

16. Key Functions – Link to a Backbone Functional Physical WBS Supports Navigation, reports, doc generation Unique target and usability for requirement 16 Copyright © June 2012 AREVA NP Inc. All rights reserved

17. 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? 17 Copyright © June 2012 AREVA NP Inc. All rights reserved

18. 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 18 Copyright © June 2012 AREVA NP Inc. All rights reserved

19. 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 19 Copyright © June 2012 AREVA NP Inc. All rights reserved

20. 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 20 Copyright © June 2012 AREVA NP Inc. All rights reserved

21. 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 21 Copyright © June 2012 AREVA NP Inc. All rights reserved

22. 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