RMS2010 Requirements Management Systems (RMS): Status and Recent Developments

Information Exchange Meeting Report

Table of Contents
1 INTRODUCTION ......................................................................................................................... 1
2 SESSION 1: INTRODUCTION AND OVERVIEW (CHAIR: K. ISHIGURO) ....................... 3
2.1 Welcome and opening remarks ..............................................................................................................3
2.1.1 The management of geological disposal programme of Japan.................................... 3
2.1.2 Can RMS Activate Experts? – From Educational Viewpoint......................................... 4

3 SESSION 2: RMS IN DIFFERENT NATIONAL RADIOACTIVE WASTE DISPOSALPROGRAMMES (CHAIR: S. VOMVORIS) ................................................................................. 6
3.1 The Requirement management System for the geological disposal programme and the development of
NUMO-RMS ................................................................................................................................................6
3.2 The SKB RMS and its Status ...................................................................................................................9
3.3 How ONDRAF/NIRAS approaches RMS: Framework & Key elements .......................................... 13
3.4 Requirements Management System in Posiva: Status, Open Issues and Future Plans ....................... 16
3.5 Requirement management at Nagra...................................................................................................... 19
3.6 KMS - Overview, Knowledge Base and KM Toolkit .......................................................................... 22

4 SESSION 3: RMS IN OTHER INDUSTRIES – WHAT CAN WE LEARN? (CHAIR: S.
VOMVORIS) .................................................................................................................................. 25
4.1 Application of RMS for the management of major projects; examples from the Aerospace industry ....
................................................................................................................................................................ 25

5 SESSION 4: OPEN FORUM AND DISCUSSION (CHAIR: S. VOMVORIS) ..................... 29
5.1 Main points discussed............................................................................................................................ 29
5.2 Conclusion on the initial questions identified by NUMO.................................................................... 32

6 CONCLUDING REMARKS...................................................................................................... 33

List of Figures
Figure 1 The three stages of NUMO's site selection process .......................................... 4
Figure 2 Vision of requirements management at NUMO ................................................. 6
Figure 3 Explanation of the requirement breakdown structure ........................................ 7
Figure 4 The rank and contents of requirement breakdown structure ............................. 8
Figure 5 Structure of the SKB RMS database................................................................ 10
Figure 6 Levels of requirements defined in the SKB database ...................................... 10
Figure 7 Process of writing, reviewing and settling the requirements in the SKB RMS. 11
Figure 8 Overview of the safety and feasibility strategy at ONDRAF/NIRAS ................ 14
Figure 9 Relationship between the feasibility statements and the design function........ 15
Figure 10 Identification of the design functions .............................................................. 15
Figure 11 System structure of the POSIVA RMS ........................................................... 17
Figure 12 The change management process as proposed for the POSIVA requirement
management system........................................................................................ 19
Figure 13 The basic structure of Nagra's RMS .............................................................. 20
Figure 14 Information flow in Nagra's requirement management system...................... 21
Figure 15 Structure and components of the JAEA KMS database ................................ 23
Figure 16 Expected evolution of the KMS toolkit............................................................ 24
Figure 17 Components of an RMS................................................................................. 26
Figure 18 Embedding of RMS in the project contents.................................................... 27

List of Appendices
APPENDIX 1: RMS STATUS AND RECENT DEVELOPMENTS INFORMATIONEXCHANGE MEETING..................................................................................A1-1
APPENDIX 2: LIST OF PARTICIPANTS OF THE OPEN SESSION...................................A2-1
APPENDIX 3: PRESENTATIONS............................................................................................A3-1

1

Introduction

In recent years NUMO has been going through an intense phase of developing it own tailored
requirements management system (RMS) as it was identified that:
Requirements management (RM) is a central part of ensuring safety as part of the disposal
programme, RM provides measures to meet the various requirements from the stakeholders involved.
Furthermore, it aids confidence building, As the disposal programme continues over a period of more than 100 years and the constraints
and premises are likely to change within this timeframe, RM should be a continuous processwith a clear long-term scope.


A discussion with - and receiving feedback from - other implementing organizations, that are also
in the process of developing RMS, was deemed extremely valuable. As part of the NUMO-Nagra
collaboration, an international information exchange meeting was organized on 26 January 2010
in Tokyo. Objectives are to introduce the RMS as considered by the different organizations interms of:
Objectives and expectations, Status of developments and progress,
 Practical experience with the application,
 Identification of the key common features, differences, if any, and reason, Identification future common needs.


Representatives of implementers, at the forefront of RMS development, as well as consultants,
research organizations and academics contributed to the information exchange meeting. The listof presenters is shown below:
NUMO
POSIVASKBONDRAF/NIRAS
Nagra
University of Tokai
Parsons Brinckerhoff
JAEA

Tomio Kawata, Hiroyuki Tsuchi, Hiroyoshi Ueda,
Tiina Jalonen
Lena Morén
William Wacquier
Piet Zuidema
Toshiaki Ohe
Henry O' Grady
Kazumasa Hioki

1

The outcomes of this information exchange meeting are reflected in this report. In Chapter 2 to 4,
an overview of the discussions during the open session is given.
In the appendices the agenda of the workshop (Appendix 1), the list of participants (Appendix 2)
and the presentations of the open session (Appendix 3) are included.

22 Session 1: Introduction and Overview (Chair: K. Ishiguro)
2.1

Welcome and opening remarks(NUMO – T. Kawata)

Dr. Kawata extended a very warm welcome to the more than 50 participants to the informationexchange meeting from over the world and representatives of the main Japanese organizations.
RM has been initiated at NUMO not only for internal reasons but also as a tool to communicate
with the stakeholders in a complex project, such as the geological disposal of radioactive waste,
and demonstrate that their requirements have been met. Two years ago, a similar tri-lateralworkshop was organized by SKB, Nagra and NUMO and took place in Sweden. It was followed
a year later by another workshop among ONDRAF/NIRAS, NUMO and Nagra in Belgium. Thistime, NUMO is very happy to organize the current information exchange meeting, which will
provide an update on the developments, enable the receipt of feedback and, finally, highlight the
open issues to be addressed in the future developments. NUMO looks forward to constructive andfruitful discussions during this day.
2.1.1 The management of geological disposal programme of Japan(NUMO – T. Kawata)

On overview of the evolution of the Japanese HLW disposal programme is given (Appendix 3).
The start of the repository operation is estimated between 2030 and 2040. The disposal concept issimilar to many European concepts. The stepwise implementation approach with the three stagesof the site selection process is shown in Figure 1. Following the Literature Survey for thevolunteer sites and confirmation that they satisfy the site selection factors published by NUMO,
the approach consists of the three stages: PIA (preliminary investigation areas), DIA (detailed
investigation areas) and finally the RS stage (repository site).

3

Figure 1 The three stages of NUMO's site selection process

Since 2002, when NUMO issued the open call for volunteers, various discussions for potential
applications have been conducted. After the withdrawal of the application of Toyo town, thegovernment has decided to play a more active role, inform and encourage candidate
municipalities to volunteer for LS. Pro-active measures were taken to enhance PR and confidencebuilding activities; for example, currently countrywide PR activities are taking place such as the
METI Energy Caravan.
The stepwise refinement of the safety case as the programme moves along the three stages was
explained. An integral part of this refinement are also the RD&D activities; these are performed incooperation with R&D organizations; which is organized through the coordination council on
geological disposal (METI). The expectations from NUMO regarding RM can be summarised as:

RM is a central part of ensuring safety as part of the disposal programme,

RM provides measures to meet the various requirements from the stakeholders involved.
Furthermore, it aids confidence building,As the disposal programme continues over a period of more than 100 years and the constraints
and premises are likely to change within this timeframe, RM should be a continuous processwith a clear long-term scope.

2.1.2

Can RMS Activate Experts? – From Educational Viewpoint(Tokai University – Prof. Ohe)

4

One should consider the experts who are expected to "bring the answers". One should consider
which routes are to be taken to obtain the answers. An RMS might aid in providing these answers.
In the practical application of the RMS, one should recognize that potentially to satisfy the dataneeds required by the system, could result in a tool that becomes very heavy and obfuscates clear
thinking. One should keep in mind that the system can never become the expert, it remains aplatform for the interface of human resources – the experts. It should also be recognized that there
is a clear benefit in the process of developing the RMS, beyond the actual goal of obtaining thesystem. It is with these in mind, that an RMS can motivate and "activate" experts. A key message
summarising the presentation is "Look before you seek".

5

3 Session 2: RMS in different national radioactive waste
disposal programmes (Chair: S. Vomvoris)
3.1
The Requirement management System for the geologicaldisposal programme and the development of NUMO-RMS(NUMO – H. Ueda)

Highlights of the presentation (Appendix 3)
The objectives and expectations with respect to RMS in the context of the whole programmemanagement are explained in Figure 2. Here a distinction is made between scope management
and quality management. The RMS should be also linked to the schedule management and humanresource management (Figure 2).

Figure 2 Vision of requirements management at NUMO

Development of the RMS started in 2005. First activities focussed on specifying NUMO's needs
for such a system and evaluating existing software (in this particular case Doors®). In order tosatisfy NUMO's needs and links of RMS with other management tools within its programme,
NUMO concluded that it would be more beneficial to develop its own dedicated system. In 20062007, the trial version of the current version was developed. In this last stage of the project (20082009), the development will be completed with fundamental functions for practical use, including
a first demonstration work.

6

Examples of the applications of NUMO RMS are:


Applications for fundamental decision making,For repository design/performance assessment (PA),

For R&D management.

The developed RMS should:Assist RM work by NUMO staff through information management,Be suitable for the stepwise approach of the Japanese programme.

Within the whole sequence of decisions to be taken by NUMO, the one for site selection is themost important decision-making issue in the stepwise siting process (see Figure 1). This can beconsidered then as the "driver" behind the current RMS developments.
In terms of organization of the requirements, a hierarchical approach, the requirement breakdown
structure, is followed as shown in Figure 3. The rank and contents of requirement breakdown
structure are given in Figure 4.

Figure 3 Explanation of the requirement breakdown structure7

Figure 4 The rank and contents of requirement breakdown structure

In order to meet the requirements, the following steps are needed:The work (design/evaluation) should be carried out to fulfil the requirements,



The fulfilment of requirements should be argued with measures, the synthesis of evidence, andthe evidence itself.

It is recognized that some arguments may depend on the site-environment and the engineering
alternatives, which implies that one can develop an RMS generically only up to a certain point (orhierarchical level). In any case however, how to fulfil the requirements should also be describedin the measures.
The next steps in NUMO's RMS development are:

Re-attribution of design requirements/design indicators for the specific site under the new RM
methodology,Link with KMS (see 3.6) and application of RD&D outcomes,

Practical operation of the RMS tool in NUMO's programme,Application to quality assurance.

8

Questions
The first question focused on the clarification of the system usage and whether the intention is touse it as a decision-making or a decision-support system. It was replied that the system should beseen as an important tool to discussion with all stakeholders and demonstrate how these are met.
Here stakeholders could be seen as external groups, or internal groups, for example the safety
analysis group, the engineering group etc.
It was argued that if the system usage is aimed to be very broad one should consider the danger
that at the end no one will use it.
With respect to the PDCA approach (Plan-Do-Check-Act), it is asked whether it should be known
in advance how to perform the third step, also called "the validation".
The "validation" step is equivalent to confirming the compliance of the suggested decision withthe requirement. The definition of this step is in progress.

3.2

The SKB RMS and its Status(SKB - L. Morén)

Highlights of the presentation (Appendix 3)
At SKB, RMS has been developed within the spent nuclear fuel programme. The application for
the Forsmark site will be in the middle of 2011. The RMS is applied mainly for the design of the
facilities at Forsmark.
SKB started developing the RMS in 2001, together with the site investigations for the twocandidate sites. Initially the design premises were described in one document. A trial project in
2002-2004 took place to transform this in a database. Since 2005, RMS is an ongoing activity.
Purposes of the RMS are:

Provide correct and complete design premises for the KBS-3 repository and repository facility,Ensure that the KBS-3 repository and repository facility conforms to the design premises,Make the basis and motive for the design of the KBS-3 repository and repository facility
traceable,

Facilitate system understanding and put details in the design and design work in their context,

Facilitate decision making and avoid mistakes in design, production and operation,9

Facilitate development and management.

The structure is given in
Figure 5 and is actually fairly similar to NUMO's structure. The different levels of the RMS are
discussed as given in Figure 6 and examples for each level are given. For example, at the Level 5
the designer gives the information to the PA to assure that the design can actually comply with thehigher level requirement.

Figure 5 Structure of the SKB RMS database

Figure 6 Levels of requirements defined in the SKB database10Requirement attributes are given to all the requirements at each level. These can be review status
or references. At the Level 4 (Design) this can also be the decision maker and the decision
document etc. The database further contains instructions, links to guiding documents and routines,
concept and definitions and decisions.
The process of writing, reviewing and settling the requirements is given below (Figure 7).
The work on the database is still continuing, but the current status can be summarised as follows:
Level 1-3:
Determined versions of all modules with stakeholder, system and sub-system requirements,



Reviewed by SKB's legal advisors and technical experts,

Sub-system requirements are currently up-dated.

Level 4 and 5:
Design requirements for all barriers of the final repository and all systems in the facility – notformally determined,

Reference design specifications – not formally determined.

Figure 7 Process of writing, reviewing and settling the requirements in the SKB RMS

11

Other design premises are:

Determined version of design premises from the long-term safety assessment,Specification of spent fuel to be deposited – not formally determined.

Open issues are still the definition of the workflows and the definition of the amount of
information that one wants to keep in the system. One should be aware that all information
included should be checked and, if necessary, updated on a regular basis.
Questions
It was asked whether the RMS can be used proactively (for example, define lower level
requirements) or retroactively (for example, document decisions made) or in both ways. The highlevel requirements can be probably defined anyway; but the lower level requirements seem very
specific and strongly linked to the KBS-3V case (one of the SKB’s EBS concept for the verticalemplacement). For example, what would happen to these requirements if the decision would betaken at SKB to change to reference case to KBS-3H(one of the SKB’s EBS concept for thehorizontal emplacement)?
The answer for the second part of the questions was that the top level and second level
requirements are identical in both KBS-3 cases. Certain parts of the facilities of the repository
system will be the same also. With respect to the first part, SKB would suggest to start earlier with
the RMS than they did, so that it can be implemented more fluently and, in that sense, also moreproactively.
With respect to development and testing of the RMS, it was asked whether it can be used forgeneric cases. If a case is still generic, would it be better to implement and test the system
retroactively, accurately documenting the current decisions?
The system can be used in a generic case and it can be used proactively mainly for the highest
levels. To write lower level design premises, a first set of information needs to be compiled. The
lower level design premises are strongly linked to, and specify, the reference design.
Consequently, they will develop as site investigations and technical development proceeds. A first
set can be regarded as an example of a possible solution and can be used proactively.
It was asked whether the stakeholders' requirements are updated continuously and if yes, what
effect would this have to the work progress.
In most programmes, the high-level requirements are not expected to change very often, or
suddenly. But in case such changes do occur, for example decisions regarding reversibility or longterm monitoring, these would need to be integrated at the top level and will have consequences at12

lower levels. The RMS can be very helpful is such a case; however, this situation is expected not
to happen on a regular basis.
With respect to the top level requirements, these are defined by the stakeholders and the regulator
and thus outside the influence of SKB. How are the low level requirements defined?
This is a long process with many people involved whereby all come with their own mindset,
which occasionally does not facilitate an expedient decision making. SKB is still working to
improve the procedure of the definition of the lower level requirements.

3.3
How ONDRAF/NIRAS approaches RMS: Framework & Key
elements(ONDRAF/NIRAS - W. Wacquier)Highlights of the presentation (Appendix 3)
In this presentation framework and key elements regarding the approach to RMS regarding threeelements are given (Figure 8):Safety and Feasibility Strategy,Feasibility Assessment Methodology,



Safety Assessment Methodology.

In the safety and feasibility strategy (Figure 8), system development and assessment of its safety
and feasibility are constrained both by boundary conditions and by a number of strategic choices
made by ONDRAF/NIRAS (which are themselves constrained by the boundary conditions). These
strategic choices and the boundary conditions are translated into requirements related to thedisposal system. System development and safety and feasibility assessment are carried out in parallel
and iteratively.
System development starts with the development of the safety concept, on the basis of existingknowledge and understanding and of the requirements on the system. The safety concept, together
with the requirements, is translated into a structured set of safety and feasibility statements, used as a
guiding tool throughout further system development and safety and feasibility assessments. With
the safety concept as a basis, the development of a repository design is carried out iteratively. The
repository design includes the description of the design of the proposed disposal system and theimplementation procedures and is developed as far as is necessary to support the safety andfeasibility case.

13

Figure 8 Overview of the safety and feasibility strategy at ONDRAF/NIRAS

Hence, the safety and feasibility statements play a central role and are equivalent to therequirements.
In the feasibility assessment methodology the feasibility statements (Figure 9) are:

Organized in a tree structure,

Derived from safety concept in a top-down approach,Covering all activities (removal primary package  institutional control).

Design functions are identified at the lowest level of the feasibility statements and arecharacterised by criteria allowing to:Evaluate if the feasibility statement (requirement) will be met,

Identify potential open questions,Specify a specific design (ref. or variants).

14

Figure 9 Relationship between the feasibility statements and the design function

The feasibility statements and the design functions are characterised by the elements as describedin Figure 10.

Figure 10 Identification of the design functions

The completeness check is obtained by cross checking with respect to story boards and the stateof the art describing the relevant best proven practices.
It can be concluded that:15

Safety and Feasibility assessment methodologies developed based on the strategy,

Requirements are managed through the safety and feasibility statements,

In the Feasibility assessment methodology, statements are further derived into functions andassociated criteria to demonstrate the feasibility.

Questions
It was asked whether the elements of the RMS are similar to the elements of the safety case(safety and feasibility statements), or if there are other elements not explicitly mentioned herein.
This is indeed true as the safety and feasibility statements form the RMS and are the drivers of thesafety case.
With respect to tools used, does ONDRAF/NIRAS use a specific software package?
ONDRAF/NIRAS is utilising currently R. Vignette, a knowledge management tool; the tool iscurrently used as part of the development of the safety case and it includes the safety andfeasibility statements with their argumentation and the remaining open questions. For the functions
and criteria Excel is used currently. Regarding the functions and criteria, first the data will becollected to "fine tune" the feasibility assessment methodology which is under development andthen the specific ONDRAF/NIRAS needs for software will be defined for the management of the
data.

3.4
Requirements Management System in Posiva: Status, Open
Issues and Future Plans(POSIVA – T. Jalonen)Highlights of the presentation (Appendix 3)
Posiva has already over 40 years of site investigations and site selection behind it. At the end of
2012, the application for the construction licence will be submitted. The goal is to start thedisposal in 2020.
The objective of the RM project has been to design, implement and introduce a systematic
process and an information system to manage the requirements related to the geological disposalof spent nuclear fuel in Finland. Before the start of the project the site was already selected.
The desired result of the project is an information system with a database which

16

Includes all the significant requirements, the reasoning underlying them, and the existing
specifications to fulfil them,Enables an easy review of compliance between separate specifications and requirements,

Contains information of dependencies between requirements,

Enables a systematic review and documentation of influence derived from alterations inrequirements,

Enables implementation of RM as part of day-to-day operations within organization.

Because of the close collaboration between SKB and POSIVA, for the development of the RMS
POSIVA was able to rely on the SKB experience and started in 2006. The DOORS software waschosen as the preferred software. The structure and contents of the RMS were developed in 2007.
The system structure is described in Figure 11.

Figure 11 System structure of the POSIVA RMS

The process of the definition of the requirements was the following:The project team gathered the Stakeholder requirements (Level 1) and the System
requirements (Level 2) (3rd Qtr 2007),

A person responsible for gathering the requirements for each sub-system (Level 3) was
nominated,
17



Canister – Development manager,Buffer – Development engineer,Backfill & Closure – Development Coordinator,

Technical facilities – Design engineer,Technical systems – Design engineer,Gathering existing requirements for levels 3-5 in each sub-system group was done during 2007,



Specifying the structure and the contents and defining dependencies for the RMS.

In its current status, approximately 1500 requirements are in the RMS database. The stakeholder
and system requirements are completed, and certain subsystem requirements are also defined. A
web access has been created for access for the contractors.

Current open issues are:

The sub-system requirements that have been compiled but need to be re-organized andapproved: technical facilities, technical systems, new sub-systems Transportations andOperations,

Actual verification of the requirements and specifications: some demonstrations done, someplanned.

Future plans are:

To link the existing sub-system requirements (connections defined) and add specifications,

To transfer ownership of the RMS to Posiva's Safety Unit,

To rehearse the change management process (see also Figure 12).

Questions
It was asked which type of the work is done in house and what is done by consultants.
The basic research and design is done at Posiva. So system engineers are involved at Posiva andthese are able to judge which information can be entered in the system. At Posiva, the systemengineers and the people feeding in the requirements are indeed sometimes the same person, butthere is always a higher level management control on what is actually entered in the system.

18

Figure 12 The change management process as proposed for the POSIVA requirement
management system

3.5

Requirement management at Nagra(Nagra - P. Zuidema)Highlights of the presentation (Appendix 3)
The current situation in Switzerland, including the ongoing site selection process, wassummarised.
The major goals of the RMS are:


Nagra wants to have a complete overview on all relevant requirements (compilation ofrequirements),For each of the issues at hand, Nagra has to ensure that all relevant requirements are
considered (specification of requirements).

Operational goals of the RMS are:19

Facilitate repository development (incl. transparency for communication with stakeholders),

Facilitate decision making (clarify objectives),Ensure traceability of decisions (motivation for decisions),Ensure a continuously updated basis (and help keeping track of changes).

Thus, the RMS contributes to ensuring safe repositories and should provide confidence to thestakeholders involved (Nagra, other). The basic structure of the RMS, the corresponding process
and the information flow are described in Figure 13 and Figure 14 respectively. RM provides also
input the formal interactions with the authorities.

Figure 13 The basic structure of Nagra's RMS

The current status of RMS at Nagra is as follows:

RM is a process within Nagra's Quality Management system since several years,



RM has been used in several key projects (resulting in formal reports), especially:Wellenberg site investigation (1997-2000),Development of waste management programme (2006-2008),



Site selection process: proposal of siting regions (2003-2008, continuing),
20The structure & process of RM has been a continuous development (evolutionary process, stillchanging) and the developments will continue,The requirements are documented in several external reports and internal databases (FileMaker Pro, EXCEL, …),

IRQA® (visure®) has recently been chosen as standard software (based on structured
evaluation process).

Figure 14 Information flow in Nagra's requirement management system

To summarise:

RM is a process to derive and apply requirements; the consideration of the overall objectives
and overall context is important,

RM is part of the organization's culture: it serves to define objectives, helps to evaluate
whether objectives are met and does this in a traceable manner to make the quality of the workand the corresponding products visible,

Therefore, RM is integrated within Nagra's qualitiy management system and has to be appliedin all important projects,21A broad and appropriate structure of the RMS with emphasis on the broad objectives is of key
importance. For that purpose, a hierarchical structure of the RMS has been chosen (different
hierarchies in the requirements, different hierarchies in the elements to which the requirements
apply).

Presently, the requirements are stored in more than one database – while their underlying
scientific basis is documented in several formal reports. This will be optimised in the immediate
future.
Questions
It was asked to describe the mechanism of decision making and application of RM as part of theselection of the siting regions.
RM can contribute to decision making but it is then important to provide the time for a certain
number of iterations in the requirements definition (and the requirement resolution) process; often,
it turned out that the first draft was not yet fully satisfactory.
In the recent process of selecting the siting regions, the government guidance asked for thedevelopment of the necessary requirements in a first step (based upon 13 broad criteria), and thensiting regions were identified in a step-wise narrowing-down process, which lead to the decisionof siting regions to be proposed. The overall process has thus been split in a sequence of steps /sub-processes. Setting of priorities played an important role: thus, the corresponding requirements
were divided into "need to have", "nice to have" and "to be considered in optimisation".

3.6

KMS - Overview, Knowledge Base and KM Toolkit(JAEA – K. Hioki)

Highlights of the presentation (Appendix 3)
In Japan, major projects are currently running in parallel:

Near-surface facilities operating at Rokkasho and interim-depth repository for higher activity
waste in preparation for licensing,

Deep repositories for HLW & TRU waste to be implemented following response to call forvolunteers,Integrated concept for industrial and research wastes in development,Extensive supporting R&D, including 2 URLs.

22

This information has to be dealt with a limited and aging work force. Therefore JAEA started
developing the KMS (Knowledge Management System) database.
Specific concerns that are addressed in the system are:

Radwaste generalists learned to use the KMS tools with support of IT experts only where
needed,

Recent advances in computing systems (hard- & software) were fully utilised and component
systems were continually tested for applicability and user friendliness,

Tools facilitate dialogue with users and feedback serves to drive further improvement andtailoring to specific needs.

The structure and components of the KMS are described in Figure 15.

Figure 15 Structure and components of the JAEA KMS database

An argumentation model is integrated and explained based on a structure of sub-claims, counter
arguments and arguments. Also the evidence of the argument is added under the form ofknowledge notes.
Main applications are focussing on major areas where large flows of information must be
integrated in a structured manner to provide support to the developing safety case for deep
geological disposal such as: safety case development & review, site characterisation &geosynthesis, repository design & PA.
23

The expected evolution of the KMS toolkit is given in Figure 16.
Conclusions and future prospects regarding the JAEA KMS are:


Significant progress has been made in establishing the KB (Knowledge Base: Databases forKMS) to support the H22 project and the tools that provide access to it,A number of different approaches have been examined but, to date, those based onargumentation models appear most generally useful,Effort is focused on establishing as much automatic functionality as possible, but it is acceptedthat practical application requires a hybrid approach - facilitating the work of project teams isthe main goal,Some major challenges have not yet been addressed,

KB freezing, archiving and security,

Smart search engine development,

Development of interface with knowledge producers.

Figure 16 Expected evolution of the KMS toolkit

24

Questions
It was asked how the KMS is (or will be) connected to the RMS of NUMO.
The key component/interface would be the argumentation model. It is planned that theargumentation model will interact at different levels with the RMS from NUMO. The exact
linkage is the topic of interactions and discussion between NUMO and JAEA.
As a user, the strategy for making decisions might be different than the one programmed in the
RMS through the "argument-counter argument" system. How is this addressed?
In case new questions are formulated, these can be uploaded. However, currently the system is in
use by the JAEA community only and questions cannot be added by outsiders.
Who is responsible for the information that is entered in the KMS and how is its quality
guaranteed?
The attribution of the responsibility is the same as is the case with the authorship of reports. The
writer remains the owner. The system just reflects the current knowledge.
The confidentiality and how to manage this confidence levels is still a point for discussion though.

4 Session 3: RMS in other industries – what can we learn?
(Chair: S. Vomvoris)
4.1 Application of RMS for the management of major projects;
examples from the Aerospace industry(Parsons Brickerhoff Ltd - H. O' Grady)

Highlights of the presentation (Appendix 3)
The presentation gives an overview of the application of RMS in non-nuclear industries,
particularly aerospace where RMS are well established. The essential components of an RMS are
people, processes and tools (Figure 17) – RM software is a component.

25

Figure 17 Components of an RMS

The RMS should be defined just as any other engineering process:

RMS should be defined and developed using Systems Engineering methods,



RMS should support the key project milestones and the Engineering Lifecycle,

Key features:Ease of use,

Minimal additional staff / resources,

Full integration into project process (after pilot has proven itself),Defined Inputs and Outputs,

Provable benefits,Ability to provide the inputs needed for the project / engineering milestones.

The RMS needs to be designed for and to operate in a project context (Figure 18). The"customers" for the RMS therefore include project managers.

26

Figure 18 Embedding of RMS in the project contents

Some thoughts regarding staffing and organizational structures:

Need some specialist staff, and good project management,"Project management" skills vs "data entry and data maintenance","do it" types vs "plan it" types,



Careful definition of the roles of other functions: IT, Projects, Commercial, Configuration
management, Engineering, and Project management,

Role of Chief Systems Engineer,Training and familiarisation are key,For management as well as engineering staff,And possibly the External Client & Regulators,

Organization of the RM function should map onto the External Client organization,
Foster External Client liaison at low levels of the organization.

During the full implementation stage of the RMS one should be aware that:27

Approach must be flexible as: staff may change, stakeholders and regulators do not behave
ideally, funding will change, or organization will change,At this stage the RM team must be fully part of the project team,

The RMS and the RM software must be the primary systems/tools used (For example. must
not let people keep using WORD or Excel and only use the RMS as an archive).

The main points regarding RMS in other industries, which are potentially also applicable to theradioactive waste business, are:

RMS should be seen as a formal project,Identify customers and stakeholders,

Application should be tailored to the people involved, the product, the external client, existing
internal processes,

Staged approach to implementation is preferable,

Identify benefits of the RMS and then demonstrate them,

RM software tool specified around the overall RM process,

Use RM processes on the RMS itself.

Questions
It was recognised that the role of the Chief System Engineer is of key importance; it was asked
how this person can be selected.
They often select themselves by showing the ability to think at the top technical level in terms ofbuilding blocks rather than detail. However, they should be able to understand the detail whennecessary and be able to communicate with technical experts, project managers and clients. The
best training of new people in this role is through mentoring. There are two common models for a
Chief Systems Engineer: a) an engineering manager leading a team of technical staff who defines
the requirements, justifies the system-level design decisions and proves the requirements havebeen met; or b) a specialist, without staff responsibilities, who has an in-depth technicalknowledge of the system and is able to advise the project manager on the top level design tradeoff.
Is RMS really working in practice in other industries?

28

This is indeed the case, for example, in aerospace and rail industries, most development andconstruction is done under fixed price contracts to deliver a contractually defined performance.
The contractual assumptions, risks and price are therefore defined by the requirements in the
RMS, and this is recognized by clients, project managers and commercial managers. The needfor an RMS is often written into the Invitation to Tender. Generally, in each project, whatever the
topic, an agreed set of requirements gives confidence to the developer that they are focussing theirresources onto delivering what the client wants. It also provides stability for the project byensuring that any changes are agreed by all stakeholders before any additional work is done.
How is the process of changing the requirements best defined? One should avoid that one isfighting against a moving target?
At certain points in the project programme, the set of requirements is frozen into a "baseline" andthis requirements baseline is then used for the design. Changes to requirements are then recordedin the RMS software tool, but are not addressed in the design until they have been formally
accepted and a new baseline has been generated. This ensures that the design work addresses a
relatively stable set of requirements.
What would be the biggest challenge of RMS in radioactive waste disposal area?
There are two that spring to mind based on the discussions so far:a)

Definition of the system boundaries i.e. “what is the system and what is not in it ?" It is easy
to expand the scope of the project indefinitely, particularly when stakeholders evolve theirneeds. A well-defined system boundary will permit the project funding and resources to beplanned will also allow interfaces with external organizations to be defined. Conversely, apoorly defined system boundary makes it hard to decide what to design, makes it hard to
predict funding and resources and makes it impossible to agree external interfaces. All thiscan increase the project risk significantlyb)Terminology: the need for a single set of definitions to ensure good communication andreduce mis-understanding. This is especially true when people from different engineering
disciplines meet and when more than one language is involved.

5 Session 4: Open forum and discussion (Chair: S. Vomvoris)
5.1

Main points discussed

The main points of the discussion session are summarised herein in terms of open questions.

29What is the need for RMS at NUMO?
The aim of RMS is to raise the quality of the process of decision making and support the decision
making itself. By using RMS, it will become clearer what NUMO needs to do now and in the
future. The RMS will provide common understanding and generate the awareness for delivering
the quality required.
The RMS system is a combination of computer-aided information retrieval and association as
well as the human resources (NUMO personnel, experts etc). NUMO's structured approach isneeded for the long term management of the project. All the detail does not need to be included
now; however, the human interactions and the interactions with the system should be discussed inmuch more detail.
RMS cannot be a stand alone system; its success depends rather on how it is supported and how it
supports and steers the geologic disposal project. In this stage, RMS in its current form seems anappropriate choice, but the concept of the RMS might still need change in the future.
Who would be the users and how often will the RMS be used?
A large part of the NUMO employees would use it. The intensity of using it will probably dependon the level of the employees. The intensity of working on the RMS is expected to be higher fortechnical project managers. Most likely, personnel at higher managerial level will access it lessfrequently. Overall, it is expected that RMS will contribute to creating a common understandingof what is needed for the completion of the disposal project.
Who would be the chief system engineer at NUMO managing the system?
The option is still open, it could either by a dedicated external team or NUMO could do theoverall management internally. Perhaps the most preferable option is to have a chief systems
engineer who is a NUMO employee, supported by suitable external experts, as the chief systems
engineer role needs to be very closely embedded in the organization. The most likely candidate
for the chief system engineer would be the director of science and technology.
Is the cost estimation of the geological disposal system also part of NUMO's RMS?
RMS will not manage costs at this point as the focus is on the design.
How does the hierarchical structure in the RMS work in practice? In particular, is there achance that you do not fulfil a low level requirement and still comply with the overallrequirements?

30

Certain implementers (e.g. ONDRAF) have next to strict requirements also so called "nice tohave" statements. These could be related to ease if implementation, for example, or cost
optimisation etc. In case these statements are not met the upper level requirements are still
expected to be met.
In the case of Nagra and NUMO there is no need to develop all requirements to the lowest level inthis stage of their project as the focus is on the site selection. However, one should make sure that
there are no show stoppers at this lower level in the future. One should avoid making decisions
too early in the process. A good risk management process will be helpful here.
For the current situation at NUMO, one has to substantiate, trace and qualify the decisions that
already have been made (response to high level requirements), but there is no need for attempting
definition of requirements at the detailed level now. A system that is flexible has to be in place.
Within the process, there will be requirement definition stages which will also include theremoval of requirements that are no longer needed. There is possibility to include, for example,
more than one option in the early development phase. Each option delivers the solution but
requires different effort and has different types of uncertainties. Even at a top level these different
options can exist.
Can a generic RMS be developed in case there is no site or host rock defined?
It is true that the boundaries in NUMO's case are not as clear as in some other countries. For
developing requirements the situation is much easier if one can start with a given regulatory
framework, possible concepts or host rocks; otherwise, one has to make some "strategic choices"– an approach taken by ONDRAF/NIRAS regarding the absence of regulatory framework. It is
important however to write the high level requirements even before the concept is defined.
NUMO is in an early stage and some of the requirements are very qualitative; through re-iteration
however, these should be refined and become more quantitative. It is important to know which
requirements are derived from choices that were made by the implementer, and which are
imposed externally. This will of course require effort and resources but it will be needed to start a
constructive dialogue. One should avoid defining too strict requirements in the beginning. One
can only construct a complete RMS once all the detail is known; but one can move in cycles.
The decision level is situated at one level higher than the level for which the requirements aredefined. It is important to bring in the stakeholders in the decision making process, for example
regarding the site selection process, and the RMS system can support this interaction.

31

5.2

Conclusion on the initial questions identified by NUMO.

As preparation for the information exchange meeting, the host of the meeting, NUMO, posed
three questions to all presenters (see also Appendix 3, presentation by Dr. Kawata). The questions
and a summary of the answers is shown below.
What are the lessons learnt from experiences of each organization and other industries
regarding the requirements management and its operation in the programme?


The RMS needs a clear definition both in terms of purpose and boundary conditions,

Two of the participating organizations started implementing the RMS system in a quiteadvanced state of their programme. Their advice is to start earlier with its implementation as inthat case the implementation will be a more fluent process,In general the RMS is part of the safety case, especially for the ONDRAF concept whereby therequirements are formulated as a system of safety and feasibility statements this is explicit. In
Switzerland the requirements are used formally within the Sectoral Plan (Siting Region
Selection), where it is also perceived as a beneficial tool for discussions with the regulator,Various software codes are in use by the different implementers. First the needs should be
defined, then appropriate software can be selected.

How to use the RMS to meet the stakeholder requirements, how does it contribute toconfidence building?


Stakeholder requirements are generally introduced in the RMS as top level requirements(although this does not always need to be the case). In this case the updating of stakeholders
requirements can be achieved a transparent way so that the consequences of changing
stakeholder requirements can be shown clearly,

Which are the difficulties encountered of applying RMS in the disposal programmes?
Which measures can be taken?


It seems difficult to define the system boundaries and to define the scope of the RMS,

The process of defining "in-house" technical requirements (Level 4 and 5) including thedecision making is challenging in terms of effort required and reaching consensus,



The RMS should be used by the people actually carrying the knowledge involved in thedefinition of the requirements. A system manager should keep an overall view,32

In case of the absence of a potential site or host rock, RMS can be used proactively and general
requirements can be formulated,

There is a clear need for a consistent use of terminology within the organization, and to acertain extent also on an international level. This because it is quite certain that between the
different specialities in the organization, different people have a different understanding of thesame terms and concepts.

6 Concluding remarks
The deliberations during the international meeting can be summarised as shown below and aspresented at the end of the meeting.


RM is an integral part of many geologic disposal programmes, its objectives should be clear
and should have a broad organizational support in order to be successfully applied,

RMS is a process, driven by human intervention, which links information in a tool which
consists of a computer system and aids decision making,The decision to implement a formal RMS is generally an organization-internal decision and
not imposed by the regulator.



Key aspects of RMS are:



RMS is associated with the quality management (QM) (it can either be part of the QM
System, or take an over-arching role),
RMS is linked with an information system/database (knowledge base: KB) and supports
decision making, it is however not a decision making system,

The most challenging aspect seems the abstraction of information coming from various
specialist groups to the succinct requirements that are needed. This is especially the case fordefining lower level requirements. Different organizations developed different procedures foraddressing this, most of which are still under development,The more advanced the programme and thus the more concretely the repository system isdefined the ‚easier" to specify the lower level requirements, it is however useful to start earlywith identifying (and tracking) the upper level requirements,One should remain aware that the purpose of RMS is not developing a complex RMS system,
but should aid ultimately the successful implementation of the geological disposal project

33

("Look before you seek" principle).

34

Appendix 1:
Meeting

RMS Status and Recent Developments Information Exchange

Date:

Tuesday, 26 January 2010

Place:NN hall, Mita NN building, Tokyo, Japan

Participants:

NUMO

Tomio Kawata, Hiroyuki Tsuchi, Katsuhiko Ishiguro, Hiroyoshi
Ueda, Takao Ohe, Satoru Suzuki, Kiyoshi Fujisaki, Hiroshi
Kurikami & others

POSIVA

Tiina Jalonen

SKB

Lena Morén

ONDRAF/NIRAS

William WacquierParsons Brinckerhoff

Henry O'Grady

Nagra

Piet Zuidema

Secretariat

Stratis Vomvoris, Irina Gaus

Tuesday, 26 January 2010
8:50-9:30

Session 1:

Registration

Introduction and Overview (Chair: K. Ishiguro)

9:30-9:35

Welcome and Opening remarks

NUMO (Dr. T. Kawata)9:35-9:50

The management of the geological disposal programme ofJapan

NUMO (Dr. T. Kawata)

9:50-10:05

Expectations with respect to a Requirements Management
System (title to be confirmed)

Session 2:

Prof. T. Ohe, Tokai Univ.;
DTAC1

RMS in different national radioactive waste disposal programmes – status, open issues,
future plans (Chair: S. Vomvoris)

10:05-10:35

NUMO

10:35-11:00

Coffee Break

11:00-11:30

SKB

11:30-12:00

ONDRAF

12:00-13:30

Lunch (Bento Box)

13:30-14:00

POSIVAT. Jalonen

14:00-14:30

Nagra

P. Zuidema

14:30-15:00

JAEA KMS – Overview, knowledge base and KM toolkit

15:00-15:30

Coffee Break1

H. UedaL. Morén
W. Wacquier

NUMO's Domestic Technical Advisory Committee

A1-1

K. HiokiSession 3:
15:30-16:00

RMS in other industries – What can we learn? (Chair: S. Vomvoris)
Application of RMS for the management of major
projects; examples from the Aerospace industry

Session 4:

Open forum and discussion (Chair: S. Vomvoris)

16:00-17:00

Open discussion in all the presentations

17:00-17:15

Wrap-up and end of workshop

A1-2

H. O' Grady

Appendix 2:

List of participants of the open session

First name & Family nameCompany or Institution

1

Tiina Jalonen

POSIVA, Finland

2

Lena Morén

SKB, Sweden

3

William Wacquier

ONDRAF/NIRAS, Belgium

4

Piet Zuidema

Nagra, Switzerland

5

Stratis Vomvoris

Nagra, Switzerland

6

Irina Gaus

Nagra, Switzerland

7

O'Grady Henry

Parsons Brinckerhoff, U.K.

8

Toshiaki Ohe

Tokai University

9

Yasuaki Ichikawa

Okayama University

10 Osamu Tochiyama

Nuclear Safety Research Association

11 Toshinori Sato

Ministry of Economy, Trade and Industry
Agency for Natural Resources and Energy (ANRE)

12 Kenji Miyano

Ministry of Economy, Trade and Industry
Agency for Natural Resources and Energy (ANRE)

13 Masakazu Niwa

Ministry of Economy, Trade and Industry
Agency for Natural Resources and Energy (ANRE)

14 Nagatsu (tbc)

NISA

15 Sumio Masuda

Nuclear Safety Commission of Japan (NSC)

16 Susumu Muraoka

Nuclear Safety Commission of Japan (NSC)

17 Hironori Funaki

Nuclear Safety Commission of Japan (NSC)

18 Shigeyuki Saitou

Japan Nuclear Energy Safety Organization (JNES)

19 Kazuhiko Shimizu

Japan Atomic Energy Agency (JAEA)

20 Hiroyuki Umeki

Japan Atomic Energy Agency (JAEA)

21 Kazumasa Hioki

Japan Atomic Energy Agency (JAEA)

22 Takeshi Senba

Japan Atomic Energy Agency (JAEA)

23 Hideaki Osawa

Japan Atomic Energy Agency (JAEA)

24 Hitoshi Makino

Japan Atomic Energy Agency (JAEA)

25 Motoi Kawanishi

Central Research Institute of Electric Power Industry (Criepi)

26 Michihiko Hironaga

Central Research Institute of Electric Power Industry (Criepi)

27 Tomonari Fujita

Central Research Institute of Electric Power Industry (Criepi)

A2-1

First name & Family nameCompany or Institution

28 Hiromi Tanabe

Radioactive Waste Management Funding and Research Center(RWMC)

29 Kenji Terada

Radioactive Waste Management Funding and Research Center(RWMC)

30 Hidekazu AsanoRadioactive Waste Management Funding and Research Center(RWMC)

31 Hitoshi Owada

Radioactive Waste Management Funding and Research Center(RWMC)

32 Kimitaka YoshimuraRadioactive Waste Management Funding and Research Center(RWMC)

33 Tai Sasaki

Japan Nuclear Fuel Limited (JNFL)

34 Yoshihiro Miyauchi

Japan Nuclear Fuel Limited (JNFL)

35 Tomio Kawata

Nuclear Waste Management Organization of Japan (NUMO)

36 Kazumi Kitayama

Nuclear Waste Management Organization of Japan (NUMO)

37 Hiroyuki Tsuchi

Nuclear Waste Management Organization of Japan (NUMO)

38 Katsuhiko Ishiguro

Nuclear Waste Management Organization of Japan (NUMO)

39 Akio Tamura

Nuclear Waste Management Organization of Japan (NUMO)

40 Hiroyoshi Ueda

Nuclear Waste Management Organization of Japan (NUMO)

41 Kenichi Kaku

Nuclear Waste Management Organization of Japan (NUMO)

42 Takao Ohi

Nuclear Waste Management Organization of Japan (NUMO)

43 Satoru Suzuki

Nuclear Waste Management Organization of Japan (NUMO)

44 Kiyoshi Fujisaki

Nuclear Waste Management Organization of Japan (NUMO)

45 Hiroshi Kurikami

Nuclear Waste Management Organization of Japan (NUMO)

46 Takao Ikeda

JGC Corporation

47 Kiyoshi Oyamada

JGC Corporation

48 Hideki Kawamura

Obayashi Corporation

49 Shoko Yashio

Obayashi Corporation

50 Susumu Kawauchi

MHI Nuclear Engineering, Co. Ltd

51 Shigeki Fusaeda

Science Solutions International Laboratory, Inc.

52 Yuji Morikawa

Web I Laboratories, Inc.

A2-2

Appendix 3:

Presentations

Session 1 Introduction and Overview ..................................................................................................... A3-3
Geological disposal programme in Japan (NUMO)......................................................................... A3-5
Session 2 RMS in different national radioactive waste disposal programmes – status, open issues, futureplans ....................................................................................................................................................... A3-13
1. NUMO ........................................................................................................................................ A3-15
2. SKB............................................................................................................................................. A3-29
3. ONDRAF/NIRAS ...................................................................................................................... A3-45
4. POSIVA ...................................................................................................................................... A3-61
5. NAGRA ...................................................................................................................................... A3-75
6. JAEA........................................................................................................................................... A3-89
Session 3: RMS in other industries – What can we learn?.................................................................A3-103
Application of RMS for the management of major projects; examples from the Aerospace industry(Parsons Brinkerhoff Ltd)..............................................................................................................A3-105

A3-1

Session 1
Introduction and Overview (Chair: K. Ishiguro)

Geological disposal programme in Japan (T. Kawata, NUMO)

A3-3

Geological Disposal Programme
in Japan
Tomio Kawata
Executive Director
Nuclear Waste Management
Organization of Japan (NUMO)
26th January 2010, Tokyo
RMS Status and Recent Developments
Information Exchange Meeting
P.0

Evolution of the Japanese HLW Disposal Programme
R&D
Second Progress
Report (H12)(Technical Reliability)

2030

2020

First Progress
Report (H 3)(Technical Feasibility)

Start of R&D
Programme

2040

H17 Report

2005
2002
2000

2010

Repository Operation
Selection of Disposal Site

Amendment of “Final Disposal Act”,
and Regulation Laws (June 2007)

1992

Commencement of Open Solicitation (Dec. 2002)

1976“Specified Radioactive Waste
Final Disposal Act” (June 2000)

NSC: “Requirements of Geological Environment
to Select PIAs of HLW Disposal” (Sep. 2002)
Establishment of NUMO (Oct. 2000)

Implementation

NSC: Nuclear Safety Commission of Japan

A3-5

P.1

Multi-barrier Disposal System
Engineered Barriers
Natural Barrier

Host rock locateddeep underground

Vitrified
waste

Overpack(steel container)z Immobilize radionuclides

in glass matrix

z Assure extremely low

dissolution ratez Prevent vitrified wastefrom contacting withgroundwater at least
for 1,000 years

z Assure extremely low

permeability to retard
penetration ofgroundwater andBuffermigration of dissolved(compacted clay)
radionuclides
z Provide mechanicalbufferP.2

Typical repository layout
Disposal
panel for
HLW

(HLW/TRU co-location option)

Disposal
panel forTRU waste

Access tunnel
Pit disposal
Hard
rock

Tunnel disposal

TRU waste

HLW

Soft
rock

A3-6

Emplacement ofwaste package

P.3

Three Stages of Site Selection Process(*) This route was added after
Toyo town case

Detailed
Investigation
Areas (DIAs)

Preliminary
Investigation
Areas (PIAs)

Repository
Site (RS)Municipalities
invited by theGovernment (*)

Volunteermunicipalities

Literature
surveyPreliminary
Investigation- Excavation of test
tunnel- Investigation in
the test tunnel- Geophysical survey- Borehole drilling etc.

Selection
criteria

1st
stage

Detailed
Investigation

Selectionof PIAs

Selection
criteria

2nd
stage

Selectionof DIAs

Selection
criteria

3rdstage Selection
of RS
P.4

Topics relevant to the site selection process
By the end of 2006, about ten local municipalities were reported tohave expressed an interest in Literature Survey (LS) in four years
since the start of NUMO’s open solicitation , but none lead to theactual application
In January 2007, Toyo town became the first municipality to submit
an application for LS
Escalation in opposition activities led to the resignation of the mayor
and his loss in the following election
A newly elected mayor withdrew application and the literature
survey for the town was abandoned in May 2007
Reflecting the lessons learnt, METI radioactive waste subcommittee recommended enhancement measures for HLW disposal
program in November 2007
9 Addition of the system where the government can nominate candidate
municipalities for LS
9 Measures to enhance PA and confidence-building activities
A3-7

P.5

Locations of municipalities expressing interest since 2002

Municipalities reported
to have expressed aninterest in Literature
SurveyToyo town
P.6

Country-wide PA Activities
METI* Energy Caravan : 46 times
METI Workshop: 20 times
NUMO Panel-discussion : 46 times
NUMO Workshop: 18 times(FY2007-09)

Panel-discussion
Workshop*METI: Ministry of Economy, Trade and Industry

A3-8

P.7

NUMO’s Basic Safety Philosophy
Safety Principles:¾ Protect human health and the environment present and future¾ Do not impose undue burdens on present and future generations
Basic policy
for promoting understandingof deep geological disposal
Development of social
acceptance

Basic policy
for ensuring safety• Appropriate selection procedureof disposal site
• Appropriate design,
construction and operation of
repository• Appropriate assessment ofsafety• Active seeking ofunderstanding and fostering a
relationship of trust• Measures to reduce publicconcerns
P.8

Report on the
Selection of
PIAs
Design concept
Supporting
Documents

Safety Case 1
NSC:
Nuclear safety Commission

SitingFactors
for DIAs
Report on the
Selection of
DIAs

SitingFactorsfor RS
Report on the
Final Selectionof the Rep.Site

Basic Design &Safety Assessment

Detailed Design &Safety Assessment

Supporting
Documents

Supporting
Documents

Selection of RS

SitingFactorsfor PIAs

Detailed
Investigation

Preliminary
Investigation
Selection of DIAs

Nomination

Literature
SurveySelection of PIAs

Open
Solicitation

Licensing

Stepwise Refinement of the Safety Case

Safety Case 3

Safety Case 2
NSC Basic
Guidelines for Safety
Review

A3-9

NSC Guidelines
for Safety
Review
P.9

Fundamental Implementation Schedule
Amendment to the “Law for the Regulation of Nuclear Source Material, Nuclear Fuel Material and Reactors” (Jun. 2007)
 “Ordinance for the Class1 underground disposal (No.23 of METI)” (Apr.2008)
Report on “ Regulatory Framework for Geological Disposal of HLW” by NISA Sub-Committee (Jan. 2008)

Time

LS PI

Construction

DI

Operation

ClosureApproval for
closure plan

Licensing• Approval of design andconstruction method• Pre-service Inspection• Confirmation of
disposal facilities• Approval of safe operation andmaintenance rules• Waste acceptance inspections• Inspection on physical protection• Periodic inspections of facilities…..

Terminationof project

Final
confirmationof closure

Confirmation ofproject termination• Periodic Safety Review• Monitoring• (Retrievability)
P.10

Close cooperation with R&D organizations
NUMO
Necessary technology based on the progress of
repository programme
R&D Planning
R&D Implementation

Evaluation of achievements

plan etc

outcomes

Fundamental R&D
Coordination council for R&D on
Geological Disposal (METI)JAEA and other R&D organizations
A3-10

P.11

NUMO’s expectations to the requirements management¾ The requirements management is one of the key
components to ensure the safety in thegeological disposal program.
¾ The requirements management provides
effective measures to meet the various
requirements from stakeholders in perspective.
It helps to build their confidence in the program.
¾ As the disposal program continues overdecades, the constraints and premises couldchange. The requirements management should
be dynamically carried out with the long-term
scope.
P.12

Some remarks for the info. exchange meeting
9 What are the lessons learned from experiences ofeach RWM organization or other industries on therequirements management and its operation ineach program?
9 For the confidence building, how to use therequirements management to meet the
stakeholder’s requirements?
9 What are the difficulties to transfer the common
requirements management to the disposal
program? What are the methodologies?
A3-11

P.13

Thank you
for your attention
For further information:www.numo.or.jp/en/index.html

P.14

A3-12

Session 2
RMS in different national radioactive waste disposal programmes – status, open
issues, future plans (Chair: S. Vomvoris)

1. NUMO
2. SKB3. ONDRAF/NIRAS
4. POSIVA
5. Nagra
6. JAEA KMS

A3-13

1. NUMO

A3-15

The requirement management for thegeological disposal programme management
and the development of NUMO-RMS
H. Ueda, S. Suzuki, K. Ishiguro, H. Tsuchi
Science and Technology Department
Nuclear Waste Management
Organization of Japan (NUMO)

26th January 2010, Tokyo
RMS Status and Recent Developments
Information Exchange Meeting
p. 0Contents

1. Objectives and expectations

9 Needs for Requirements Management in NUMO

2. Status of developments and progress
3. Practical experience with application
9 Managing the requirements
9 Requirements Management System of
NUMO

4. Next step

9 Link with KMS and application of R&D outcomes

A3-17

p. 1

NUMO’s expectations to requirements management¾ The requirements management is one of the key
components to ensure the safety in the geologicaldisposal program.
¾ The requirements management provides effective
measures to meet the various requirements fromstakeholders in perspective. It helps to build theirconfidence in the program.
¾ As the disposal program continues over decades, theconstraints and premises could change. The
requirements management should be dynamicallycarried out with the long-term scope.
p. 2

Three Stages of Site Selection Process(*) This route was added after
Toyo town case

Detailed
Investigation
Areas (DIAs)

Preliminary
Investigation
Areas (PIAs)

Repository
Site (RS)Municipalities
invited by theGovernment (*)

Volunteermunicipalities

Literature
surveyPreliminary
Investigation- Excavation of test
tunnel- Investigation in
the test tunnel- Geophysical survey- Borehole drilling etc.

Selection
criteria

1st
stage

Detailed
Investigation

Selectionof PIAs

Selection
criteria

2nd
stage

Selectionof DIAs
A3-18

Selection
criteria

3rd
stage

Selection
of RS
p. 3

Stepwise implementation and regulations
2010

Basic policy for safety regulation

Basic guidelines for safety review

2020

Guidelines for safety review

2000

2030

DIAs

RS

2050

2100

Revise as appropriate

Establish technicalstandards

Application
Implementation
Selection SelectionSelection
PIAs

2033-2038

Safetyreview

Approvalconfirmation

Approval

Approval

Approval

Operation

ClosureEnd of
Implementer’s
Role

LicenseConstruction

p. 4

What is “requirements” considered in NUMO RMS?
The attribution of requirements for the disposal programme.

Stakeholders aspects•Local municipalities/residential
people•Laws/ordinances/guidelines•Authority/Knowledgeable people•Waste producer

Programme aspects•Programme schedule•Policy/concept•Products(documents/works/decisions)•Human resources/Cost•Risk/uncertainty

Quality aspects•Quality control•Specification for design•Indicators and criteria•Practicality of technology•Scientific soundness•Communication•Communication with stakeholders

R&D aspects•R&D issues•R&D schedule

Scope management

Quality management
A3-19

p. 5

What is the requirement management of NUMO?
Programme management

NUMO Requirements management¾Scope management¾Quality management
link

Schedule management

Human Resource management*Terms basically based on PMBOK

Scope Mgt.: To specify the decision/work with requirements at each stage of the
programme. The modification of scope will be carried out dynamically at every
milestone.
Quality Mgt.: To specify the required quality (goal of the work/quality level) at
each stage of programme.
p. 6

Development of the NUMO-RMS• FY2005

Research on RMS initiated using DOORS®

– Organization and description of requirements considered for engineering
requirements• FY2006-07 Development of NUMO-RMS with basic functions for trialuse– Need for a program management methodology for supporting decision-making,schedule management and R&D management in NUMO (NUMO Structured
Approach; NUMO TR-07-02)– The trial RMS tool was developed as a central component of the PMS tool
– The preliminary database was prepared based on requirements derived fromthe H12 report• FY2008-09 Development of NUMO-RMS with fundamental functions
for practical use– Establish the concept for requirements management in NUMO’s program– Providing desired fundamental RMS functions (more user-friendly GUI for input,
search, review and change management)– Preparation of database for the design of disposal system with links to the sitecharacterization process
A3-20

p. 7

Managing requirements

Modeling of requirements management• Procedure for requirements management• Decision-making (selection) and requirements• Repository design and requirements• Requirements and compliance arguments

p. 8

Requirements management in NUMO’s work
• For fundamental decision-making– Siting factors for site selection– Selection requirements for engineering alternatives• For repository design/performance assessment– Specification of safety functions– Consideration of practicality of operation– Design requirements and design indicators• For R&D management– Identifying and prioritizing the targets of R&D on the basis ofrequirements

A3-21

p. 9

Procedure for requirements management
Procedure for requirements management based on PDCA cycle
 Plan: Work/requirements specification phase
Compile, analyze and specify requirements such as constraints, quality
goals and regulations for the geological disposal program Do: Implementation phase
Carry out the principal work of design of the disposal facility, safetyassessment and geological investigations in line with the specified
requirements
 Check: Validation phase
Confirm whether the requirements for each action have been fulfilled Act: Decision-making phase
After fulfilling all the requirements, a decision can be madep. 10Classification of requirements¾Mandatory requirements• Must be fulfilled with demonstrated compliance• e.g. avoidance of significant volcanic activity¾Preferable requirements• Would be better if they are fulfilled, but not essential• Strongly linked to the selection process (sites, design,etc.)• e.g. the longer migration distance for radionuclides ispreferable

Note: Premises, constraints and conditions arealso considered, but they are classified not to therequirements in our system.
A3-22

p. 11

Decision-making and requirements
Site selection is the most important decision-making issue
in the stepwise siting process• In 2002, NUMO published an Information Package that provided
background on the HLW disposal project and initial requirements
for finding a suitable site.
• One of the main documents in the Information Package
addresses “Siting Factors for the Selection of Preliminary
Investigation Areas”.
• Siting Factors can be used to evaluate whether an area hasappropriate characteristics for a repository site and to assist in thedecision of volunteer community as to whether the area would
qualify as a suitable PIA.
• The scientific basis for “the Siting Factors” was published as
NUMO TR-04-04 (“Evaluating Site Suitability for a HLW
Repository”).
p. 12

Siting Factors for PIA Selection
Legal requirements
No record of significant movement in geological formations
Low risk of significant movement in geologicalformations in the futureNo record of unconsolidated Quaternary deposits in the hostformation
No record of mineral resources that are economicallyvaluable in the host formation

Evaluation Factors for Qualification (EFQ)Earthquake, fault activity
Igneous activity
Uplift, erosion
Unconsolidated Quaternary deposits
Mineral resources

Requirementsfrom NSC

Extractionof items

NUMO requirements
Legal requirements for DIA
selection, repository site selection
Practicality of repository
construction, operation

Favorable Factors (FF)
Properties and characteristics
of geological formations
Hydraulic properties
Investigation and assessmentof geological environment
Risk of natural disasters during
construction and operation
Procurement of landTransportation

Development of criteria
for evaluation

Siting Factors

Confirmation
A3-23

13
p. 13

Repository design and requirements• Aims of RM for repository design are to assure implementationof a safe repository with realistic operational technology.
• RM should be based on the safety concept of NUMO (isolationand multibarrier system).
• The requirements will be derived in a traceable manner from“the safety concept”.
• Operational safety through construction to closure and longterm post-closure safety are required. Trade-offs must be taken
into consideration in the design.
• Decision-making on engineering alternatives such asvertical/horizontal emplacement of waste forms and theemplacement technology (e.g. PEM, block assembly) are also
targeted in RM of design requirements.
p. 14

Requirements breakdown structure

Requirements source
Requiredsystemfunctions

Designrequirements

Safety concept
Safety functions

Operational functions

Design requirements*Indicators/standards are involved in design requirements

Organized by requirements breakdown structutre (RBS)

A3-24

p. 15

Rank and contents of Requirement Breakdown Structure
Rank of requirements

Requirements
sourceSource ofrequirements

Legal (laws/regulation)
Demands from local municipalities/people

Concept of thegeological disposal

Isolation (incl. isolation and containment
in IAEA WS‐R‐4)
Multibarrier system

Programconstraints

40,000 units of HLW to be disposed overca. 40 years
Safety functions
Operational functions

Required system function
Designrequirements

Contents (examples)•Design
requirement•Design indicators•Criterion

Requirements for the design of eachcomponent
Indicators and criteria for design
performance
p. 16

Design requirements for overpack
Required function

Design requirements

Safety functions(physical
containment ofradionuclides)

To prevent groundwaterfrom coming into contact
with vitrified waste for a
specified period•Containment of radionuclides in vitrified
waste•Corrosion allowance/resistance•Pressure resistance•Radiation shielding•Radiation damage resistance•Heat resistanceOperational
functions

No significant impact onother engineered barriers•Sufficient internal space•Adequate thermal conductivity•Radiation shielding•Chemical buffering capacity

Technical feasibility of
manufacturing/installation•Manufacturability•Possibility of remote sealing•Possibility of remote emplacement(Based on JNC, 2000; NUMO, TR-04-01)

A3-25

p. 17

Requirements and compliance arguments• The work (design/evaluation) should be carried out to fulfill therequirements.
• Fulfillment of requirements should be argued with complianceshown by a synthesis of supporting evidence.
• Some arguments may depend on the site environment and theengineering alternatives. It is important that specified
requirements include an indication of how compliance can bedemonstrated.

Measures to fulfill therequirement

Arguments

Synthesis of evidence
Evidence
p. 18

Need for NUMO-RMS
Basic concept for NUMO-RMS•Assist requirements management work by NUMO staff throughinformation management•Suitable for the stepwise approach of the Japanese program•“Reactive use (QM)” and “proactive use(Scope Mgt.)”• To assist requirements management work from“work/requirements specification” to “decision-making”• To facilitate access to the information required forwork/decision-making• To record the arguments fulfilling requirements• To record the quality control of information• To record the sequence of decisions/work and ensure
traceability of all changes
A3-26

p. 19

Basic functions of the RMS tool
Record-keeping
The RMS tool records the requirements, constraints,
premises, arguments and related information in a wellorganized structure
Support of decision-making
Ensures no critical requirements are overlooked
Change management
If any changes in requirements and decisions occur, theRMS tool identifies the related requirements anddecisions and alerts the responsible persons
Schedule management
RMS identifies what decisions will be made in future stages
and when/how/by whom the requirements should be fulfilled

p. 20

Next steps
9 Re-assessment of design requirements/designindicators for a specific site using the new RM
methodology
9 Link with KMS and application of R&D results
9 Practical operation of the RMS tool in NUMO’sprogram
9 Application in a quality assured manner

A3-27

p. 21

Use of JAEA-KMS and application of R&D results
RM procedure

NUMO-RMS

Requirements

fulfill
Arguments

Measures for fulfilling
the requirements
Synthesis of evidenceTop-downTop
down
Need for synthesis ofevidence
Attachment of synthesis
documents

Evidence

Bottom-up

Another use case of the outcome of R&D“Argumentation network methodology”
developed in the JAEA-KMS would be useful toprepare the “Arguments” in the NUMO-RMS.

NUMO work and R&D
JAEA-KMS
ANRE R&D
CRIEPI R&D
p. 22

Summary

1. Objectives and expectations
9 Needs for Requirements Management in
NUMO
2. Status of developments and progress
3. Practical experience with application
9 How manage the requirements?
4. Next step
9 Link with KMS and application of R&D
outcomes
A3-28

p. 23

2. SKB

A3-29

RMS at SKB
Status, open issues and future plans
Lena Morén

BACKGROUND

A3-31

SKB’s programmes for nuclear waste• Spent nuclear fuel programme– the development of the RMS was initiated within thisprogram• Loma programme for low and intermediate level waste(both short and long-lived)– will apply the RMS developed within the spent nuclear
fuel program

Spent nuclear fuel programme
Final repository

Transport system
for spent fuelInterim storage facility
Encapsulation plant

Transport system forencapsulated spent fuel• Interim storage facility in operation since 1985
• Application for encapsulation plant 2006
– combined with interim storage facility• Site for final repository selected in 2009 (Forsmark)• Application at the end of 2010

A3-32

Loma - low and intermediate level waste

Transport system

SFR facility
Short lived waste• SFR facility (Forsmark) for short lived waste

Final repository
Long lived waste– Licensed for operational waste, in operation since 1988
– Application for decommissioning waste 2013

• Planning for a repository for long lived low andintermediate level

Facilities applying RMS• New part of SFR facility fordecommissioning waste• KBS-3 repository andrepository facility(this presentation)

A3-33

THE SKB RMS AND ITS STATUS

Development of RMS at SKB• 2001– Design premises for the KBS-3 repository compiled in
one document• 2002-2004 Trial project– the design premises were transferred to a database– the structure of the database was developed• 2005- ongoing activity– requirement management included as an activity within
the spent nuclear fuel programme– routines for writing and determining design premises
developed

A3-34

Purpose• Provide correct and complete design premises for theKBS-3 repository and repository facility• Ensure that the KBS-3 repository and repository facility
conforms to the design premises• Make the basis and motive for the design of the KBS-3
repository and repository facility tracable• Facilitate system understanding and put details in thedesign and design work in their context• Facilitate decission making and avoid mistakes in design,
production and operation• Facilitate development and management

Structure
Waste to be managed
Design principles

Stakeholder

System requirements

KBS-3

MethodGeology and barriers

Sub-system requirements

KBS-3
Engineered barriers
Underground openings

Generic layout
Barrier functions

Currently
suggesteddesignReference design
Reference methods

Design requirements

Other design premises

Reference design

A3-35

Level 1

Level 2

Design premises

SourcesLevel of detailObjectives andprinciples

Laws and regulations
Stakeholder demands

Problem to besolvedPrinciples to apply

Functions of therepository andrepository facility

Laws and regulations
The spent nuclear fuelThe KBS-3 method

Level 3Functions of thebarriers andtecnical systems

Level 4

Properties andparameters to be
designed

The required functions

Premises for thedesignLoad cases from thesafety assessment
Other barriers or parts
Production and operation

Level 5

KBS-3 repository
and repository
facilityEngineered barriers
Systems in thefacility
Components ofbarriers and theirproperties
Systems of the
facility and thierproperties
Methods for
production

ExampleLevel 1 – The post-closure safety of the final repository shall be based on
several barrier functions that are maintained through a system ofpassive barriers.
Level 2 – The final repository shall contain the spent nuclear fuel andisolate it from the biosphere.
Level 3 –The canister shall withstand the mechanical loads that are
expected to occur in the final repository.
Level 4 – Properties that affect the strength of the insert, i.e. the material
properties compression yield strength and fracture toughness (K1C)
and the dimensions e.g. edge distance, shall be such that the copper
shell remains tight with respect to the largest expected isostatic loadin the final repository.
Level 5 – An isostatic load of 45 MPa, being the sum of maximum
swelling pressure and maximum groundwater pressure.

A3-36Requirement attributes• All levels/kinds of design premises– Review status– References– English translation• Level 1, 2 and 3 (Stakeholder, system and sub-system)– Background– Statue, law or regulation– Objectives and guidance (only sub-system requirements)• Level 4 (Design)– Decision maker– Decision document– System number– Verification

Level 5, other design premises - attributes• All– pending: project (from a list) within which the premise is used
• Spent nuclear fuel and systems/parts of the KBS-3 repository
and repository facility– Specifications of data
– Other attributes, same as for level 4 requirements• Design premises from the assessment of the long-term safety– document– comment and guidelines• Design premises from the assessment of the operational safety– pending• Activities in the facility– pendingA3-37

Other information in the database• Instructions– How to create and name projects, folders and modules– How to write, reveiw and determine requirements andother design premises and thier attributes• Links to guiding documents and routines• Concepts and their definitions• Decisions– Links to project decisions– Links to protocols

KBS-3
KBS-3
repository
repository

Structure of database
Concepts
Conceptsand
andinstructions
instructions

Instructions
Concepts

Decisions
Decisions

DecisionsProtocols

DesignDesignpremisespremisesRequirements
Requirementsand
andspecifications
specifications

Stakeholder
SystemSub-systems
Sub-systems
Sub-systems
Sub-systems
Sub-system
Sub-systemdesigndesignprojects
projects

CanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanisterCanister

Other
Otherpremises
premises

Stakeholder
Stakeholder
Stakeholder
Stakeholder
Spent
fuel

16

A3-38

Design requirements
Referencedesign
designReference
ReferencedesignWrite, review and settle requirements
Responsible
ExpertGather data
and writereq.

Changeexisting req.

Suggestion

Revise req.

No
Review by
expterts

Reviewer

Approved?

No

Yes

Conflict ofinterests?
Yes

Reviewed

Determinepriority

Decision-maker

No
Review
regardingcompleteness

Yes
Approved?

Determined

17

Current status of the database• Level 1-3– Determined versions of all modules with stakeholder, systemand sub-system requirements– Reviewed by SKB’s legal advisors and technical experts– Sub-system requirements are currently up-dated• Level 4 and 5– Design requirements for all barriers of the final repository andall systems in the facility – not formally determined– Reference design specifications – not formally determined• Other design premises– Determined version of design premises from the long-term
safety assessment– Specification of spent fuel to be deposited – not formallydetermined

A3-39

Development since last meeting• Organization for writing and determining high level
requirements settled• Routine for technique decisions settled• High level requirements determined• First versions of lover level requirements and otherdesign premises in the database• Projects that shall apply RMS determined – in the next
phases of these projects RMS shall be incorporated tothe project plans and recourses allocated• Documents in which the requirements are presented
to authorities settled

Requirements and documents

Document database

Requirement database• Relations between different kindsof requirements and designpremises• Presentation of requirements anddesign premises to stakeholders,designers and contractors,• Links to documents containing
requirements and design premises• Explanation and background• Links to decisions and minutes• Used by SKB as a tool to manage
requirements and design premises

A3-40• Further instructions

OPEN ISSUES

Requirement databaseGet requirements/premises
Write new requirements/premises

New specification or
guiding document

Reviewrequirements/premises

Review of document

A3-41

Save baseline
Check consistency

Appoved document

Stakeholder
System and sub-system

System and sub-system

Design requirements
and/or design premises

23

Information to be included in the database• Design basis events from the operational safetyassessment• Activities in the facility – the main activities are– Rock construction works– Deposition works – installation of buffer and backfill,deposition of canister– Investigations of the rock

• Verification of the requirements

A3-42

Open issues• Verification– which information to include– how to include the information on the different levels ofdetail• Activities– links between activiteis and technical systems– possibilities to use the information in the database forsimulations• Requirements imposed on the operation of the facilityby the engineered barriers and undergroundopeniengs – Operational limits and conditions (STF
document)

A3-43

3. ONDRAF/NIRAS

A3-45

How ONDRAF/NIRAS approaches RMS
Framework & Key Elements

W. WacquierTokyo 26 January 2010

How ONDRAF/NIRAS approaches RMS
Part 1: Framework & Key Elements• Objectives of the presentation:• Give a global overview of the safety and feasibility
strategy developed at ONDRAF/NIRAS• Provide a description of the safety and feasibility
assessment methodologies currently developed toemphasize on the key data (link RMS)

2How ONDRAF/NIRAS approaches RMS

A3-47

Tokyo 25-27
January 2010

How ONDRAF/NIRAS approaches RMS
Part 1: Framework & Key Elements• Safety and Feasibility Strategy• Feasibility Assessment Methodology• Safety Assessment Methodology• Conclusions

3

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

How ONDRAF/NIRAS approaches RMS
Part 1: Framework & Key Elements• Safety and Feasibility Strategy• Feasibility Assessment Methodology• Safety Assessment Methodology• Conclusions

4

How ONDRAF/NIRAS approaches RMS

A3-48

Tokyo 25-27
January 2010

Safety and Feasibility Strategy: iterative
process guiding repository development
The Safety and Feasibility
Strategy aims to:• Support development of any
Safety and Feasibility Case
(SFC) that is to be presented tothe authorities at key decision
points• Develop the safety concept anddesign of a geological repository• Acquire evidence, throughassessments and arguments, toshow that the proposed disposal
system is safe and feasible
5

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

SFC1 planned for 2013
Objective SFC1: Demonstrate that
The disposal system is able to ensure long-term
safety while being feasible (no major flaw)
in order to support a « go for siting » decision
Outcomes:• Description of a reference solution(level of conceptual design)• Demonstration of its long term safety and its feasibility(substantiation of the safety & feasibility statements)

6

How ONDRAF/NIRAS approaches RMS

A3-49

Tokyo 25-27
January 2010

Boundary conditions
to take into account
ONDRAF/NIRASWorking hypotheses> Solution on national territory> Disposal in deep geological formation> Potential HR limited to argillaceous formations> Argillaceous formations: poorly indurated clays> Implementation ASAP (based on waste
availability and scientific, technological, societal
and economic factors)> Conventions & directives (IAEA Safeguard issues)

International framework > General texts (ICRP, IAEA, …), …
Belgian and regulatory
framework> Laws (Well-being at work, …)> Royal Decrees (H&S in mines, Prot. ionising rad.)>…

Institutional policy

Recommendations made by competent authorities
but not yet in the regulatory framework> AFCN/FANC: Technical Guide Geological Disposal

Other stakeholder
conditions

Belgian « non-institutional » stakeholder or
foreign institutional stakeholder> Currently no conditions

7

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

The 9 Strategic Choices of
ONDRAF/NIRAS
•
•
•
•
•
•
•
•
•

8

Boom Clay = reference; Ypresian Clay = alternative
Materials & implementation shall not unduly perturb safetyfunctions
EBS designed to provide complete containment during thermal
phase (heat-generating waste)
Waste types divided into groups, emplaced in separate sections
Repository construction and operation ASAP, but taking due
account of scientific, technological, societal and economic
considerations
Disposal galleries, repository sections and repository closed ASAP
Preferences for permanent shielding of wastes and minimisatonof underground operations
Preferences for materials & implementation procedures for whichbroad experience and knowledge already exists
Repository planning shall assume that post-closure surveillance
and monitoring will continue for as long as reasonably possible
How ONDRAF/NIRAS approaches RMS

A3-50

Tokyo 25-27
January 2010

The boundary conditions and strategic
choices are translated into requirements••••

Requirements are identified in a top-down mannerand organised in a structured « tree »Top level requirements are expected to be stable
Requirements = safety and feasibility statements
The statements:• Definition System Statement: The proposed disposal system isproperly defined (i.e. waste) and its development has been guided bya well-defined and rational step-by-step safety strategy• Safety Statement: The proposed disposal system provides passive
long-term safety if implemented according to design specifications.
• Feasibility Statement: The proposed disposal system can beconstructed, operated and progressively closed taking into accountoperational safety issues and with adequate funding• Uncertainty Statement: The residual uncertainties related to the
proposed disposal system can be adequately dealt with in future
programme stages

9

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

System Development - Safety concept
The passive long-term safety elements
Engineered
Containment Phase (C)Supercontainer

System Retardation Phase (R)R1: Limit contaminants release
R2: Limit water flow
R3: Retard contaminant migration
Waste Forms, EBS, NBS

Geological Isolation phase (I)
NBS

Thermal phase
3
10

4
10

5
10

6
10

Time after closure [years]
10

How ONDRAF/NIRAS approaches RMS

A3-51

Tokyo 25-27
January 2010

System Development - Repository Design
Development as far as is necessary> Layout> Description offacilities & key equipment(functions)> Material Specification sheets> Storyboard> Potential incidental/
accidental situations& mitigation> Cost assessment> Layout refined (site)> System & components
further detailed

11

How ONDRAF/NIRAS approaches RMS

Full technicalspec. ofcomponents

Tokyo 25-27
January 2010

Repository design
Current design
Depth: 200 m (“Soft” Clay)
Separated sections for B&C
Access Gallery  6m
Disposal Galleries> Fishbone>  3m x 1000 m (max)Schedule:> Construction: 2025
> Operation: 2040

12

How ONDRAF/NIRAS approaches RMS

A3-52

Tokyo 25-27
January 2010

Safety Functions implied by thestrategic choices for Supercontainer
LT Safety Functions< Thermal phase

Components

LT Safety Functions> Thermal Phase

R1 (Main)
C(Main)
Prevent
water
R2 & R3 (Contribute)
Overpack
contacting the waste
Concrete Buffer
C (Main) - Provide
R2 & R3 (Contribute)/ Fillerfavorable chemical env.
Envelope
C (Contribute) – Delay R2 & R3 (Contribute) –income of water & Delay income of water
aggressive species
Waste Form

Backfill & Lining
Host Rock& overlying layers

13

I (Main)

R2 & R3 (Contribute)
I (Main)
R2 & R3 (Main)

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

How ONDRAF/NIRAS approaches RMS
Part 1: Framework & Key Elements• Safety and Feasibility Strategy• Feasibility Assessment Methodology• Safety Assessment Methodology• Conclusions

14

How ONDRAF/NIRAS approaches RMS

A3-53

Tokyo 25-27
January 2010

Feasibility Assessment Methodology• Objectives:
•
•
•
•

15

Identify potential remaining uncertainties
Define and prioritise B&C feasibility programme
Present a reference solution
Defend the reference solution by supporting the
Feasibility Statements by strong arguments in order todemonstrate that is technologically (Engineering &Op. Safety) and economically feasible to construct,
operate and close a repository (i.e. no major flaw)

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

Feasibility Assessment Methodology:
Iterative process structured in 3 steps

16

How ONDRAF/NIRAS approaches RMS

A3-54

Tokyo 25-27
January 2010

Step 1 - Functions, Criteria & Open Questions> Statements to demonstrate feasibility
Feasibility Statements (equivalent to requirements):> organise in a tree structure> derive from safety concept in a top-down approach> cover all activities (removal primary package -> institutional control)

Design Function:> identify for lowest level of the feasibility statements> caracterised by criteria allowing to:- evaluate if the feasibility statement (requirement) will be met- identify potential open questions- specify a specific design (ref. or variants)

17

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

Step 1 - Functions, Criteria & Open Questions> Top levels statements

FS The proposed disposal system can be constructed, operated and progressively
closed taking into account operational safety issues and with adequate funding

FS 1 The assessment
basis and feasibility
assessment provide
evidence of theengineering
practicality of the
proposed disposal
system18

FS 2 Health & Safety andEnvironmental issues, as
evaluated in feasibility
assessment, can bemastered, taking into
acccount all relevant
uncertainties

FS 3 The costs for theconstruction, operationand closure of therepositoy, as calculated
in feasibility assessment,
can be covered withadequate funding

FS 4 Quality
assurance procedures
have been applied thatfavour confidence inassessment basis
development and in thefindings of feasibility
assessment

How ONDRAF/NIRAS approaches RMS

A3-55

Tokyo 25-27
January 2010

Step 1 - Functions, Criteria & Open Questions> Identification of design function
Feasibility Statement> Feasibility Statement
Design Function / Subfunction> Design Function> Description> TypeCriteria> Criteria> Requested Level> Design Type- Reference Design- Variant Design> Flexibility> Current Level> Validation Mode
> Argumentation> Dependencies> Conflicts

Open Question> Way Forward> Open Question- Who> Priority- How- Impact on Safety Concept- When- Level of uncertainty> Status- JustificationHow
ONDRAF/NIRAS
approaches
RMS
Tokyo 25-27- Priority

19

January 2010

Step 1 - Functions, Criteria & Open Questions> Completeness check• Storyboard (chain of events):••••

identify if no steps/activities are missing
identify if all significant open questions are identified
help to clarify and take assumptions
Set of information:• Step – Which action is performed?
(e.g. retrieval of primary waste package)• Equipment or system – How is the action performed?
(e.g. truck, tilting system)• Location – Where is the action performed?
(e.g. reception hall)• Next step – What is the next action?
• Time – How long does the action last?
• Possible incidents/accidents – What if scenarios• Measures for quality control• The link with design functions• state-of-the-art (relevant best proven practices)20

How ONDRAF/NIRAS approaches RMS

A3-56

Tokyo 25-27
January 2010

Step 2 – Prioritisation
Prioritise Open Questions & Define R&D studies
Potential impact
on safety concept

Priority Medium

Priority High
Focus for SFC-1

ReduceUncertainties

Define R&D
Programme

Priority Low

Priority Medium

Optimise
the Design

Identify mostappropriate alternative

High impact

Low impact

Low(High confidence)

High(Important doubt)

Level of uncertainty to solve the issue

21

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

How ONDRAF/NIRAS approaches RMS
Part 1: Framework & Key Elements• Safety and Feasibility Strategy• Feasibility Assessment Methodology• Safety Assessment Methodology• Conclusions

22

How ONDRAF/NIRAS approaches RMS

A3-57

Tokyo 25-27
January 2010

Safety Assessment methodology
Development of scenarios & ass. cases

23

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

Safety Assessment methodology
Data governing evolution of system• Diversity of data representing safety statements governing
evolution of disposal system given in the form of• Source range = basic range outside of which parameter value
is unlikely to lie (min, max, (pdf))• Expert range = realistic range within which parameter value is
expected to lie (min, max, (pdf), best estimate)• Considering phenomenological uncertainties• Upscaling (lab to in-situ)• Evolving conditions (e.g. climate evolution, volcanism)• Transferability (applicability in a larger zone)• A data clearance process will be developed to « freeze »data for safety assessment (traceability)• Treatment of other uncertainties (model, scenario) is underdiscussion
24

How ONDRAF/NIRAS approaches RMS

A3-58

Tokyo 25-27
January 2010

How ONDRAF/NIRAS approaches RMS
Part 1: Framework & Key Elements• Safety and Feasibility Strategy• Feasibility Assessment Methodology• Safety Assessment Methodology• Conclusions

25

How ONDRAF/NIRAS approaches RMS

Tokyo 25-27
January 2010

Conclusions• Safety and Feasibility assessment
methodologies developed based on thestrategy• Requirements are managed through the safety
and feasibility statements• In the Feasibility assessment methodology,
statements are further derived into functions
and associated criteria to demonstrate thefeasibility

26

How ONDRAF/NIRAS approaches RMS

A3-59

Tokyo 25-27
January 2010

4. POSIVA

A3-61

Requirements Management System
in Posiva
Status, Open Issues and Future Plans

Tiina Jalonen

1

Preparation - 40 years’ effort

2020

Start of disposal

Test operation and commissioning

2018

Application for
operation license

Construction of disposal facility
Application for
construction license

2012
Construction of ONKALO andconfirming investigations at Olkiluoto

2001

Site selection

Decision in principle by
Government and Parliament

VLJ-repositories
VLJ-repositories

Site
investigations

KPA
KPA -Spent-Spent fuelfuel storage
storage
Government’s decision on
objectives and timetable

1983
1978

Start of feasibility studies of geologic disposal

Tiina Jalonen

A3-63

INDEX

2

BackgroundLong-term Isolation from the Nature (KBS-3)

Tiina Jalonen

INDEX

3

Tiina Jalonen

INDEX

4

Background
Multibarrier principle







The flow rate of thegroundwater in bedrock isminor and slow.
The groundwater found deepin the bedrock contains no
oxygen and has no impact
on copper.
The backfill material
expands and prevents any
water movement around thecontainer.
The stone type of the final
repository almost completely
prevents water movement,
and thus all the material willvirtually stay in their place inthe bedrock.

A3-64

Deep repository

Personnel and ventilation shafts

Canister shaft
Disposal tunnels (-420 m)
Access tunnel
Technical Rooms(-437 m)Pumping Station

Tiina Jalonen

INDEX

5

Posiva’s RMS Project The objective of the project has been to design,
implement and introduce a systematic process andan information system to manage the requirements
related to the geological disposal of spent nuclear
fuel in Finland.

Tiina Jalonen

A3-65

6

Objectives 1/2
 The desired result of the project is an information
system with a database which Includes all the significant requirements, the reasoning
underlying them, and the existing specifications to fulfil them
 Enables an easy review of compliance between separate
specifications and requirements

Tiina Jalonen

7

Objectives 2/2
 The desired result of the project is an information
system with a database which
 Contains information of dependencies between requirements
 Enables a systematic review and documentation of influence
derived from alterations in requirements
 Enables implementation of requirements management as
part of day-to-day operations within organisation

Tiina Jalonen

A3-66

8

Developing the RMS
 The project and the project group were set up in 2006
 The project group consists of the project manager Juhani
Palmu and representatives from different areas – disposal
plant design, long-term safety, ONKALO construction andsafety/quality control

 The software system was evaluated and selected
 DOORS (Telelogic)

 Co-operation & consulting partner was selected (Eurostep Oy)

 The structure and the contents were defined (3rd Qtr,
2007)
Tiina Jalonen

9

System Structure
Level 1 - Stakeholder requirements -Legislation, decisions by theparliament, guides, owners

Level 2 - System requirements-

The KBS-3 concept

Level 3 - Sub-system requirements Level 4 - Design requirements

The role of the key KBS-3
components-

Detailed design req. of
the key components

Level 5 - Design specifications Constraints-

Reference design

Things that can’t be designed/changed
like the site properties (salinity
etc.)
Tiina Jalonen

A3-67

10

System Structure – a view of the Database

VAHA – Vaatimusten Hallinta – Requirements Management
Tiina Jalonen

11

Defining the requirements 1/2


The project team gathered the Stakeholder
requirements (L1) and the System requirements (L2)
3rd Qtr 2007

A person responsible for gathering the requirements
for each sub-system (L3) was nominated






Canister – Tiina Jalonen, Development manager
Buffer – Keijo Haapala, Development engineer
Backfill & Closure – Johanna Hansen, Development
Coordinator
Technical facilities – Petteri Vuorio, Design engineer
Technical systems – Pasi Mäkelä, Design engineer

Tiina Jalonen

A3-68

12

VAHA – Implementation with DoorsVAHA ≈ Vaatimusten Hallinta – Requirements Management

Tiina Jalonen

13

Defining the requirements 2/2
 Gathering existing requirements for levels 3-5 in eachsub-system group was done during 2007
 10/2007 =>: Specifying the structure and the contents
and defining dependencies for the requirements
management system

Tiina Jalonen

A3-69

14

Status 1/2
 Current status: appr. 1500 requirements andspecifications gathered The following requirements have been compiled andapproved in the system stakeholder requirements system requirements
 sub-system requirements

canister sub-system requirements (L3) and design
requirements (L4)backfill sub-system requirements (L3) and design
requirements (L4) The buffer requirements have been compiled but noconsensus has been reached in the approval process
Tiina Jalonen

15

Status 2/2
 Doors Web Access (DWA) was launched into
production in January 2009. The new system will
enable external parties (consultants and the Finnish
regulatory authority STUK) to access the RMS
system remotely

Tiina Jalonen

A3-70

16

VAHA – Doors Web Access (DWA)

https://rms.posiva.fi/dwa
access with the SecurID authentication key delivered by
Posiva & TVO

Tiina Jalonen

17

Open issues
 The sub-system requirements that have been
compiled but need to be re-organised and approved Technical facilities Technical systems
 new sub-systems Transportations and Operations

 Actual verification of the requirements andspecifications
 Some demonstrations done, some planned

Tiina Jalonen

A3-71

18

Future plans The existing sub-system requirements will be linked(connections defined) and specifications will be
added Organisational issue: the Posiva Safety Unit will be
the owner of the RMS in future The change management process will be rehearsed

Tiina Jalonen

19

VAHA Change Management Process
Requirement
ApprovalManagement
Group

Requirement
Prio risation

TKS Group

Requirement Approval

Reviews andcomments

Safety GroupYes

Sub-systems,
persons in charge

ChangeProposalRequirement
checking

Expe rt Groups(internal/external)

Requirement
Conflict

No

ChangeActivation in
VA HAReviews andreports.

DOORS
System Admins

Requirementchange*) orchange proposal

Proposal

CheckedApproved*) Change = additon, deletion orcontent change

Tiina Jalonen

A3-72

20

Traceability Views

A3-73

Tiina Jalonen

21

Tiina Jalonen

225. Nagra

A3-75

Requirements
management at Nagra(Day 1 – Session 2)
January 2010

Background - The Swiss Waste
Management Programme

A3-77

Swiss waste management concept

Two repositories:
 Spent Fuel (SF), vitrified high level waste (HLW) ➙ HLW repository
 Long-lived intermediate waste (ILW/TRU) ➙ HLW repository (co-disposal)
 Low and intermediate waste (L/ILW) ➙ L/ILW repository
3210110/Zu

Requirements Management Nagra_210110

Time schedule for repository for SF/HLW/LL-ILW

4210110/Zu

Requirements Management Nagra_210110

A3-78

HLW-repository: Project Opalinus Clay (Zürcher Weinland)a solid basis

5210110/Zu

Requirements Management Nagra_210110

30 years of research and development
 the scientific-technological basis is available and accepted the inventory of possible host rocks in Switzerland has
been evaluated the demonstration of disposal feasibility for HLW repository
for Opalinuston in Zürcher Weinland has been accepted in2006 by federal government(for L/ILW: already accepted in 1988)

 important strategic decisions have been taken
Æ How to implement has been clarified

The scientific basis is available and accepted
6210110/Zu

Requirements Management Nagra_210110

A3-79

Now: where to implement?
A stepwise site selection procedure
Sectoral Plan 'Geological Repositories' (land use planning law) Part 1: Development of concept ( - 2008)- Aims, boundary conditions- Procedure (steps, role/responsibilities of stakeholders, products)- Criteria (safety/feasibility, land use planning, socio-economic issues)

 Part 2: Implementation (2008 - ~ 2016?)- 1st stage (2.5 a): identification of potential regions (long-term safety &engineering feasibility Æ geology)- 2nd stage (2.5 a): within potential regions: identification of sites (land use
planning, environmental impact, … Æ surface infrastructure, provisionalsafety analyses) & selection of 2 sites for more detailed evaluation- 3rd stage (2.5 – 4.5 a): field investigations, selection of 1 site Æ generallicence (as part of nuclear energy law)7210110/Zu

Requirements Management Nagra_210110

Proposed siting regions

 are result of systematic application of requirements of Sectoral Plan do consider the geological possibilities of the whole of Switzerland
 are derived in a systematic, step-wise narrowing-in process based onsafety and engineering feasibility
8210110/Zu

Requirements Management Nagra_210110

A3-80

Requirements management
at Nagra

Goals for Nagra’s requirements management system
Major goals Nagra wants to have a complete overview on all relevant requirements(compilation of requirements)
 For each of the issues at hand, Nagra has to ensure that all relevant
requirements are considered (specification of requirements)

Operational goals
 Facilitate repository development (incl. transparency for communication withstakeholders) Facilitate decision making (clarify objectives)
 Ensure traceability of decisions (motivation for decisions) Ensures continuously updated basis (and helps keeping track of changes)

Thus, the requirements management system …
 … has to contribute to ensuring safe repositories
 … should provide confidence to the stakeholders involved (Nagra, other)

10210110/Zu

Requirements Management Nagra_210110

A3-81

Framework
 Origin of requirements Æ compilation of information-

Laws, ordinances, regulatory guidelines, stipulations,…
Instructions by owners of Nagra (NPPs, Federal office of health)
Science & technology
Authorities' expectations (recommendations, …)Expectations from scientific community & public Using requirements Æ specifications & information for …
- „Hardware“- Facility design- Development of engineered barriers

11

Planning of field investigations
Documents for decision-points, licensing
Development & update of RD+D programme
Development & update of waste management programme
Update of cost study
Consultation on revisions of laws, ordinances, regulatory guidelines, etc.
…
210110/Zu

Requirements Management Nagra_210110

Requirements Management is part of Nagra‘s (Q)MS Is part of strategic planning (formal process) with periodic
check-points
 Has direct links to projects (input to development of project
specifications / boundary conditions for project)
12210110/Zu

Requirements Management Nagra_210110

A3-82

… is also part of (formal) interaction with authorities
 The different steps: proposal by Nagra Æ presentation /discussion with authorities Æ finalisation- Definition of requirements & boundary conditions (linked tooverall objectives)- Development of alternatives, incl. justification- Selection of alternatives to be developed in more detail, incl.
justification- Evaluation of alternatives

13210110/Zu

Requirements Management Nagra_210110

Basic structure of Nagra’s RMS
1 For which reason?
-

Laws, ordinances, regulatory guidelines, stipulations
Instructions by owners of Nagra
Science & technology
Authorities‘ expectations
Expectations from scientific community & public

2 What requirement? (hierarchical structure)-

Aim / purpose: Principles & functional requirement for all stages in life-cycle
Relevant system-properties that enable fulfilment of principles & functional requirements andspecific requirements (for all stages in repository life-cycle)
Specifications (layout, material, processes)

3 For which element? (hierarchical structure)-

Waste management concept
Repository concept (for all stages in life-cycle)
Concept for HLW & L/ILW repositories
Geological barrier (incl. geological situation); engineered barriers; detailed components

4 When?
-When (and at what level of detail) must compliance with requirement be reached?

5 For which (alternative) system?
14

210110/Zu

Requirements Management Nagra_210110

A3-83

Information flow in Nagra’s RMS
Implementation Framework

Types of Requirements

Legal, Regulatory and Policy Requirements

System Requirements(principles of design)

Technology and
SafetyRequirements

Concept Design Requirements

PublicExpectations

Progresss of Project(performance requirements)

Level of Detail

Waste Producer
Requirements

Functional Requirements

Authorities'
Recommendations(sub-system requirements)

System Design Requirements(specifications)

Verified design(demonstration)

15

210110/Zu

Requirements Management Nagra_210110

Hierarchical structure of requirements (I)2What requirement?

2.1 Identify principles and functional requirements (objective/motivation)
2.1.1 Waste management programme
2.1.2 Long-term safety
2.1.3 Engineering feasibility (construction, operation, closure)

2.2 For the various system elements / components (see 3): Identify properties(Æ indicators) that contribute to fulfilment of principles and functional
requirements
2.3 Define requirements for these properties to ensure effectiveness ofelements / components
2.4 Define specification for system elements / components, so that
requirements are fulfilled
p.m.: associated attributes





16

type of requirement (limit, target, optimisation, issue)level of detail for demonstration (concept, …, detailed demonstration)
milestone for fulfilment of requirement
etc.

210110/Zu

Requirements Management Nagra_210110

A3-84

Hierarchical structure of requirements (II)3

For which element?

3.1 Waste management concept (wastes, time plans, types ofrepositories, …)

3.2 General repository concept (relevant to all types of repositories)
3.3 HLW repository-

The different elements / components of repository (hierarchical)
For the different phases of the repository (construction, operation,
closure, post-closure)

3.4 L/ILW repository-(details as in 3.3)

3.5 Combined HLW & L/ILW repository-

17(details as in 3.3)

210110/Zu

Requirements Management Nagra_210110

ExampleRelevant systemelements /components

Question

AnswerIdentify principles
and functional
requirements

Long-term safety:
Containment ofradionuclides
SF/HLW Canister

Identify relevant
property of systemelements

Life-time

Define requirementsfor propertiy(Æindicators)≥ 1000 years

Specification ofsystem elements /components

18210110/Zu

Canister design
specification (material
Æ corrosion rate,
thickness)

Requirements Management Nagra_210110

A3-85

Porewater
chemistryRequirements Management: Status
 Requirements Management is a process within Nagra‘s (quality)
management system since several years Requirements Management has been used in several key projects(Æ formal reports), especially:- Wellenberg site investigation (1997-2000)- Waste management programme (2006-2008)- Site selection process: proposal of siting regions (2003-2008,
continuing) Structure & process of requirements management has developed(evolutionary process, still changing); development will continue Requirements documented in several external reports and internal
databases (File Maker Pro, EXCEL, …)
 IRQA has recently been chosen as standard software (based on
structured evaluation process)19210110/Zu

Requirements Management Nagra_210110

Conclusions
 Requirements Management is a process to derive and apply
requirements Æ consideration of overall objectives & overall context
is important) Requirements Management is part of the organisation’s culture: It
serves to define objectives, helps to evaluate whether objectives are
met and does this in a traceable manner to make the quality visible
 This requires anchoring the RMS within the management system of
the whole company & its consistent application in all important
projects
 A broad and appropriate structure of the RMS with emphasis on the
broad objectives is of key importance The major difficulty encountered up to now is related to the
documentation of requirements
Presently, the requirements are stored in more than one database –while their underlying scientific basis is documented in several formal
reports
20

210110/Zu

Requirements Management Nagra_210110

A3-86

Thank you!

A3-87

6. JAEA

A3-89

JAEA KMS

Overview, Knowledge Base and KM Toolkit
RMS Status and Recent Developments
Information Exchange Meeting
Tokyo, Japan
26 January 2010
K.Hioki, H.Osawa, T.Semba, H.Makino
Knowledge Management Group
Japan Atomic Energy Agency
0

Advanced KM is a requirement not a luxury¾ Total inventories and rates of production of
information and data are continuing to expand
exponentially: processed knowledge is failing tokeep up¾ Traditional management systems have failed
completely...
...but resulting lack of overview means that
this has not been recognised in many cases

A3-91

1

The Yucca Mountain Project

http://www.gao.gov/new.items/d04460.pdf

estimated
to exceed
30 million
pages

2

In Japan, major projects running in parallel...
¾ Near-surface facilities operating at Rokkasho and interim-depth
repository for higher activity waste in preparation for licensing¾ Deep repositories for HLW & TRU waste to be implemented
following response to call for volunteers¾ Integrated concept for industrial and research wastes indevelopment¾ Extensive supporting R&D, including 2 URLs

Overview of facilities for
wastes from nuclear
power production
A3-92

3

...with a limited (and aging) work force¾ Over the last 2 decades, key integration and overview
tasks have been carried out by teams whose experiencehas grown over that period...these are now completely overloaded...and most experienced members are nearing retirement

Geological disposal (HLW/TRU waste) timeline
H3(1991)

H12(2000)

H17(2004)

Licensing(2030s)H22(2009)

4

Management of tacit knowledge
Recognised to be a critical resource, which is captured using bothtraining methods (both traditional and advanced ) and knowledge
acquisition and capture within expert systems
19 Japanese organisations are members of the ITC
Tacit knowledge is captured in theexpert system modules used inseveral applications

Senior staff and “young generation”
work together in training courses
and brainstorming exercises
A3-93

Control shell(“mother”)

Operational
functions(“child”)

5KMS development: background¾ From a review of international experience (alsooutside the radwaste business), major problems
with developing and implementing advanced KMS
tools were identified as:¾ establishing communication between KE systemdesigners (IT experts) and knowledge producers /users (extremely diverse, multidisciplinary)¾ Insufficient use of capabilities of modern computing
systems

6

KMS development: approach¾ Specifically to address the identified concerns:¾ radwaste generalists learned to use KE tools and took
over the job of KM system design (with support of IT
experts only where needed)¾ recent advances in computing systems (hard- &software) were fully utilised and component systems
were continually tested for applicability and userfriendliness¾ tools facilitate dialogue with users and feedback serves
to drive further improvement and tailoring to specific
needs
A3-94

7

KMS development process¾ Despite initial scepticism, the JAEA approach has
resulted in development of a KMS which isincreasingly accepted throughout the Japanese
programme:¾ the KMS team are capable of communicating with all
knowledge producers and users¾ development focuses on benefits to all involved, as thisis the key to acceptance¾ tools are being tested by user groups and madeavailable as soon as possible

8

Structure and components of the KMS
Review
Board

Knowledge Office•Strategy/approach for Knowledge Management•Executive analysis/evaluation•Toolkit development•Quality management

METI
Coordination
Executive
Relevant R&D
Organizations

Staff

Training
Users• Implementer• Regulatoryorganizations• Experts• Otherstakeholders incl.
policy makers,
general public,etc.

Communication
Interface
User-friendly
knowledge service
Requirements /requests

Japaneseradwaste
Knowledge Base

Long-term program
goals

Key gaps in
Knowledge Base

Focused productionof new knowledge

Anticipating
requirements /knowledge

Think tank-Space forInnovative Knowledge
Creation

A3-95

R&D
Sectors
Factory ofKnowledge
Production

Autonomic
Knowledge
generation

World
Knowledge
Base Web9

Argumentation Modelor RMS

JAEA Knowledge BasePartner
Knowledge intranets

stakeholders•

Project
Knowledge

World
Knowledge internet

AssociatedKnowledge

The JAEA KB is the subset of world knowledge that contributes todevelopment of geological disposal projects in Japan. Because of the wide
definition of the “safety case”, most of this can be structured by associatedargumentation models or requirements management systems (RMS):
however, closer to implementation a wider Strategic Environmental
Assessment (SEA) may be considered(http//www.jaea.go.jp/04/tisou/kms/pdf/sc_ws_02.pdf)
10

Illustration of argumentation model～

The safety case justifies proceeding with the repository project at a particular programme milestone.

Sub-claim
Counter argument
Argument

Lifetime of the overpack is more than the desired designing value.
Corrosion
allowance morethan the corrosion
depth which willprospective during
the required period.
The overpack willkeep the enoughstrength during therequires period.

We can makeoverpacks asplanned using thecontemporary
techniques.

It has possibilities that thecorrosion rate will increase& the sealing performance
will fade away at an earlypoint.
It has possibilities that the
overpack will be passivatedresulting the localized
corrosion & the sealing
performance will fade away
at an early point.
It has possibilities & thesealing performance will
fade away at an early pointdue to the stress corrosion
cracking.
It has possibilities & thesealing performance will
fade away at an early pointdue to hydrogen
embrittlement.
It has possibilities that thesealing performance will
fade away at an early point
because of the corrosion
which is due to the residual
oxygen in the closed
repository.
It has possibilities that thecorrosion will be
accelerated due to themicrobes.

Argumentation based on
experimental data
The general corrosion rate in the
reducing environment is less than
the supposed value -0.01mm/y.
CQ1: Is the experimental
system relevant to thatconsidered in the repository?

CQ2: Is the experimental
dataset rigorous and quality
assured?

CQ3: Are there any
contradictory experimental
data?
CQ4: Are the boundary
conditions well enoughestablished for the applicationconsidered?
CQ5:Are there any critical
simplifications or assumptions
required for its application?

CQ6:What are the errors anduncertainties associated withthe data used?

A3-96

Knowledge Note
・Overview of evidence
・Reference・Additional informationetc.

If the overpack is put
in touch withpowdery reagent
magnetite, thecorrosion rateincreases.

Knowledgebase-Documents-DatabaseArgumentation based on
experimental data
The corrosion rate increases because
the excess of ferric oxide overstoichiometric composition works as anoxidant. If this ferric oxide will be
consumed, the corrosion rate reduces.
CQ1: Is the experimental
system relevant to that
CQ2: : Is the experimental
considered in the repository?
datasetandanyquality
CQ3: :rigorous
Are there
assured?
contradictory
CQ4: Are theexperimental
boundary
data?
conditions well enough
CQ5: Are thereany
criticalestablished
for theapplication
simplifications
assumptions
CQ6:What areorthe
errors andconsidered?
requiredfor itsassociatedapplication?
？
uncertainties
withthe data used?

11

This phenomenon not only
due to the ferric oxide,because the hydrogengeneration also increases.11

KMS Components¾ The Knowledge Base (KB) is a highly dynamic
entity which is intended to be a fundamental
resource for implementers, regulators and otherstakeholders¾ The KM toolkit provides access to the KB andallows it to be¾ extended - by adding input from relevant sources¾ modified - integration & synthesis¾ reviewed - autonomous or focused QA¾ utilised - by all interested parties

12

Content of a radioactive waste KB

Processed
data

Synthesis
reports

Model output

Expert teams

N

標高
500

S
0

Log K [m透水係数s-1]［ms ］
-1

の対数値

-500

-4.0
-5.0

-1000

-6.0
-1500

-7.0
-2000

-8.0
60

-9.0
-10.0
-11.0

00

8
-6

EW

68

92
-6

00

［m
］

76

00

-7

00

00

00

N-

S

40

0

］
［m

13

3D hydrogeological model showing distribution of
hydraulic conductivity

A3-97

Managing tacit knowledge – Expert System
Information objects

Information types

Expert System

Control shell“mother” Operational
functions“child”

Image of the Resulting Blackboard System
14

KB structuring¾ Unlike traditional approaches, the database has no inherent
structure: application-specific structures are imposed on the
database - e.g. using hyperlinks to argumentation models¾ Using expandable argumentation models and hyperlinks tofull documents (focused on relevant sections), models,
databases, videos, animations, etc., a comprehensive KB isgenerated, which can then be frozen at project milestones

A3-98

15

Main applications¾ Focus on major areas where large flows of
information must be integrated in a structured
manner to provide support to the developing
safety case for deep geological disposal¾ Safety case development & review¾ Site characterisation & geosynthesis¾ Repository design & PA...although there is clearly significant overlap between
these areas

16

Expected evolution of the KMS toolkit
Safety confirmation
through intermediate
SC reviews

Site-specific safety cases
H12 SC
generic

SC for PIA
selection

Synthesis of• site understanding• site-specific design• state-of-the-art system
understanding
Regulatory constraints:• goals• boundary conditions (e.g.
timescales, treatment ofspecial scenarios, …)

Socio-economic BCs:
• acceptance• financial constraints• ….

SC for DIA
selection

SC for site
selection

SC forlicensing

Changes:• technical• regulatory• socioeconomic

Changes:• technical• regulatory• socioeconomic

Total synthesis:• technical• regulatory• socio-economic

SC forclosureTotal synthesis:• technical• regulatory• socio-economic

Evolution
JAEAKMS
KMS
Evolution ofofJAEA
etyfecases
and andlemen
tertertotma
ke kth
-Ssupporupportt bbootho maeethsa
efsa
thimp
imp
lemen
ty casesregulator tointelligent
tools
for: for:regulator
to review
reviewthem
thembybyproviding
providingintelligent
tools• sitesite characterisation
planning
and
implementation
characterisation planning and implementation
ositorto sitepp
y designgtailored• develodeveloppment
mentofofrere
ositorn tailoredto sitey desi• step-wisesite-specificandrealisticsafetyassessment
integration of all relevant information into the•safety
step-wisecaseintegration of all relevant information into thesafety
case
-The
final
goals is full coupling of information fluxes of
- The
goal
of informationssafullyrepository
safetyof site
ite cfinal
harac
teriistion,coupling
design andfluxes
characterisation, repository design and safety assessment
assessment

A3-99

17

Change management
New counterarguments

Target(argument)¾ The KB continually expands
and new knowledge may
contribute (positively or
negatively) to specificapplications

Layer1:
Argumentation¾ Important feature of NUMO’s
RMS, which is now underdevelopment (e.g. NUMO-TR07-02)

Layer3:
Processes andfeatures¾ Might be implemented via the“alerting (notification)” functionof a smart search engine

Layer5:
Data

A

D
G

Layer2:
Safety function
B‘’Seed’’ of counterargument

C

Layer4:ModelsE

F‘’Seed’’ of counterargument
Negative link

Argument

Positive link‘’Deeper’’ knowledge

SearchProposal of new
counter-argument

18

Implementing QA – JAEA QA Workshop
Basic procedures, priorities and review work have to be carriedout by expert teams - initial workshop record available at
http://www.jaea.go.jp/04/tisou/kms/pdf/qa_ws_19_2.pdf

A3-10019

Accessing the KB¾ Access via:
¾ CoolRep / H22 report¾ Argumentation models¾ Smart search engine (planned development)¾ integrates focused electronic search with functionality such as:– automated translation– automated summarisation / quality checks¾ initial attempt to develop system from scratch failed– better approach seems to be tailoring existing specialist searchengines (e.g. FAST ESP, Autonomy IDOL)– features include: connectivity, data cleansing & linguistic analysis,federated search, entity extraction, faceted search, contextual
search, relevance & ranking, scalability, security and alerting– “alerting” - autonomous identification of new material on a topic could be the basis for a change management function

20

KMS user interface

A3-10121

CoolRep• CoolRep developed as the interface to H22 – also
providing easy access to all supporting documentation.
• CoolRep specifically designed to communicate with awide range of stakeholders…

22

Conclusions and future perspectives¾ Significant progress has been made in establishing the KB
to support the H22 project and the tools that provide
access to it¾ A number of different approaches have been examined
but, to date, those based on argumentation models
appear most generally useful¾ Effort is focused on establishing as much automaticfunctionality as possible, but it is accepted that practicalapplication requires a hybrid approach - facilitating thework of project teams is the main goal
¾ Some major challenges have not yet been addressed¾ KB freezing, archiving and security¾ Smart search engine development¾ Development of interface with knowledge producers

A3-10223

Session 3
Session 3: RMS in other industries – What can we learn? (Chair: S. Vomvoris)
Application of RMS for the management of major projects; examples from the
Aerospace industry (H. O’Grady)

A3-103

Experiences of Requirements Management in the
Aerospace Industry

Henry O’Grady
Parsons Brinckerhoff Ltd
Tokyo, Jan 2010

RMS Information Exchange Meeting, Tokyo,
Jan 2010

Engineering a sustainable future

Scope of this presentation• Experiences of Requirements Management outside the
Nuclear industry• Not intended to be original: you may already have solved
most of the issues• My own experiences– presented in a way which I hope is relevant to NUMO’s
mission and current activities• Mainly on aerospace / defence experience– where RM is well accepted and usually mandated

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-1052
Engineering a sustainable future1

Contents• My background• Examples of Requirements Management application• Requirements Management as a process within thelarger project• Generic stages or the implementation of a
Requirements Management System– with some points and lessons from each

RMS Information Exchange
Meeting, Tokyo, Jan 2010

3
Engineering a sustainable future

My background

•
•
•
•
•
•
•
•

Mainly Aerospace / Defence
Explosives engineering
Engineering consultancy
High energy-rate simulation software
Avionics systems
Weapon systems
Project management
Process definition, including Requirements
Management Systems
RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-106

4
Engineering a sustainable futureRequirements Management Applications

Brimstone
AAW

Storm
Shadow

JSF Stick& Throttle

EFA HeadUp Display
MissionPlanning
SoftwareNote: this is a schematic diagramme of a “Generic” aircraft andfittings
RMS Information Exchange
Meeting, Tokyo, Jan 2010

5
Engineering a sustainable future

Requirements Management Applications:London Olympics – Combined Cooling Heat andPower

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-107

6
Engineering a sustainable future

RMS Components

Requirements
Management System
PeopleProcesses
Tools

RMS Information Exchange
Meeting, Tokyo, Jan 2010

7
Engineering a sustainable future

The RMS within the Project Context

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-1088Engineering a sustainable future

Generic Stages of an RMS• Client relationship• Justification / Business Case / Funding• Process definition– Software specification• Procurement / Staffing / Organisational Structure• Roll-out– Pilot project– Proving the benefits– Process improvement

•
•
•
•

Full implementation
Demonstration of added value
Continuous improvement
ClosureRMS Information Exchange
Meeting, Tokyo, Jan 2010

9
Engineering a sustainable future

Client relationship• RM is well-established in some industries, notrecognised in others• Client may have own RMS• Client may have own project Lifecycle and Milestones• RMS may be excellent selling point in its own right• Define the “clients” in detail– Who, exactly, in the Client organisation ?
– Client Project Manager ?
– Client’s Client ?

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-10910
Engineering a sustainable future

Clients & Stakeholders

RMS Information Exchange
Meeting, Tokyo, Jan 201011
Engineering a sustainable future

Justification / Business Case / Funding••••

Run RM implementation as a project, with milestones
Include budgeting and cost control
Define staff requirements: who, how many
Define benefits, and who for– Absolutely key to getting support– Define the RMS deliverables eg single set of
requirements to contract against• Find senior level “champion”• Formally identify Stakeholders– Who are they: organisation, peoples’ names– What do they want
– What “language” do they speak (ie commercial, project,engineering, IT, etc)

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-11012
Engineering a sustainable future

Funding• Funding may be in tranches, conditional on
demonstration of benefits• This is very beneficial– Keeps RM as high profile– Provides delivery of RMS in stages– Ensures active reporting to senior management– Ensures RM is part of the project– Focusses the RM delivery team on proving the benefits– If these can’t be done, then good to know early !

RMS Information Exchange
Meeting, Tokyo, Jan 201013
Engineering a sustainable future

Process definition• RMS should be defined just as any other engineering
process• RMS should include appropriate use of Systems
Engineering methods• Key features:– Ease of use– Minimal additional staff / resources– Full integration into project process (after pilot has provenitself)– Defined Inputs and Outputs– Provable benefits• Integration with project / engineering milestones

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-111

14
Engineering a sustainable future

The RMS within the Project Context

RMS Information Exchange
Meeting, Tokyo, Jan 201015
Engineering a sustainable future

Generic Systems Engineering / Project Lifecycles

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-11216
Engineering a sustainable futureTypical Engineering Lifecycle

•
•
•
•

CADMID Lifecycle
Used by UK MoD
Technical / engineering reviews
Stage Gates / “GO – NO GO” Milestones

RMS Information Exchange
Meeting, Tokyo, Jan 201017
Engineering a sustainable future

The RMS within the Project Context

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-11318
Engineering a sustainable future

Systems Engineering applied to the software tool

• The need for any software tools should arise from thedefinition of the desired process– Then can specify the software tool
– Again, can use the full suite of RM methods to specify
and procure / develop the software tool
• Essential to apply the same approach to the systems
engineering of the RM process and software that will beapplied to the overall product– Good test of the Systems Engineering process– Identifies areas of the SE process that don’t add value– SE team is seen to be “walking the talk”

RMS Information Exchange
Meeting, Tokyo, Jan 2010

19
Engineering a sustainable future.

Project

Supports

RM process
Supports

Helps
defineRMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-114

RM Tool

20
Engineering a sustainable future

Development of PBRMS Software Tool

RMS Information Exchange
Meeting, Tokyo, Jan 2010

21
Engineering a sustainable future

Procurement / Staffing / Organisational Structure• Need some specialist staff, and good project
management– “Project management” skills versus “data entry and data
maintenance”– “do-it” types vs “plan it” types• Careful definition of the roles of other functions– IT– Projects– Commercial– Configuration management– Engineering– Project management• Role of Chief Systems Engineer
RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-11522
Engineering a sustainable futureProcurement / Staffing / Organisational Structure (2)• Training and familiarisation are key– For management as well as engineering staff• And possibly the External Client & Regulators• Organisation of the RM function should map onto theExternal Client organisation– Foster External Client liaison at low levels of theorganisation

RMS Information Exchange
Meeting, Tokyo, Jan 201023
Engineering a sustainable future

Cooling the TubeRMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-11624
Engineering a sustainable futureRoll-out• Pilot projects– will provide early and low-cost identification of areas for
improvement– will provide early demonstration of benefits– and confirmation that the business case objectives aremet– and that objectives can be proven to have been met• Pilot can be focussed on– a specific part of the organisation– a sub-set of the requirements

RMS Information Exchange
Meeting, Tokyo, Jan 201025
Engineering a sustainable future

Full Implementation• Approach must be flexible– Staff may change– Stakeholders and regulators don’t behave ideally– Funding will change– Organisation will change• At this stage the RM team must be fully part of the
project team• The Requirements Management System and the RM
software must be the primary systems/tools used
– For example. must not let people keep using WORD or
Excel and only use the RMS as an archive

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-11726
Engineering a sustainable future

RM Process: Continuous Improvement• Regular formal process reviews• Monitor good practice across industry and in otherindustry sectors• Issues or suggestions log, with single ownerresponsible for RMS process improvement• Need formal process for CI• Capability Maturity Models– The RMS can be formally audited against CMM Levels 1
to 5– Provides a basis for target-driven improvement– In the longer term, important to integrate the different
CMMs across various disciplines
RMS Information Exchange
Meeting, Tokyo, Jan 2010

Engineering a sustainable future 27

RM Software Tool Improvement• Good communication between software developers
and the RM team
• RM team should know something of the difficulties ofsoftware development, and vice versa• Emphasis on– data entry,– data update– configuration management– reporting for Project Managers• Keep issues log• Schedule formal software updates, addressing
priorities
RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-118Engineering a sustainable future 28

Closure• Stop using RM software, re-deploy staff• Archive of data and change histories• Knowledge management principles apply– Data must be available over lifetime of the project andbeyond• Data migration to future software tools will benecessary in the longer term
• Data formats will become obsolete• Decisions on paper / low-tech data formats• Do a formal Lessons Learned and transmit the lessons

RMS Information Exchange
Meeting, Tokyo, Jan 201029
Engineering a sustainable future

Trade-offs – Optimised for Specific Project

•
•
•
•

Terminology – local versus global
Electronic data storage versus paper
RM software tool versus MS WORD
How far down the Systems Engineering hierarchy should be
automated ?
• Integration with Customer and Contractor Requirements
Management systems• Technical specialists versus project managers• Inward facing staff versus outward facing

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-11930
Engineering a sustainable future

Main Points• RMS as a formal project• Identify Customers and Stakeholders• Application should be tailored to the people involved,
the product, the external Client, existing internal
processes• Staged approach to implementation• Identify benefits and then demonstrate them
• RM software tool specified around the overall RM
process• Use RM processes on the RMS itself

RMS Information Exchange
Meeting, Tokyo, Jan 201031
Engineering a sustainable future

Annex: Generic CMM Levels

•
•
•
•
•

Level 1 – Exists, undocumented
Level 2 – Repeatable
Level 3 – Defined and consistentLevel 4 – Managed, uses metrics
Level 5 – Optimized: with continuous improvement

RMS Information Exchange
Meeting, Tokyo, Jan 2010

A3-12032
Engineering a sustainable future

RMS2010 Requirements Management Systems (RMS): Status and Recent Developments

Information Exchange Meeting Report