Requirements engineering in Fennovoima nuclear power plant program: presentation in Finnish Project Management Association's seminar

1. Requirements engineering in
Fennovoima nuclear power plant
program
Pekka Mäkinen
© Fennovoima Oy
08.10.2018
Public

2. 2

3. Basic principles

4. The Holy Trinity
 Requirements engineering is
implemented as part of
configuration management.
 Design documents must
conform to design requirements
– and physical configuration
must conform to design
documents and requirements.
Picture source IAEA-TECDOC-1335: "Configuration management in nuclear power plants"
4

5. The V model
 Requirements are elaborated
to requirements and design.
 Elaboration and design
continue until something can
be implemented.
 Review and testing is done
against requirements.
 Finnish nuclear YVL Guide
requirement B.1 339: “The
requirement specifications
shall be unambiguous,
consistent and traceable. It
shall be possible to verify the
fulfilment of the requirements.”
Picture source https://en.wikipedia.org/wiki/V-Model_(software_development)
5

6. From architecture to systems
Picture source Space and Missile Systems Center Systems Engineering Primer & Handbook
ADLAS is a trademark of Fortum Oyj
 Requirements define a
problem for which functional
solutions are found.
 The functions are then
allocated to systems in
architectures, also defining
the interfaces between
systems.
 ADLAS® implements a
system to define system
architecture based on safety
functions.
6

7. Some nuclear industry specificities
 Safety is and must be #1.
 In addition of verification/validation there is also the concept of qualification: the
requirement to verify that a system or a component fulfills it’s safety function
and requirements working correctly within all environmental parameters
throughout it’s operational life.
 Requirements and design are mostly document based: that means that many
requirements are not identified as such (e.g. with a requirement identifier).
 Concepts of requirements as design decisions and design as collection of
requirements are mostly missing in the industry.
 Not maybe specific to nuclear industry, but a note that contracts are collection
of requirements.
7

8. The implementation

9. Requirements in the Fennovoima NPP program
 FH1 Program contains: EPC project, Fuel project, Owner’s Scope projects
 Laws, EU directives, standards etc.
– Essentially infinite amount of requirements, but typically not handled as individual requirements but document references
 STUK regulations
– ~600 objects, ~300 requirements
 YVL Guide requirements
– ~9 000 objects, ~5 600 requirements
 NPP Engineering, Procurement and Construction (EPC) contract with RAOS Project Oy
– ~25 000 objects, ~17 000 requirements + the actual contract + appendices + YVL requirements
 Nuclear fuel contract with TVEL
– Requirements defined as part of the contract text
 ADLAS requirements (elaborated from EPC and YVL requirements)
– Safety architecture and system design, small amount yet, few thousands, will grow during system specification to tens of thousands
 Owner’s Scope requirements
– ~ 50 ongoing projects, each with hundreds of requirements
 Requirements elaborated by Fennovoima
– Elaboration from e.g. security standards or environmental permits
9

10.  Process charter description
 Requirement Management
Plan covering the whole
supply chain and
Fennovoima.
 Fennovoima internal
– RM Procedure
– RM Procedure for Owner’s
Scope
– DOORS Quick Guide and linking guide
– Requirement attribute instruction
– Requirement writing instruction
– Management of environmental requirements
– …many specific instructions covering requirement management in DOORS
Requirement management process and
instructions
10

11. 11
 Three persons in the requirement management team, part of the configuration
management sub-unit
– Administration of Rational DOORS tool
– RM / DOORS training
– Supplier requirement document reviews and audits
– Requirement internal reviews
– Management of requirement changes
– Export and import of requirements data from/to DOORS
– DOORS customizations
 Requirement content, change and implementation analysis is the responsibility
of discipline technical specialist whom the requirement management team
support
– Requirement Responsibles named for individual EPC contract and YVL Guide
requirements.
Fennovoima organization for requirements

12. Requirements in the supply chain
 Each supplier / sub-supplier
has it’s own requirements
management tool or minimally
a supplier at the end of the
supply chain receives
requirements as appendices to
contracts or in Excel file.
 Supplier requirement
management plans and
procedures define transfer
formats for sending
requirement data between
suppliers or to Fennovoima.
AtomProekt Requirement
Management procedure
AtomProekt Requirement
Management procedure
EPC contract (and
Fennovoima Requirement
Management Plan)
RAOS Project Oy
Requirement Management plan
Supplier Requirement
Management procedure
Owner
Supplier
Sub-Suppliers
DOORS
RMS
RMS
Suppliers relevant to safety:
sub-Sub-Suppliers procedures
RMS
RMS
RMS
sub-Sub-Suppliers
RMS = Requirement Management System
EPC contract
Contracts
Contracts
12

13.  IBM Rational DOORS is used as requirements
management tool
– Positives: “looks like Excel”, can be customized
as needed, can handle tens of thousands of
requirements and their relationships
– Negatives: missing functionalities for database
wide actions, old client-server solution which is
not easily integrated to modern web solutions, can’t handle well parallel development.
 Fennovoima has around 40 user licenses for DOORS.
 DOORS database has around 350 user accounts.
 Most of the requirements data is in DOORS.
 Personnel use DOORS from day one, as most have to study EPC contract and YVL
Guides.
The tool in Fennovoima: Rational DOORS
13

14. Training on requirements engineering and tools
 Induction training
– Two week program includes a short session on requirement management.
 DOORS Basic Course
– Two hours hands-on training in a computer class
– All personnel get read-only access to Rational DOORS
– After completing this basic course, also modify access is granted.
 Writing better requirements
– Half-day workshop on requirements writing aimed at Owner’s Scope personnel.
 Reviewing ADLAS documents
– Full-day workshop with exercises going through ADLAS principles, requirement structure and
DOORS tool support.
14

15. Safety requirements andADLAS
 Fortum’s ADLAS methodology implements basic principles of system engineering by functional architectural design
based on requirement traceability: requirements allocation and elaboration.
 Part of safety related requirements have been selected as input requirements to be elaborated with Fortum’s ADLAS
methodology which will produce licensing documentation along with requirement traceability.
 Current coverage of ADLAS for YVL requirements is around 10%, so the fulfilment of the rest YVL requirements has to
be shown by other methods.
15

16. Requirements traceability
 As design is mostly document-based,
most of the traceability information is
in the document “List of requirements” table.
 Data on requirements traced (selected as input requirements and requirement version used for
this document revision) are also sent to Fennovoima and the data is imported to DOORS and
linked to document data.
16

17. Requirement fulfilment
 Requirement fulfilment is followed in two Fennovoima internal projects in which the
discipline specialists fill fulfilment data for EPC requirements or YVL requirements:
– Who are responsible for fulfilment and follow-up of an individual requirement
– What documents show or will show the implementation or fulfilment of this requirement
– What is the justification for the Fennovoima view on fulfilment
– When does Fennovoima expect this requirement to be fulfilled.
 Reporting on fulfilment
– Fulfilment metric reports are run with customized script across all EPC/YVL requirements to
report progress.
– Part of the YVL fulfilment data is sent to STUK as an attachment to the licensing documents.
– Part of the EPC fulfilment data is sent to RAOS Project as a Fennovoima view on the fulfilment
of the EPC contract.
17

18. Requirement change management
 Requirement change management is part of the “Integrated Change Management”
process which analyses the change requests and assesses their impacts.
 If the change request is made against a requirement then after passing this process and
approved the requirement is changed.
 Implementation in DOORS
– Change request data for EPC requirements is stored in DOORS and are linked to the affected
requirements creating traceability between change request and requirement.
– Change requests can be viewed by a DOORS traceability view to see what change requests
have been made.
– In addition DOORS history mechanism stores data on all changes made.
– To protect against accidental changes most important attributes in DOORS are read-only for
standard DOORS users.
18

19. Requirements and configuration management
 Design requirements are configuration items and thus have connections to configuration
baselines (EPC / YVL / ADLAS / Environmental / OS).
 Each requirement is versioned, either by Fennovoima, STUK or by supplier writing the
requirement.
 Requirement change requests have a specific configuration baseline where the change is to be
implemented.
 Approved requirement change request leads to a new requirement version.
19

20. Customized tools developed
 DOORS DXL script development allows to supplement DOORS
functionalities which are missing from out-of-the-box DOORS,
e.g.
– Requirements search across modules
– Traceability views and exports
– Requirements allocation to systems
– Integration of requirements to other design tools
– Reporting on requirement metrics
– Producing formatted exports.
 These user scripts are collected as DOORS menu selections.
20

21. Problems found in requirements engineering
 Requirements version management in supply chain
– Across hundreds of suppliers it is sometimes hard to be certain that all suppliers have the current
requirements available
– Tools: checking in audits, allocation work by the suppliers
– In the future all the Finnish YVL guide requirements will be updated…
 Vocabulary: what does traceability mean
– Not all suppliers are capable of producing data showing the fulfilment of requirements allocated to
them
 Vocabulary: what are e.g. “design requirements” or “project requirements”
– What is meant actually meant by the terms? “Design requirements” might be a text document, not a
collection of requirements
 Tools and transfers of data, tool support or manual
– Excel is the most used requirements management tool in the world, but that does not mean that Excel is
a good requirements management tool.
21

22. Looking forward: where to go from here
 Current focus is on fulfilment of requirements in design and licensing material for construction
license.
 After the design V model is fulfilled (and change managed), then the come the V model
fulfilments for construction, installation, commissioning and operation.
Requirement
Fennovoima fulfilment: should be fulfilled by
Supplier traceability: is fulfilled by
Analysis: is the
contract fulfilled?
22

23. 23
The end result

24. 24

25. FOLLOW US
@PekkaTMakinen
@Fennovoima