5.

ANNEX B
IAEA Specification

RAIS 4.0
Software Requirements Specifications (SRS)
Contents
List of Abbreviations and Capitalized Terms ........................................................................ 5
1 Introduction.................................................................................................................. 7
1.1 Background Information and Purpose of the document .......................................... 7
1.2 Document Organization .......................................................................................... 7
1.3 Document Conventions ........................................................................................... 8
1.4 Scope of the Project ................................................................................................ 8
1.4.1 Future Plans for Extending or Enhancing the System .................................... 9
1.5 Applicable Documents and References .................................................................. 9
2 System Description ................................................................................................... 10
2.1 Process Driven Approach ...................................................................................... 10
2.2 Dynamic Data Driven Approach ............................................................................ 12
2.3 System Operation Modes ...................................................................................... 13
2.4 Default System Access and Permissions .............................................................. 13
2.4.1 Functional Role Management ....................................................................... 14
2.4.2 Data Role Management ................................................................................ 14
2.5 Default System Actors ........................................................................................... 14
3 Functional Requirements........................................................................................... 18
3.1 Default and Advanced Functional Modes .............................................................. 19
3.1.1 Default Mode ................................................................................................ 19
3.1.2 Advanced Mode ............................................................................................ 19
3.2 System Features ................................................................................................... 19
3.2.1 Process Management ................................................................................... 19
3.2.2 Customization ............................................................................................... 23
3.2.3 Administration for System Access and Permissions ..................................... 26
3.2.4 Data Manipulation (Desirable) ...................................................................... 27
3.2.5 Data Import ................................................................................................... 29
3.2.6 Web Services................................................................................................ 29
3.2.7 Dashboard (Desirable).................................................................................. 30
3.2.8 Reports ......................................................................................................... 31
3.2.9 Add-Ons (Desirable) ..................................................................................... 31
3.2.10 RAIS Migration Tool .................................................................................. 32
3.2.11 Search and Filter Functionalities .............................................................. 32
3.2.12 File Library (Desirable) ............................................................................. 33
3.2.13 Document Generation .............................................................................. 33
3.2.14 Messaging Feature ................................................................................... 34
3.2.15 Administrator System Reports (Desirable)................................................ 34
3.2.16 System Backups ....................................................................................... 35
3.3 Use Cases............................................................................................................. 36
3.3.1 Use Case - Process Management ................................................................ 36
3.3.2 Use Case – Customization ........................................................................... 38
3.3.3 Use Case – Administration for System Access and Permissions .................. 43
3.3.4 Use Case – Data Manipulation ..................................................................... 46
3.3.5 Use Case – Data Import ............................................................................... 51
3.3.6 Use Case – Web Services ............................................................................ 52
2
 3.3.7 Use Case – Dashboard ................................................................................ 52
3.3.8 Use Case – Reports ..................................................................................... 54
3.3.9 Use Case – Add-Ons .................................................................................... 57
3.3.10 Use Case – RAIS Migration Tool .............................................................. 58
3.3.11 Use Case – Search and Filter Functionalities ........................................... 59
3.3.12 Use Case – File Library ............................................................................ 61
3.3.13 Use Case – Document Generation ........................................................... 64
3.3.14 Use Case – Messaging Feature ............................................................... 65
3.3.15 Use Case – Administrator System Reports............................................... 66
3.3.16 Use Case – System Backups ................................................................... 67
3.4 Entity Relationship Diagrams ................................................................................ 69
3.4.1 Authorizations ............................................................................................... 70
3.4.2 Inspection ..................................................................................................... 71
3.4.3 Radiological Events ...................................................................................... 72
3.4.4 Development of Regulations and Guidance ................................................. 73
3.4.5 Review and Assessment ............................................................................... 74
3.5 Data Dictionary...................................................................................................... 75
3.5.1 Authorization ................................................................................................. 75
3.5.2 Inspection ..................................................................................................... 75
3.5.3 Radiological Events ...................................................................................... 76
3.5.4 Development of Regulations and Guidance ................................................. 77
3.5.5 Review and Assessment Process ................................................................. 79
4 Technical Requirements (Non-functional) .................................................................. 82
4.1 Architectural Strategies ......................................................................................... 82
4.1.1 Technology Requirements ............................................................................ 82
4.1.2 Reuse of Software Components ................................................................... 83
4.1.3 System Architecture ...................................................................................... 83
4.1.4 Client Server Based ...................................................................................... 84
4.2 Components Based (Desirable) ............................................................................ 84
4.2.1 Pipeline Components (Desirable) ................................................................. 85
4.2.2 Add-On Based (Desirable) ............................................................................ 86
4.3 Performance.......................................................................................................... 86
4.4 Scalability .............................................................................................................. 86
4.5 Security ................................................................................................................. 87
4.5.1 User Access .................................................................................................. 87
4.5.2 Encryption ..................................................................................................... 88
4.6 Maintainability ....................................................................................................... 88
4.6.1 Monitoring ..................................................................................................... 88
4.7 Usability................................................................................................................. 88
4.7.1 UI requirements ............................................................................................ 88
4.7.2 Mobile Device Compatibility (Desirable) ....................................................... 89
4.8 Concurrency .......................................................................................................... 90
4.9 Multi-Lingual Requirement .................................................................................... 90
4.10 Auditing and Logging ........................................................................................ 90
5 Requirements and Deliverables ................................................................................ 91
5.1 Phased Implementation Plan ................................................................................ 91
5.1.1 System Assessment and Acceptance Procedures ........................................ 91
5.1.2 Project Phases.............................................................................................. 91

3
 5.2 Additional Requirements for RAIS 4.0 Development; Meetings, Reviews,
Testing and Data Deliverables ....................................................................................... 93
5.2.1 Meetings ....................................................................................................... 93
5.2.2 Point of Contact ............................................................................................ 94
5.2.3 Work review .................................................................................................. 94
5.2.4 Testing and Scaling....................................................................................... 95
5.2.5 Data and other Deliverables ......................................................................... 95
6 Appendix ................................................................................................................... 97
6.1 System Features Figures ...................................................................................... 97
6.1.1 Dashboard .................................................................................................... 97
6.1.2 Reports ......................................................................................................... 98
6.2 UI Requirements Figures ...................................................................................... 98
6.3 UI Customizations Figures .................................................................................. 101

4
List of Abbreviations and Capitalized Terms
Abbreviation Definition
AngularJS Open-source web application framework that relies on JS
API Application Programming Interface
ASP.NET Active Server Pages in .NET framework
AVG SQL Function for calculating average of items
Bootstrap A free and open-source front-end web framework
COUNT SQL Function for number of items
CRUD Create, Read, Update and Delete
CSV Comma-separated values – file extension
DOCX Office Open XML – MS Word file extension
Ext.JS JavaScript application framework
FTP File Transfer Protocol
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ID Identifier
IIS Internet Information Services
JS Java Script
KPI Key Performance Indicator
MAX SQL Function for retrieving the maximum from a set of items
MVC Model View Controller
NDR National Dose Register
NSRW Division of Radiation, Transport and Waste Safety
PDF Portable Document Format
POST A request method supported by the HTTP
QCM Query Customizations Language
RADMeter Radiation Meter
RAIS Regulatory Authority Information System
RAIS 3.X Series RAIS 3.1, 3.2, 3.3 and 3.4, excluding RAIS 3.0
RAISWS RAIS Web Service
RAN Regulatory Authority Number
RPC Remote Procedure Call
SCRUM Software Development Methodology
SDD Software Design Documentation
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
SPA Single Page Application
SQL Structured Query Language
SRS Software Requirement Specifications
SSL Secure Sockets Layer
TFS Team Foundation Server
UI User Interface
URL Uniform Resource Locator
WYSIWYG What You See Is What You Get – HTML Editor
5
XML Extensible Markup Language

Use of capitalized terms in the SRS document:

All capitalized terms not defined in the list of abbreviations above or in the text of the SRS
refer to their meaning as defined in the existing RAIS 3.3 documents or other documents
listed in Section 1.5.

Any reference to the ‘current’, ‘recent’ and ‘latest’ version of RAIS refers to RAIS 3.3 Web.
When only RAIS is mentioned, it refers to the system to be developed, RAIS 4.0.

6
1 Introduction
1.1 Background Information and Purpose of the document
Within its statutory functions in providing for the application of Safety Standards, the
International Atomic Energy Agency (IAEA) has been developing the Regulatory Authority
Information System (RAIS) as part of a supporting set of actions designed to assist
countries in managing their regulatory control programme in accordance with international
standards and guidance, including the Code of Conduct on the Safety and Security of
Radioactive Sources and its supplementary Guidance on import and export of radioactive
sources.
RAIS promotes a consistent and common approach to the regulatory control of radiation
sources, whilst offering flexibility to respond to specific needs of the countries, with due
account of their national legislative framework, administrative structure and institutional
and regulatory framework. RAIS is a product with its own history where the first version
was developed in the late 90’s. Following an evolutionary path, RAIS followed the trends in
software development and arrived in the web-based domain with version 3. The most
recent version of RAIS (Version “3.3 Web”) was released in March 2014 and the source
code for all RAIS versions is owned by the IAEA. The System described in this document
shall be succeeding the previous version 1 and shall be labelled RAIS 4.0.

The purpose of this document is to present a partial description of RAIS 4.0. It is

focussing on the description of additional and amended features, interfaces and
constraints in comparison to its predecessor., In addition, this document contains detailed
description regarding the processes, the interfaces of the System, what the System shall
do, the constraints under which it shall operate and how the System shall react to external
stimuli.

1.2 Document Organization

This document is organized in four chapters.
Chapter One gives an introduction to RAIS, its purpose and scope. In addition, it covers
some terminology clarifications and document references.
Chapter Two explains how the System operates and how it shall operate according to the
new requirements. The main RAIS actors and the corresponding role concepts are
introduced in this chapter as well.
Chapter Three covers the functional requirements of RAIS 4.0 or the core changes that
shall be introduced. The chapter provides the details on the new or modified existing
(RAIS 3.3) features that shall be built into RAIS 4.0. To support the definition of the
functional requirements, Use Cases are created with a certain extend of details. These
Use Cases do not cover every possible way of using the described functionalities.
Furthermore, a set of modified entities from RAIS 3.3 with details of modifications are
presented with entity diagrams and data dictionaries.
Chapter Four covers the technical requirements of RAIS 4.0 such as: architectural
1
Or any subsequent version of RAIS 3.X series

7
strategies, requirements for System performance, scalability, security, usability, lingual
support etc.
The Annex located at the end of the document provides figures that represent a sample UI
visions that could be used as a direction for the new look and feel of RAIS 4.0.

1.3 Document Conventions

Common terms from RAIS 3.3 which shall be used in the description of the System are
explained here briefly:
Dynamic masks are found under the menus: regulatory System, Input, Query and
Statistics. Dynamic masks are generally associated with data tables (mainly related to
Regulatory Processes data) and are used to list, view, add, edit or delete data. There are
four types of dynamic masks2:
• Details mask: Usually used in the Input menu. This mask type is referred to also
as ‘Single Row Mask’
• List mask: Used in the Regulatory System as well as the Input menus. This
mask type is referred to also as ‘Single Row Mask with List’
• List with Filter mask: Usually used in the Input menu
o Preselection lists are the landing page for an entity using a List with Filter
mask and allow to filter a list of records of a specific entity
• Parameters mask: Usually used in the Query and Statistics menus.
Within this document, the term mask refers to one of the types elaborated above and
represents a UI web layout or a dynamically rendered web page.

1.4 Scope of the Project

The Regulatory Authority Information System is designed to support countries in operating
their regulatory control program. Regulatory control means any form of control or
regulations applied to facilities or activities by a regulatory body for reasons related to
radiation protection or to the safety or security of radiation sources. The goal of this
development process is to amend existing features from the latest available version RAIS
3.3 and together with new features and functionalities to add them into a new System
RAIS 4.0. It is neither required nor prohibited to use existing source code which is property
of the IAEA.

RAIS 4.0 as described in this document shall be a customizable web application for data
management to keep a national register for radiation sources and associated equipment,
inventory of radiation facilities and activities, and also to manage the regulatory body
processes (Authorization, Review and Assessment, Inspection, Enforcement,
Development of Regulation etc.). It shall offer a dynamic process creation and
customization mechanism that shall allow reproduction of any regulatory body related
process. In addition it shall be able to process large amount of data with which the
regulatory authority is daily confronted such as registry of occupationally exposed workers,
2
More details at RAIS 3 1 Web Users Guide.doc / 2.2.2.

8
radiation events, etc. It is also essential for assessing the level of radiation safety and
security in the country and the effectiveness of the regulatory programme. RAIS 4.0 is an
enhanced software version of its predecessors in managing Regulatory Processes and
data.

1.4.1 Future Plans for Extending or Enhancing the System

The evolution of RAIS is not intended to end with the advent of the current version. The
System shall anticipate further enhancements and accommodate for further extensions to
the System while keeping in mind that an upgrade path has to be provided from the latest
direct version.

1.5 Applicable Documents and References

The following documents and information shall be applicable for the RAIS 4.0:

• Annex A – “RAIS 4.0, Software Requirements Specification, Processes Supporting

Document” - provides detailed description of the core processes of RAIS 4.0

• RAIS 3.3 Web software, Latest version of RAIS - available for download and install.
All functionalities and features of this software must be reflected in RAIS 4.0. The
download package 3 includes supporting documents describing the features and
capabilities of RAIS 3.3 (or if unchanged from RAIS 3.1) which also builds on its
predecessors. These documents shall be considered part of the full description of
RAIS 4.0:
• Documents/Manuals/RAIS 3.2 Extensions.doc
• Documents/Manuals/RAIS 3.3 Extensions.doc
• Documents/Manuals/English/RAIS 3 1 Web Regulatory Model.doc
• Documents/Manuals/English/RAIS 3 1 Web Users Guide.doc
• Documents/Manuals/English/RAIS 3.1 Web Administrators Guide - Part
I.doc
• Documents/Manuals/English/RAIS 3.1 Web Administrators Guide - Part
II.doc

• RAIS Blog and RAIS Frequently Asked Questions

http://gnssn.iaea.org/CSN/RAIS/Blog/default.aspx

3
http://gnssn.iaea.org/CSN/RAIS/RAIS Versions/RAIS 3.3 Web/RAIS 3.3 Web Package.zip

9
2 System Description
RAIS aims to support regulatory bodies in countries which may have different
requirements mostly enforced by legislation to perform regulatory activities. The default
implementation of RAIS is only a starting point to adopt and customize the System to
those requirements in order to be useful. Therefore RAIS needs to be flexible to allow
modification of every aspect of the application from user and rights management and entity
definition to business logic and workflows.
All characteristics of RAIS 3.3 Web that are not described in this
document shall be reflected in RAIS 4.0. The functional software RAIS 3.3
Web with all its features, capabilities and relevant documentation is an
integral part of the full feature specifications of RAIS 4.0.
RAIS 4.0 shall be dynamic so that such aspects can be configured and
managed - without compiling code - typically by non-software
programmers such as RAIS Administrators. The UI must be dynamically
generated to reflect the configuration.
Previous versions of RAIS focused on entity based data management and had virtually no
“out of the box” support for reflecting real-life business processes / workflows. However,
with the provided customization capabilities a well-trained Administrator could have
modified RAIS in a way to reflect such real word processes. This was often desired by
users and Administrators of the System but was hardly ever achieved as it was perceived
too challenging or the Administrators were lacking resources to do so.
RAIS 4.0 shall address this requirement to reflect any business processes or workflows
that shall follow predefined steps in correct order which may need additional input or
trigger other processes or events (like sending out notifications).
RAIS 4.0 shall be process driven where users are guided through
configured workflows by notifications (e.g. required action), automation of
process steps where possible, limitation of user input according to
circumstances, etc.

2.1 Process Driven Approach

The aim is to have a generic structure of a business process in RAIS 4.0 which is able to
accommodate any process or workflows required by a regulatory body. A process can
either be predefined and part of the “core” RAIS System, or custom designed by Member
States depending on their individual needs.

A process may be as simple as input validation by an authorized user

(User A enters data -> User B is notified -> User B checks data and approves / rejects)
or reflect more complex scenarios where parallel processes interact with each other, or
certain steps have external interfaces that require certain data to continue, or internal
interfaces to trigger other “child” processes. The following figure (Figure 1) shows a simple
diagram describing such a process:

10
 Figure 1 – Schema of a Sample Process

The System shall aim to be a tool to manage the daily work of regulators and inspectors
rather than merely collecting data. In this sense it shall also be able to replace or reduce
required paperwork to manage business processes. It shall allow for a process to manually
forward to the next step or return to previous steps if necessary. The System shall also
allow to monitor process performance e.g. by time passed between steps.

At minimum, Member States shall be able to:

• Tailor the core processes in RAIS according their individual needs
• Design new processes in RAIS
Export their processes as “process package” (see Section 3.2.9 Add-Ons)
Import “process packages” in RAIS designed by other member states or 3rd parties (see
section 3.2.9 Add-Ons)

The processes are specified in a separate document 4. The following is an overview of the
main categories with examples.
Processes can be categorized into 3 different types:
• Regulatory Processes (RAIS 4.0 core)
• Management Processes
• Support Processes
Regulatory Processes are:
• The Authorization Process
• Review and Assessment
• The Inspection Process
• The Enforcement Process
• The Emergency Preparedness Process
• Development of Regulations

4
• RAIS 4.0, Software Requirements Specification, Processes Supporting Document.

11
Management Processes are:
• Development of Policies and Processes
• Processes related to Monitoring and Measurement
• Self-Assessment
• Independent Assessment
• Control of Records Processes

Support Processes
• Use of External Support

2.2 Dynamic Data Driven Approach

As one of the main objectives of the System is to provide a high degree of customizability,
a “dynamic data driven” approach is of major importance, as opposed to logic previously
compiled into the application. The System shall provide a generic customization
mechanism allowing an Administrator to perform any type of supported customization in
terms of business objects (entities), business processes, business logic, UI navigation and
menu items, reports and web services.

The container for this dynamically driven logic should be the database as the basis for
communicating between parallel processes, as opposed to direct inter-process
communication via message passing functions and message-oriented middleware. The
benefit of database-centric architecture shall be simplification of the design by utilizing
DBMS-provided transaction processing and indexing to achieve a high degree of reliability
and performance.

As shown in Figure 2, any communication between entities and business processes or

between parallel processes shall also be performed through the database, to allow for
transactional consistency at any stage of a process.

12
 Figure 2-Dynamic database driven approach

Since the entities, business logic and processes can be configured/customized during
operation; the UI shall also be dynamically generated based on the definitions in the
database. Note that in current RAIS 3.X versions, this concept is implemented through
“dynamic masks”.

2.3 System Operation Modes

RAIS 4.0 shall offer two operation modes, which could be selected during the installation
phase: default and advanced mode. Switching to an advanced mode shall be possible
after RAIS has been installed.
The default mode shall include core regulatory processes as described in section 2.1 (and
RAIS 4.0, Software Requirements Specification, Processes Supporting Document) with
the possibility of their limited customization (see section 3.1.1).
The advanced mode shall offer the full capability of the new RAIS as described in this
document.

2.4 Default System Access and Permissions

RAIS uses a role-based accounting system which is able to handle different types of
access rights. The idea is to split data roles and functional roles. Data roles on the one
hand represent rules based on specific data entries, for example all facilities in a defined
region. On the other hand, functional roles enable or disable various masks (or menu
items) in the web portal. If a user is created, a data role and a functional role are assigned
to his account.

13
2.4.1 Functional Role Management
A functional role controls which masks the user can access and what operations (view,
add, edit and delete) he can perform on each of the masks. Additionally, functional roles
specify the level of validation required for the data entered by the user.

2.4.2 Data Role Management

Data roles provide restriction on accessible data. In RAIS 3.1 Web, data roles provide
restriction based on region, district or facility based on the permissions granted to the user.

2.5 Default System Actors

By default RAIS has six (6) predefined functional roles5 as listed below. It shall also allow
for management of permissions of predefined data and functional roles and creation of
new data and functional roles. The functional roles below are the default actor definitions
and figures as described in RAIS 3.X series and correspond to the menu structure in these
RAIS versions.

Administrator: This user type has full access to RAIS and can make all changes
supported by the System, including adding, modifying, deleting and viewing all data,
modifying the way the regulatory body operates by modifying regulatory system model and
modifying regulatory system data. Additionally, Administrators shall be allowed to define
users into the RAIS 4.0 Web System and assign access permission.
Administrators are responsible for installation and customization of RAIS. They are able to
set up common tables, user groups, roles and predefined values. They also have access
rights to all areas of RAIS (Figure 3).

Figure 3 - Functional role for Administrator

Regulator: This user type is allowed to change regulatory data related to Facilities,
Departments, Sources, Associate equipment and all default processes in the System. The
Regulators are the representatives of the national Authorities. They have complete access
to all areas in the System except the installation and customization areas. In addition to
their tasks, they have to validate data changes made by Licensees / Applicants (Figure 4).
As already present in RAIS 3.X series, a connection/interface from RAIS to the
“International Catalogue of Sealed Sources” shall be implemented. Only regulators shall
have access to this interface.
5
For further description please refer to the RAIS 3.3 Web software and the SRS RAIS 3.0 Web [see
Sections 2.3.5.1. Role based accounting system, 2.5.2.2. Data role management and 2.5.2.3. Functional role
management]

14
 Figure 4 - Functional role for Regulator

Restricted Access Regulator: This user type is allowed to view regulatory data, but not
allowed to add, modify or delete any regulatory data or regulatory system data (Figure 5).

Figure 5- Functional role of Restricted Access Regulator

Licensee: Users of this type are authorized representatives of facilities. In addition to the
global and public information, this user type is allowed to access only regulatory data
about their own facility. However, adding, editing and deleting any data related to their
facility is subject to validation process by the regulatory body.
Licensees and applicants are principally the same group. Licensees actually get a license
and applicants apply for a license. This group will probably have the largest amount of
users. They only have rights to some data of their related facility (e.g. they have no rights
to inspections). Query and statistics are not available for this group. All data changes
made by them are submitted to Regulators and need validation by the Regulators (Figure
6).

15
 Figure 6 - Functional role for Licensee

Public Bodies: This user group only has readable access to statistical data. National
authorities should have access to all facilities. Users of this group are for example local
and national authorities, customs, police, first responders, etc.

Guest: This user type is only allowed to view global and public information, such as
statistical data. Guests are not allowed to add, modify or delete any regulatory data or
regulatory system data.

Figure 7- Functional role for Guest

This group is not a user group of RAIS and need no login account. They can login as
16
guests without prior registration. They only have readable access to some statistics and
documents which are intended for use by the general public. They have neither access to
the other areas of the System, nor can they see other menu entries of the System.

17
3 Functional Requirements
The most significant externally visible improvement from RAIS 3.3 to RAIS 4.0 shall be the
process driven approach as per Section 2.1. A process can be viewed as a real-life step-
by-step workflow supported by RAIS. The main processes are detailed in the support
document “Processes” which describe the processes that shall be implemented out of the
box and also outline some processes users of the System may design using
customization.
A brief overview of the main changes to be built in RAIS 4.0 in comparison to the most
recent version of RAIS 3.3:
1. The System shall offer two modes of operation: default and advanced which targets
System Administrators with different level of technical skills.
2. The System shall guide users through processes, i.e. process for authorization of
the usage of a radioactive activity. In Addition, the System shall allow for the
Administrator to amend the processes according to the user needs.
3. The System shall allow for the Administrator to create new entities and processes
and to customize existing ones by adopting their design from the UI
4. The System shall allow users to merge records, detect duplicate records and
validate input not only by type but also against rules which may involve other fields.
Certain data shall be made visible to the corresponding functional roles only.
5. The System shall support preselection lists for ListWithFilter type of masks to allow
filtering and sorting to quickly find records.
6. The System shall allow importing XML and Excel files using the web UI and
consuming clean XML by external systems.
7. The System shall provide a customizable dashboard as default home screen where
users will see reports, statistics (graphs), tasks and notifications.
8. The System shall support exporting and importing of Add-Ons which encapsulate
full functional menu items or process definitions to share customizations among the
community.
9. The System shall provide more granular search capabilities to find records.
10. The System shall support files to be linked to entities and process instances / steps
which shall also be available for search in a file library.
11. The System shall allow users to generate documents based on data in the System
(e.g. certificates).
12. The System shall allow message based communication among RAIS users and in
one way to external users.
This overview list combines some of the features described in detail in the next section
“3.2 System Features”. In addition, section “3.3 Use Cases” further builds on the System
features and describes actual scenarios how each feature shall be used. The provided
Use Cases do not cover every possible aspect of a feature operation; they support their
description with few desired real examples.

18
3.1 Default and Advanced Functional Modes
In accordance with Section 2.3, RAIS shall provide default or typical operation mode,
which is a significantly simplified version of the full RAIS capability.

3.1.1 Default Mode

The default mode is intended for system Administrators with no advanced technical skills
such as: IIS configuration, ASP.NET web.config configuration knowledge, SQL programming
and relation algebra knowledge etc. It shall offer the simplest way of installation without
any IIS configurations and all prerequisites must be installed automatically during the
installation process.
The default mode shall be easy to use, manage or customize by the RAIS Administrator. In
using the general functionalities of RAIS, the user shall be able to jump to different
locations of the System to retrieve the required information without losing the context and
the focus of his operation. When customizing entities or reports, the customization shall be
done in place by clicking checkboxes which correspond to show/hide columns or when a
new value is needed in one of the lookup tables, a simple jump from / to customization
area is needed with a simple jump back to continue the operation and use the newly
added lookup table value. System back up shall be available and it shall be possible
through the UI (refer to Section 3.2.16)
Complicated features shall not be included in the default mode. Nevertheless, there must
be a possibility for their “unlocking” at a later stage by switching to advanced mode. Some
of the complicated features are: Process Creation and Customization, Web Services,
Query Customization Mechanism, Login Mechanisms, Add-ons, File-Library Configuration,
etc.

3.1.2 Advanced Mode

The advanced mode shall offer the full capability of RAIS. Using the advanced mode, an
Administrator shall have access to every aspect of customization of RAIS. In case RAIS is
upgraded from default to advanced mode, all missing software prerequisites shall be
installed during the upgrade.

3.2 System Features

3.2.1 Process Management
A process consists of an orchestrated and repeatable pattern of business activity enabled
by the systematic organization of resources into processes that provide services or
process information. It can be depicted as a sequence of steps (or operations), declared
as work of a person or group or one or more mechanisms.
From a more abstract or higher-level perspective, a process may be considered a view or
representation of real work. The flow being described may refer to a document or service
that is being transferred from one step to another. Another common expression would be:
workflow. In principle, once the process definition or customization phase is completed, the
process can be used or initiated with different content (multiple times).
19
Processes in RAIS shall be initiated by trigger events which can be internal or external to
the System. An internal trigger can be an expired timer. Such timer shall trigger a process
unconditionally or in cases when a certain condition/event has or has not occurred. For
example, an authorization process step needs additional data and sets a timer for 2
weeks: if the data is not entered by then, a notification shall be sent. Another internal
trigger can be certain conditions within a step of a process. Another example is an
inspection process (checking that the operation actually meets the authorized practice)
concluded non-compliance with the authorization which initiates an enforcement process
(to correct the non-compliance by escalating the issue).
An external trigger shall be a user manually initiating a process, for example, a licensee
wants to get an authorization for transportation by providing the required information.
Process Initiation
• A process is initiated after a certain triggering event has occurred;
• A process can be initiated by different types of triggers;
o manual (a user action);
o automatic timer based (conditionally and unconditionally);
o based on rules or change of value in a record;
• The triggers that fire a process shall be defined for each separate process;
• Triggers shall require multiple inputs.
Process Content
• One process consists of one or more steps;
• If steps inside a process are to be logically grouped together, they shall be treated
as a separate process;
• There is no fixed limit on the number of steps or levels of sub-processes;
• Decision-making steps determine the flow of the process;
• Iterative steps may loop until certain criteria are met.
Process Steps Content
• Steps inside a process follow a sequential flow;
• Automated logic or manual action can be used to advance to a next step;
• By default, the System shall not allow a step to be skipped. However, a user can
decide to skip any step by a manual entry only if it does not interfere with the
consistency of the process. The user shall provide justification in this case. The
possibility to skip a specific step shall be done by the administrator when
defining/editing the process;
• At any step it shall be possible to revert back to the immediate preceding completed
step, either automatically with a notification (rule based) or by a manual entry;
• It shall be possible to define one or more required data inputs for each step;
• It shall be possible to define custom logical rules on each step considering data in
any of the process steps;
• It shall be possible to define a default time frame for completion and timeout for
each step. The step shall have customizable logic to handle the timeout condition;
• A process step can be a “magnet” step meaning that if the step is customized it
shall revoke back all ongoing processes that already passed this step.

20
Parallel / Sub Processes
• A process step shall initiate another process (= sub process, e.g. a notification
process or inspection process);
• A sub process shall be run in serial (locking the parent process) or in parallel to the
parent process, or terminate without feedback to the parent process in which case
the parent process shall catch an exception or an appropriate message;
• A serial sub process shall typically provide feedback to the calling step. The
feedback is for example the final output of an inspection process which shall be
linked to the parent process step which initiated the sub process. The parent
process shall not continue without this feedback;
• A parallel sub process shall provide feedback to one of the steps following the
calling step. The parent process shall continue simultaneously to the step requiring
the feedback;
• It shall not be possible to manually skip a step which is waiting for a feedback from
a sub process;
• Steps waiting for feedback from a sub process shall be able to define a timeout and
notify the process owner/initiator when the timeout is reached. The calling step shall
have customizable logic to handle the timeout condition.
Process Resources
• Each step in a process shall have one, or more associated resources;
• Resources shall be categorized in human and non-human resources;
• Resources shall be group able;
• Human resources shall have one or more associated task (entity description of
persons);
• Depending on the tasks, suitable human resources shall be associated with a step.
For example, only inspectors can be sent for inspection;
• Human resources shall have an associated user login;
• Human and non-human resources shall have availability based on a schedule
(booked, busy, maintenance).
Process / Step Status
• A process step shall always be in a given state according to this list:
• Ongoing
• Completed
• Failed
• Cancelled
• Waiting (after Timed out)
• Timed out
• Skipped

• A process shall always be in a given state according to this list:

• Ongoing
• Completed
• Failed
• Cancelled
• Waiting (after Timed out)
• Timed out

21
Process Result
• A completed process shall produce one or more expected results:
• A document
• Data record
• Email
Process Documents
• It shall be possible to attach multiple documents to each step;
• It shall be possible to provide metadata about each attached document;
• It shall be able to show all documents related to a process.
Process Monitoring
• The System shall provide a visual map displaying the process progress;
• The System shall provide a monitoring mechanism for each process;
• Monitoring can be categorized into:
6
• Functional / KPI reports;
• System monitoring (technical performance);
• The process designer (RAIS administrator) shall be able to define the KPI’s;
• The process designer shall be able to define the method of reporting (e.g. automatic
notification through email, on-demand report).

For monitoring and assessment of the process performance, measurable quantities shall
be identified to regularly monitor performance. The quantities shall be provided by default
(out of the box) reports under the “Query” menu:

a) The time elapsed between different stages (to identify bottlenecks in the
process):
Average of time spent for each step (sum/count) and standard deviation. The
time of any step is the date difference between the current and the previous
step, for example step refers to the step of Authorization process, added through
the Authorization History form (in RAIS 3.X series). Each Authorization process
is connected to the Facility and that Facility may be connected to one or more
Practices. The average times and standard deviations are calculated over all
Facilities in a Practice.
b) Workload distribution among officers: - This report counts finished process steps
completed by user /officer grouped by process to identify over/under
performance or issues in the process.
c) Time elapsed between conducting the work and entering the relevant data in
RAIS (to identify difference between action date and recording):
RAIS_TIME_STAMP is time when an entry is inserted into database. A ‘Status
Date’ is the “datetime” value inserted by users of RAIS when a specific step was
completed. The difference in time between the date of data entry and the ‘Status
6
Key Performance Indicator

22
 Date’ provides the delay between conducting the work and recording it in RAIS.
This information may be useful for the manager of the regulatory body to
supervise and control workflows.
Process Customization
It shall be possible for an administrator to create new processes or edit existing ones
according to the framework described in the “Process Management” feature. The process
designer shall be in the form of a user-friendly visual designer.
The process designing mechanism shall provide some versioning functionality. This
functionality shall be used in scenarios such as when an existing process is edited by
adding or removing a process step or by modifying step content or step resources. Any on-
going process instance of such type shall still be allowed for completion in its current
version. However, if the modification is performed on a process step market as magnet
during the process design phase, all ongoing instances of that process shall return to the
modified process step. Past instances of processes that achieved the goals based on
previous process definition shall be given an option to re-run on the newly modified
process version. After any modification, the new starting processes instances shall use the
new modified version. The feature shall offer a list of previous process definitions and it
shall be possible to revert to an older definition.
The customization / definition of processes shall be easily possible for a non-software
programmer trained in customizing RAIS, ideally using a visual user interface inside RAIS.

3.2.2 Customization
Customization is a very important part of RAIS. Entity definitions and business logic shall
be customized to meet the user’s requirements. Virtually every aspect of RAIS shall have
the possibility for customization. Further details about required feature customizations are
included in the feature description. The current version of RAIS enables customization in
separate screens / sections. It can be cumbersome to locate the entity or rule to customize
in that screen. Therefore RAIS 4.0 shall perform customization “in place” as much as
possible or quick link to take the Administrators directly to the correct place for
customization. Figure 8 shows an example of in-place editing found at social networking
sites. A way of manipulating the structure of entities shall be achieved by enabling an edit
mode that allows for modification of the metadata directly from the data entry screen as
shown in Figure 9. This shall be achieved by providing a link when the application is in
“configuration” mode.

23
 Figure 8 - in place text editing offering options when hovering the text

Figure 9 - direct link to customization as alternative to “in place”

As noted in the System default operation mode, the customization of the System and its
features shall be as simple as possible for the user, where the user shall be able to reach
the configuration mode without losing track of the current screen. If a user wants to
manipulate the results of a report or when the administrator wants to modify an SQL query,
the customizations shall be reachable from the active masks and the customizations
results shall be visible immediately. Checkboxes and radio-buttons shall be used for
customizations where applicable, i.e. add/remove columns in list masks or in reports by
selecting or deselecting items from a list offering all columns for the affected table/tables.
Query Customization Mechanism
The referenced customizable groups shall be customized through Query Customization
Mechanism (QCM). This customization entails either adding a new query or altering
existing one by modifying their SQL statement and/or parameters, and then producing a
compiled form of the query. QCM shall keep existing logic from previous versions of RAIS
24
where Administrators have already adopted the ability to work with SQL queries. Also,
QCM shall extend the current approach with a visual designer taking into consideration
that most Member States using RAIS do not have sufficient IT knowledge.

QCM shall support “in place” modifications in order to preview the immediate result.
However, customizations of logical constructs like processes shall be done in a dedicated
area or screen.

In previous versions of RAIS customization often required “un-assignment” (un-linking

rules were used in the screens) of queries before customization. This approach shall be
replaced by a more convenient solution that allows for rolling back the current
“development version” of a query to the last compiled version.

Entity Customization
The existing table (entity) management feature in the current RAIS 3.X series supports
three types of tables: Single, With History and Authorization 7. The Authorization process is
only one of the core processes in RAIS 4.0 and therefore, an extended mechanism for
entity management shall be considered that shall cover new entity types according to the
processes which exist by default in RAIS. The mechanism shall include new processes
that shall be added through the process management mechanism.
The current versions of RAIS do not allow adding references to the same table multiple
times. RAIS 4.0 shall allow customizing an entity in way that it references Facility once as
origin and once as destination.

RAN Generation
The RAN Generation mechanism in the current RAIS 3.X series has a certain limitation in
terms of information contained in the RAN numbers. This RAIS feature shall be extended
to accept various RAN formats and data from mask input fields or selected menu items.
The RAN formats shall be rule-based, composed from different parts that retrieve data
from the System by defining certain rules. These rules shall define what kind of data shall
be plugged into different parts of the RAN number, i.e. rules that follow menu structure
depending of the location of the mask where the RAN is generated or RANs for
authorization can follow format for “Authorization” followed by “Authorization Type” and
then followed by some other context relevant data. Various functions that produce discrete
numbers such as: Count, Average. Min, Max etc. shall be available to add data in the
desired RAN parts.

User Interface Customization

Conditional Visibility of Entity Attributes

The current version of RAIS allows assignment of data entry screens to functional roles.
7
RAIS 3.1 Web Administrators Guide - Part I.doc “4.2 Customizing Tables”

25
The new System shall further allow to restrict data manipulation (create and update
permissions) or visibility (read permission) to certain fields of an entity to functional roles.
For example, an authorization process might hold internal information which shall not be
shown to external users or for a given mask the Administrator can see full list of attributes
while a restricted role can only view Title and Creation Date.

Data Entry

The current version of RAIS performs input validation and consistency checks only on the
server side. Consistency checks shall be extended to use all data presented in the masks.
The input validation of RAIS 4.0 shall be performed on client and server side. Everything
that needs to be stored into database shall be validated on client and server side. An
administrator shall be able to set and add or change validation messages in the whole
System.
Existing input validation capabilities shall be extended to allow validation of value range
(min, max); and patterns (email address, website, and regular expressions in general). It
shall also be possible to allow comparing different values in the same mask (e.g. value for
“minimum xxx” field shall be smaller than the value for “maximum xxx” field). These
validation definitions shall be offered as a customization functionality of the affected
masks.

Menu and Themes

The theme shall be customizable at runtime through the UI to extend the editing static text,
colours and images (logos) through the browser in an “in place” manner. For example, if a
headline needs to changed, it shall be achieved by enabling the edit mode and modifying
the headline in place using a WYSIWYG editor, i.e. Redactor 8 text editor. Insertion and
replacement of images shall be possible “in place” using the browser.
A global RAIS UI theme shall also be selected from a set of predefined themes, similar to
commercial software’s that offer, i.e. light, dark and custom theme. Theme selection shall
affect the whole System and shall apply the theme System wide.

3.2.3 Administration for System Access and Permissions

User Management
Deleting a user directly from RAIS shall be disabled as it may have side effects that affect
the System integrity. For instance, if a user has modified or added data to the System,
deleting this user shall cause conflicts within the logging feature. Only users that are not
associated to any record or data that harms the System integrity shall have the possibility
to be removed from the System.
If a user is not from the list of users’ types from Access privileges, then the Administrator
shall be able to assign to it an appropriate data role.
8
http://imperavi.com/redactor/

26
Using a systems component approach for authentication, the Administrator shall be able to
change the type of login mechanism of user accounts (e.g. by developing a new
authentication module). For instance, users shall be able to login with active directory
accounts or username and password. In the second case, there shall be an option to reset
the password through e-mail or by SMS. However, only out-of-the-box forms
authentication is supported.
Functional Role Management
Functional roles shall be able to restrict users by four main activities in RAIS: add, edit,
delete and view. The functional role mechanism shall be extended to be applied to the tab
level and even to the field level. Currently, functional roles are only assigned at the mask
level. Restriction shall cover every single mask associated with the menu. Administrators
shall be able to add, edit and delete functional roles assigned to user types.

Data Role Management

Data roles shall be able to restrict access to data of facilities, districts and regions. One
data role shall have one or more restrictions which shall not be in conflict. For example,
Restriction A restricts a user to read only data for facilities from Region 1 while restriction B
only allows that user to read data from a facility in Region 2. The goal is that the user does
not have access to see any data. In RAIS 4.0 such conflicts shall be checked while editing
the data roles.
Data roles shall be more restrictive with high flexibility. Every single field in database that is
presented on some of the masks shall be used for restrictions. A data role restriction shall
be applied to all dynamic masks in the database, including reports, or to the mask
associated with a menu item, including all of its tab pages. Some of the more restrictive
data roles shall be offered by default RAIS; for instance, medical facilities, non-medical
facilities, customs etc.
Furthermore, when editing Functional and Data roles a user friendly customization is
crucial. Using check boxes is highly desired when assigning or revoking specific actions
and System functionalities.

3.2.4 Data Manipulation (Desirable)

The user interface shall guide the user when manipulating the data, avoiding potential data
entry mistakes as much as possible. The following is a non-exhaustive list of required data
manipulation improvements for the current version:
- As already mentioned in the customizations part, it shall be possible to define an
explanation text for each field of an entity, which shall then be displayed as tooltip
on the form;
- Repetitive input of similar records of data shall be user friendly, for instance, by
using autocomplete textboxes or a “copy-from” functionality, which shall allow a
user to prefill a form based on the values of another record. For example, a set of
similar devices with same attributes except for serial number shall be entered in a
way that similar data is entered only once. RAIS shall offer a way to create a given
number of records in the database with the same attributes provided. The unique
information (such as the serial number) shall be provided in an editable grid;
27
 - Multi-select controls shall be clear and intuitive to use. Drag and drop functionalities
shall be introduced;
- Any control displaying or text containing, shall automatically size accordingly, so
that the entire text is visible.
Approval
Certain user roles shall require validation, meaning that data entered by a user of this
functional role shall first be validated by a user with the respective permissions before it is
finally accepted in the System. Inside Functional roles, the Administrator shall be able to
assign validation mechanism to the role. This mechanism shall define whether the current
Functional role is a validator or the role requires validations on data input by another role
with privileges to validate.
A validations mechanism shall be applied to all dynamic masks or to the mask associated
with a specific menu item, including all of its tab pages and fields. The current version of
RAIS has certain shortcomings in that area. For instance, it is only possible to either
completely accept or completely reject the entered record. The new System shall provide
the possibility for the validating user to correct any fields of the record without the need to
reject it. They shall be saved in the database using the versioning mechanism of the
current RAIS. Therefore, the original information shall not be deleted. After the correction
has been saved, the validating user shall continue to approve the record. In the message
sent back to the initiating user, it shall be mentioned that the entry was accepted
highlighting the modifications made (original vs changed values).
Record Merging
The new System shall provide a mechanism for merging two records of the same entity.
The workflow shall have the following outlook:

- User identifies duplicate records (in any data entry screen), selects the first and
presses the “merge” button. The process can be similar to a “compare product” feature
known from many web shops9;
- The merge window appears and provides a list of records of the same type of entity.
Then, the merger asks the user for the “primary” record from the two;
- The user has the possibility to select the fields he wishes to maintain the data for from
the “primary” record, and the ones from the “secondary” record;
- After all selections have been made, the user presses a “perform merge” button. This
ensures that the “primary” record gets filled with the correct data according to the field
selections, that all related data from the “secondary” record are re-linked to the
“primary” record, and that finally the “secondary” record gets deleted. The System shall
keep a history of merged and deleted records and the merge operation shall be
recorded in the log.
Duplicate Detection
The System shall provide the functionality to define duplicate detection rules for records of
9
E.g. www.pluscompare.com

28
the same entity, and a user with appropriate permissions shall be allowed to run a
duplicate detection rule at any time on demand. For instance, a duplicate detection rule on
the “person” table could be defined on the columns combination such as “first name”, “last
name” and “birth date”. Whenever the user runs this duplication detection rule, the System
shall present all records of the “person” table that have more than one record having the
same first name, last name and birth date. The user shall then decide that these records
require to be merged (see the “Record Merging” feature).

3.2.5 Data Import

One of the shortcomings of the current RAIS version is that it is hard to import external
data into the System. The new System shall provide a mechanism to bulk import
structured data from Excel sheets and XML files. A concept of “data import mappings” shall
be available, where a user with appropriate permissions (defined as “Import Files”
permission in the Tools/Data Import menu item under functional role permission) is able to
define a mapping between Excel sheet columns and RAIS entity fields, and then import
Excel files according to this mapping. In addition, XML files shall be uploaded and mapped
to fields in an entity table. It shall also be possible to save this mapping for future reuse.
The import mechanism shall ensure transactional consistency, i.e. not leaving the data in
an inconsistent state should anything go wrong during the import of a file.

3.2.6 Web Services

The System shall offer a Web Services feature that shall enable third party systems to
retrieve and input data from and to RAIS. The feature shall act as an interface that offers
RAIS data to other organizations/systems i.e. customs.

A certain customizable mechanism shall be offered, through which RAIS Administrators

can establish an instance of a web service and delegate it to an external entity. The
delegation of the instance shall be achieved by registering a Web Service User (see RAIS
3.3 Web Service Concept). The feature shall offer the possibility to assign one or many
different data views to a registered web service user.

This mechanism shall enable creating a web service instance and web service users in a
simple way through the RAIS User Interface, located under the Administration area. The
data views for information export and the data mappings for the information import shall be
built on top of the Query Customization Mechanism as described in Section 3.2.2
The data coming in/out to/from RAIS shall be in a machine independent and readable
format such as XML containing only relevant data. Note that the xml-serialized dataset
format returned by RAIS 3.3 Web services is not desired.
Security
The communication shall be highly secured as the exchanged data is highly sensitive.
A two tier security check of external systems is required. The first tier shall require
authentication of the external system that sends the request in order to establish a secure
channel for data transmissions. The second tier shall authorize the request and check for
permissions for the intended data to be retrieved. The current version RAIS 3.3 uses static
29
authorization with the same credentials for multiple remote procedure calls (RPC); instead
of using static user name and password as fixed URL parameters, the authorization shall
add a level of indirection e.g., by using a token (such as One-Time-Password) while the
authentication can be left the same (static credentials).
The secure channel shall run under HTTPS preferably using the main RAIS server
certificate.
In general, Microsoft patterns & practices, Chapter 3: Security Design Guidelines for Web
Services 10 shall be followed as much as feasible to ensure a secure approach of
information exchange.
User Access
The Web Service feature shall offer assigning a web service instance to a registered Web
Service user (see RAIS 3.3. extensions). The registration of a Web Service user shall
create a complicated user credential with username and password that follow strong
security and password complexity rules. The credentials shall be created by the System
automatically or by the RAIS Administrator.
The RAIS Administrator shall be able to assign permissions for specific data views to the
registered Web Service User. The Authorization shall offer permission verification
mechanism through a unique one-time token.

3.2.7 Dashboard (Desirable)

The Dashboard presents information in blocks called modules. Every RAIS user shall have
its own dashboard according to the data role assigned to him/her. The assignment of
permissions to view dashboard modules shall be done under Administration/User
management/Functional roles. Every data role has permissions to one or more modules of
which the dashboard consists. The Dashboard shall follow Modern UI approach using
modern web interaction techniques, i.e. JavaScript, to enable users to organize their
personal space. The organization of dashboards by a User means a User has the
possibility to change the order of the displayed modules or hide/show some of them. Each
module can be expanded or contracted by clicking on the module title bar.
By default, RAIS offers four modules: Welcome module, Tasks module, Statistics module
and Announcements module. Dashboard modules shall be assigned to functional roles
(with “View” permission) in the same way as menu items. By default, every functional role
shall have view permissions to every module.
• Welcome module - displays welcome message and offers “get started” materials;
• Tasks module – displays active tasks related to the logged user. Tasks shall be
linked to enable users to go directly to the assigned task. A task can be a validation,
a notification or process triggers that require action from a specific user or any user
of a specific role;
• Statistics module – displays statistics related to processes and offer analytics views
10
https://msdn.microsoft.com//library/ff649737.aspx

30
 such as charts. Charts shall be customizable to select input from tabular data (from
reports or by QCM) to produce visual graphs. Other parameters like graph colour do
not need to be customizable. At the very least, the following chart types shall be
available: Bar, Line, and Pie;
• Announcements module – displays general announcements or notifications related
to the entire regulatory body or some of the departments. Announcements shall be
added in the menu item, i.e. Tools/Announcements and have a start date and an
end date which defines the time when they are displayed on the dashboard.
Permissions to Add, Edit or Delete Announcements are given to functional roles.
The Information displayed on the dashboard shall be updated automatically without
page refreshing by user action.
The modules shall offer a certain degree of customization such as adding data columns
and filtering the displayed data. The User shall be able to save and export the settings to a
file that can be later imported in different personal user space.
The Administrator shall have additional module for monitoring of the System (see Section
4.6.1 Monitoring).

3.2.8 Reports
The reporting shall follow a modern UI approach and modern UI interaction possibly using,
e.g. JavaScript, libraries to generate charts and tables. The tables displayed in this way
shall allow for sorting and paging, if applicable. Ideally, the chart functionality of the
statistics dashboard module shall also be available in reports.

The report engine shall allow for customization of the query retrieving the data using a
visual designer, avoiding the need for the end-user to have SQL syntax knowledge. The
report engine shall also allow for the report results to be displayed in a chart form, offering
various chart types (minimum Column, Bar and Pie), enabling filtering the results by
parameters (with customizable selection values, e.g. only a subset of Sealed Sources)
either real time or “up front” before generating the report.

The report engine customization applies to queries related for reports and statistics which
are by default in RAIS as well as new ones that will be created.
When customizing the reports and statistics, the Administrator shall be able to modify SQL
queries responsible for collecting data from the database, to perform grouping/ordering
commands, to add aliases of column names and to add images in the report template.
Customization shall cover header and footer of the reports and statistics. Reports and
statistics shall accommodate result view data mappings from complex SQL queries.
In addition to the default reports in the latest version, RAIS 4.0 shall offer performance
reports (calculating statistical values) for all types of default processes (like authorization)
as described in Section 3.2.1, Process Management under Process Monitoring.

3.2.9 Add-Ons (Desirable)

The System shall allow a mechanism for add-on packages to be exported from one RAIS
instance and imported into another instance, e.g. one add-on package could be a set of
related customized entities and processes.

31
To avoid risk that affects the stability of the core System, add-ons shall follow sandbox
approach, e.g. it shall separate customizations made by add-ons by using different data
storage or a different schema in the same database defaulting to “.dbo”. With this
approach, RAIS shall be able to restore the original state of the System when removing an
add-on. Note that add-ons shall be developed by the IAEA or third party entities such as
Member State regulatory bodies. Therefore, RAIS shall expose an API that allows to
“connect” add-ons.
Examples of add-ons (not included in RAIS):
• NDR – National Dose Register
• RADMeter
• Safety Related Records

3.2.10 RAIS Migration Tool

The migration shall be user friendly process to be completed by trained non IT experts /
software developers.
The migration tool shall:
• be able to do prerequisite check before its installation and keep a log about the
activity;
• support versions RAIS 3.2 and RAIS 3.3;
• migrate all previously entered data (data from standard RAIS fields and from
customized fields);
• migrate all settings such as input masks related to the customized fields;
• migrate all files uploaded by previous versions;
• keep a log about migration process;
• be able to roll back the migration in case that migration process completed with
errors;
• be able to roll back the migration in case of unexpected interruption.

3.2.11 Search and Filter Functionalities

The System shall accommodate search functionalities to allow the user to quickly find the
desired entity record. Each entity that is in accordance to the defined user role and is
presented in the user interface shall be searchable. To an end user, the results grid shall
offer additional possibilities of manipulation with the data such as column sorting and
filtering by context (for example order names by alphabet or dates by newest, filter records
by date). Paging or load more functionality shall be offered when displaying a many
records.
Two types of searches shall be available: quick search and advanced search.
Quick Search
When displaying a list of the records of an entity (typically in some kind of grid form such
as the Preselection Lists in RAIS 3.X series), a “quick search” textbox shall be visible at
the top of the grid. Whenever a text is typed into that text box and “enter” is pressed, the
record grid shall filter the records based on the fields containing this text. Fields of an
32
entity as part of a quick search mechanism shall be customizable by the Administrator, and
not necessarily have to be part of the visible fields on the grid, but shall be any field of the
entity.
Advanced Search
For more advanced searches, a specific “advanced search” button shall be visible at all
times when displaying the entity records grid. The advanced search shall provide the
possibility to the user to select one or more fields for search and each field to allow
specifying which condition it shall meet (begins with, contains, does not contain, is greater
than, etc.) and also the value of the condition. The search fields shall not be limited to only
the fields of the current entity. It shall also be possible to include related entity fields in the
search query.
- Example 1: “I want to search for all facilities that have at least one active
authorization of type ‘Transport Authorization’”  main entity to search = facility;
related entity to include = authorization; related entity fields to use in conditions =
status and type
Example 2: “I want to search for all female workers with birthdate earlier than 01/01/1990”
 main entity to search = person (worker); fields to use in conditions = gender and birth
date

3.2.12 File Library (Desirable)

The System shall enable uploading and associating of multiple files on an instance of a
process (e.g. Authorization), process step and a certain entity record.
The metadata of the uploaded files shall contain information regarding the file basic
information, origin of its creation: manual or automatic, and it shall contain an association
to an instance of a process, process step or entity record with an optional association with
their statuses.
The file library feature shall represent a component (see Section 4.2) available for an
instance of a process or entity record.
It shall offer listing of the file repository independently of the associated process, process
step and entity. In addition, it shall offer in-place listing of the documents for a selected
process, process step and entity record and it shall offer filters of the files list by specific
parameters from the metadata.
The choice of allowed file types uploaded shall be a System-wide setting customizable by
the Administrator. By default, however, upload of potentially harmful file types (.exe, .vbs,
.bat, etc.) shall be disallowed.
The actual store location of the file library should be a pluggable System component, i.e.
some countries may wish to store the file library on a classic network drive, other countries
may want to store it in a SQL database, others may want to store it in a SharePoint
environment, etc.

3.2.13 Document Generation

The system shall provide a document generation engine, to allow automatic generation of
documents by composing entity data into a document template with the option to merge

33
fields (e.g. Name = First name + Last name). These templates and merge fields shall be
customizable by an Administrator, and any entity field (standard or custom field) shall
potentially be used as a document merge field.
The document generation engine shall be accessible from the process framework (e.g. to
generate a license document at the end of an authorization process).
The document generation engine shall be able to automatically save the generated
document to a corresponding file library in at least the following output formats: DOCX,
PDF.
The choice of output format shall be part of the template customization by the
Administrator. For example, it shall allow certain document types to be only generated in
PDF so they remain read-only, while other document types shall be generated in DOCX so
they are editable by the user.

3.2.14 Messaging Feature

The System shall have a messaging feature to allow communication between:
- Two users of the System (both ways);
- User to all members of a data role/roles;
- A user of the System and an external contact by e-mail (SMTP) independent or as
part of a process and/or a process step.
The System shall notify the recipient (user or functional role) inside the System by sending
a copy of the message to the user’s personal inbox. The inbox contains messages,
notifications, reminders etc. and are clearly categorized. In addition, the inbox shall be
displayed on the user dashboard (see Section 3.2.7).
Any e-mail communication initiated internally from the System shall carry a tracking token
(e.g. a unique ID in the e-mail header or subject field), so that subsequent replies to this e-
mail shall automatically be linked back to the corresponding process inside the System.
The messages shall have the possibility to contain attachments and the System shall offer
the possibility to the recipient to save the attachments in the file library of the
corresponding process.
The System shall have the ability to track the history of the communications related to a
process.

3.2.15 Administrator System Reports (Desirable)

RAIS 4.0 shall be able to export health monitoring information to enable external support
to have relevant information. Health monitoring shall be automatically resource managing
and rollover logs, e.g. every 4 weeks. Health monitoring shall collect runtime information in
three (3) severity levels: Info, Warning and Error. By default, only Errors are logged but
Administrators shall be able to change the logging level.
Also the Administrator shall be able to execute various reports based on the monitoring
information. The following reports shall be provided out of the box:
• Number of health records grouped by level (Error, Warning) and Exception category
34
 (e.g. database, null-ref, parameter etc.) over a specific time provided as parameter;
• Detail Error report that shall contain full description of any exception;
• A summary SQL profiler report to identify database bottlenecks.

3.2.16 System Backups

RAIS 4.0 shall offer a simple back up functionality that shall allow the Administrators to
perform a modular backup and restore on entity/process level such as Authorization,
Inspection, Enforcement, workers’ doses, sealed/unsealed sources etc.
Performing a backup and restore shall be possible through the UI only with one click after
selecting the desired entity or process. Every backup file shall have the name of the entity
or process, followed by a time stamp. The backup files shall be available and listed for
immediate restore. If necessary, additional backup files shall be uploaded and displayed in
the list of backup files.
Incompatible backup files are backups from RAIS 4.0 instances where the System
customizations influence the entity or process definition. These backups shall not be
restored before importing the necessary entity or process customizations (see Section
3.2.1 and 3.2.2). If incompatible backup file is uploaded, a problem describing message
shall appear.
The functionality shall be very simple to use, and it shall be available in the default RAIS
mode. In addition, it shall function without compatibility issues on the default entities/
processes configuration.

35
3.3 Use Cases
The following Use-Cases are supplementary information to the feature definitions in
Section 3.2. They explain the essential steps and behaviour of the features to be built or
features to be amended from previous RAIS versions. The Use-Cases do not cover every
possible aspect and way of how these features shall operate; therefore, it is assumed that
the features shall be able to perform additional use-cases that are not defined here.

3.3.1 Use Case - Process Management

ID UC1: Process customization
Description To enable administrators to change pre-defined processes / workflows
or to create new well-defined processes.
Actors Administrator
Preconditions Administrator has been logged on and browses to the customization
section for processes.
Basic Steps 1. Administrator opens a pre-defined process for customization
2. Administrator adds/inserts a new step and defines
a. Required data inputs of the step according to entity
customization rules
b. triggers (that may initiate sub-processes, or send
notifications to users of one or more functional roles)
c. Required output - i.e. advance to a next step with some
resulting output info or produce document
d. Optional: logical rules for step behaviour
e. Optional: time-frame for completion
3. Administrator repeats until the process /workflow definition is
complete
Alternate 1. Administrator creates a new process and adds steps as above –
Steps/1 continues from step 2
Exceptions
Business
validations/Rul
es
Post A process has been well-defined/changed and can now be initiated.
conditions

ID UC2: Process initiation

Description To kick off a new instance of a well-defined process/workflow. A
process/workflow may reflect any other real life process of an
organization. The details of the preconfigured processes are specified
in the Support Document “Processes”.
Actors Authenticated User

36
 System
Preconditions The process with required steps, rules and conditions etc. has been
defined by either “out of the box” or by customization through the
administrator.
Basic Steps 1. User explicitly starts an instance of a process by creating a new
record.
2. User goes through the process step by step until external input is
required or the process finishes.
Alternate 1. The System starts an instance of a process automatically after
Steps/1 certain criteria are met or a pre-set timer goes off.
2. The System informs users of assigned functional roles through
the dashboard of the new process instance.
3. One of the notified users goes through the process step by step
until external input is required or the process finishes.

Alternate 1. User changes a data field to a value which has been defined as
Steps/2 a field that shall initiate a new (sub-) process instance.
2. The System informs users of functional roles (as defined in
customization) through the dashboard of the new process
instance.
3. One of the notified users by the System, goes through the
process step by step until external input is required or the
process finishes.
Exceptions If the process initiation encounters issues, the administrator shall be
informed about the fail process initiation by providing error details such
as trigger details and the reason for failure.
Business
validations/Rul
es
Post A process has been initiated and awaits either further input or finishes /
conditions closes out.

ID UC3: Process - resources

Description To enable users assign / book resources required for a given step in a
process.
Actors Administrator
Regulator
Inspector
Preconditions A process is already initiated
Basic Steps 1. The user opens a process step
2. User selects add/remove resources
3. User defines date and time information for the process / process
37
 step
4. A list of related and available resources at that date and time is
displayed (i.e. inspectors and vehicles for inspections, )
5. User saves the modifications
6. The affected RAIS users are notified through their inbox on their
dashboard
Exceptions
Business
validations/Rul
es
Post The selected resources (i.e. inspector and vehicle) are “booked” for the
conditions planned date and if exclusively booked, cannot be selected for any
other activity on that date.

3.3.2 Use Case – Customization

ID UC4: QCM: Query customization (in place)
Description To enable Administrators to modify a certain SQL query in the System.
Actors Administrator
Preconditions 1. The admin shall be logged on.
Basic Steps 1. The admin browses to a dynamic mask which he wants to
customize.
2. The admin clicks a link to activate the customization mode.
3. Admin selects for example a single Lookup field which shows all
entries of a specific table.
4. Admin clicks on a link to open logic customization for that list
5. Admin writes SQL code which filters and limits the entries of that
list e.g. based on values from other fields in that dynamic mask
6. Admin clicks “apply” and tests the new logic.
7. Admin finds that the query needs fine tuning and changes the
query, clicks apply etc. until satisfied with the result.
8. Admin saves and releases the query
Alternate Steps Admin may decide to roll back the customization to the last released
version.
Exceptions None
Business
validations/Rul
es
Post The customized logic is active for other users who use that dynamic
conditions mask as well.

38
ID UC5: Entity customizations: Entity – 1-n references
User Story “As an Administrator I want to manage (Create/Update/Delete) entities
(tables) and their fields with respective data types and relations (1-1 or
1-n) to other entities. The amount of such relations shall not be limited
so for example I can link a Facility to other Facilities in different fields of
the same entity in order to create parent-child relation next to existing
PK constraints and other referrals to the same entity.”
Description To enable administrators to design a 1-many relation multiple times
between the same tables.
Actors Administrator
Preconditions 1. The admin shall be logged on.
Basic Steps 1. The table / entity customization section is open
2. The admin adds a field of type “multiple lookup” to Table A
3. The admin adds another field of type “multiple lookup” to the
same Table A
Alternate Steps None
Exceptions None
Business
validations/Rul
es
Post Both relations are working and can be edited in the regular mask.
conditions

ID UC6: Entity Customizations: Entity – inline help

User Story “As an Administrator I want to be able to add descriptive text to a field
to be displayed in-place when manipulating data by other users.”
Description To allow administrators to provide short help consumed by the users of
a mask.
Actors Administrator
Preconditions 1. The admin must be logged on.
Basic Steps 1. The table / entity customization section is open
2. The admin adds a field of any type and provides additional
descriptive text explaining what kind of data is expected in this
field.
Alternate Steps None
Exceptions None
Business
validations/Rul
es

39
Post A user creating / updating a record of that entity can see this help text,
conditions e.g. by hovering over an (?) icon next to the field.

ID UC7: Entity customizations: Entity – conditional fields

User Story “As an Administrator, I want to define the visibility of a field based on
criteria that involves values provided in other fields. For example, If a
Yes/No field that asks “Requires external input?” received a “Yes” then
an additional selection field “External input source” shall be made
visible/available”.
Description To allow Administrators to provide rules for the visibility of fields
Actors Administrator
Preconditions 1. The admin shall be logged on.
Basic Steps 1. The table / entity customization section is open
2. The admin adds a checkbox field “Requires external input?”
3. The admin adds a new field “Input source” and defines rules to
display/hide depending on the value of “Requires external
input?”
Alternate Steps Same shall apply for single or multiple lookup fields as trigger for
visibility of other fields.
Exceptions None
Business
validations/Rul
es
Post A user creating / updating a record of that entity is only able to see and
conditions enter data in “Input source” when “Requires external input?” is checked.

ID UC8: UI customizations: UI appearance customization

User Story As an Administrator I want to change the colours used in the UI, the text
for headlines and a logo if applicable using the browser. Ideally I want
to do this directly in view of the UI I am using in my daily work and not
in a separate section (in-place).
Description To enable administrators to modify the visual appearance of specific
visual parts of the System.
Actors Administrator
Preconditions The admin shall be logged on.
Basic Steps 1. The admin clicks a link to activate the customization mode
2. The admin selects a link “change logo” in the context menu right
40
 clicking on the logo
3. A file upload opens prompts, the admin selects an image from
the disk and confirms.
Alternate Steps A similar workflow shall apply for changing the title or colours on
specific UI objects used in the System
Exceptions None
Business
validations/Rul
es
Post When saved, the old logo is replaced / title / colours are changed.
conditions

ID UC9: UI customizations: Theme selection

Description To enable a user to choose and activate a UI theme at run time.
Actors Administrator
Preconditions The user must be logged on as Administrator
Basic Steps 1. User clicks on the menu item “Change Theme” which appears in
the admin panel
2. A list of pre-set and self-created themes are shown to the user
with a preview of their colour scheme
3. User selects the theme
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business None
validations/Rul
es
Post The selected theme is activated and applied System wide.
conditions

ID UC10: UI customizations: Theme customization

Description To enable a user to customize the UI theme at run time.
Actors Administrator
Preconditions The user must be logged on as Administrator
Basic Steps 1. User clicks on the menu item “Change Theme” which appears in
the admin panel
2. User selects “create new theme”
3. User is directed to a basic theme creator tool. The tool gives the
User option to select the desired colours for all parts of the
theme (header, font, background etc.)
41
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business None
validations/Rul
es
Post The newly created theme is saved and added to the list of existing
conditions themes.

ID UC11: RAN generation: Manage RAN generation mechanisms

User Story “As an Administrator I want to assign logic to a field that creates a
unique identifier according to customizable rules like Year-
AuthorizationType-FacilityName-incrementing number. The rule how
the number is generated (such as COUNT of records or an AVG or
MAX, etc.) as well as where this rule is applied shall be customizable at
runtime.”
Description To allow the Administrator to create and manage RAN generation
mechanisms
Actors Administrator
Preconditions The user shall be logged on as Administrator
Basic Steps 1. The admin selects RAN Management from the administration
panel
2. A list of all RAN Generation mechanisms is shown
3. Admin selects a RAN Generation mechanism to be managed
and clicks on “edit”
4. A list of all available rule-based formats is displayed
5. The user selects a rule-based format or creates a new one
6. The user selects an existing mask
7. A list of all possible input fields is displayed
8. User assigns parameters and input field values to the selected
rule-based format
9. User clicks Save
10. The Systems offers sample generated RAN numbers
Alternate Steps 1. The admin selects RAN Management from the administration
panel
2. A list of all RAN Generation mechanisms is shown
3. The Administrator clicks “Add” new RAN generation Mechanism
4. All other basic steps are repeated
Exceptions A proper message is displayed containing information about what went
wrong and what to do next
Business
42
validations/Rul
es
Post The changes shall be saved and reflected in the System.
conditions The RAN generation mechanisms are available to be assigned to a
certain mask.

ID UC12: RAN generation: Manage RAN generation rule-based formats

Description To allow the Administrator to create and manage RAN generation
formats based on some rules that accept data from mask input fields,
menu-item names, number producing functions, static numbers, data
retrieved by SQL queries etc.
Actors Administrator
Preconditions The user shall be logged on as Administrator
Basic Steps 1. The user clicks edit a rule-based format
2. A list of all RAN Generation rule-based formats is shown
3. The user selects a rule to be managed and clicks on “edit”
4. The user defines the components of the format by defining rules
for input data from mask input fields or menu items, discrete
number functions, special SQL queries etc.
5. User clicks Save
6. The Systems offers sample generated RAN number in the
defined format
Alternate Steps 1. The Administrator clicks “Add” new rule-based format
2. All other basic steps are repeated
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business
validations/Rul
es
Post The changes shall be saved and reflected in the System.
conditions The RAN generation rule-based formats are available to be used in a
certain RAN generation mechanisms.

3.3.3 Use Case – Administration for System Access and Permissions

Data Role Management

ID UC13: Data role management

User Story “As an Administrator, I want to define new or customize existing data
roles to allow access to data associated to certain Facilities defined by
custom logic.”

43
Description To allow the Administrator to create and manage data roles.
Actors Administrator
Preconditions The user shall be logged on as Administrator
Basic Steps 1. The admin selects Data Roles Management from the
administration panel
2. A list of all existing data roles is shown
3. Admin selects the data role to be managed and clicks on “edit”
4. A list of all entities (region, district, facilities etc.), processes and
process steps are shown
5. The Administrator selects the level of the data role (entity,
process and process steps or custom level defined by QCM) and
creates the role
Alternate Steps 1. The Administrator clicks “Add” new
2. The Administrator enters a role name and creates the role
3. Continues from point 4 as stated in the Basic steps
Exceptions A proper message is displayed containing information about what went
wrong and what to do next
Business None
validations/Rul
es
Post The changes shall be saved and reflected in the System.
conditions The roles can be assigned to RAIS users.

Functional Role Management

ID UC14: Functional role management Add/Edit

User Story “As an Administrator I want to manage (allow or restrict) Create, Read,
Update and Delete access granular by Business processes (see
definition of processes) Entities, customization and administrative
operations.
Description To enable the admin to edit existing functional roles that shall
restrict/allow users to access various areas of the System and assign
proper add, edit, delete and view permissions per entities, processes
and process steps . (Similar with the current implementation in RAIS
3.X series and in addition assigning permissions on tab and field level.
In previous versions of RAIS, the Functional Role manages CRUD
access to menu items)
Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. The user selects Functional Roles from the administration panel
2. All existing functional roles are listed for the user
3. User selects the functional role which needs to be edited
4. The User edits the role name and changes the validation mode.
44
 5. List of all levels (main menu, submenu, menu items, tab items
and fields inside a menu item).is given to a user with an option to
check/uncheck the permissions (add, edit, delete and view)

Alternate Steps 1. The user selects the option “Add New” functional role
2. The User enters the role name and the validation mode
3. Continues from point 5 as stated in the Basic steps

Exceptions A proper message is displayed containing information about what went

wrong and what to do next.
Business The default access privileges and functional roles are given in Section
validations/Rul 3.2.3
es
Post The changes shall be saved and reflected in the System. The
conditions permissions for the existing users of the functional role shall be updated
accordingly.

ID UC15: Functional role management – Delete

Description To enable the admin to delete functional roles that shall restrict users
for the four main activities: add, edit, delete and view.
Actors Administrator
Preconditions The user must be logged on as Administrator.
Basic Steps 1. The user selects functional roles from the administration panel
2. User selects the option “delete functional role”
3. A list of all existing functional roles is given to the user
4. The user selects the functional role
5. A short report is generated, providing the admin a list of users
who have been assigned the functional role
6. User clicks delete and deletes the role
Alternate Steps The same Use-Case applies to Data Roles deletion
Exceptions A proper message is displayed specifying that the role cannot be
removed and users need to be reassigned.
Business The admin cannot delete a function role unless he reassigns or
validations/Rul removes all users from that role.
es The default access privileges and functional roles are given in Section
3.2.3
Post The changes shall be saved and reflected in the System
conditions

45
3.3.4 Use Case – Data Manipulation
ID UC16: Data manipulation – Tool tip availability
Description To guide the user as much as possible when manipulating the data to
avoid potential data entry mistakes.
User Story “As any user I want to see in-place explanatory text for fields while
editing data.”
Actors All users
Preconditions Explanatory text needs to exist for a specific input field.
Basic Steps 1. User opens any entry web form for entity or similar
2. Clicks the Help icon next to it
3. A Tool tip appears with explanation text about the field
Alternate Steps 1. A User hovers with the mouse on a field
2. A Tool tip appears with explanation text about the field
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business None
validations/Rul
es
Post A tool tip (which will contain the explanation text) shall appear when
conditions necessary on all the fields containing an explanation text for the user.

ID UC17: Data manipulation – Tool tip management

Description To enable the Administrator to modify the text displayed in a tooltip for a
given entry field.
Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. User goes to field management in the administration panel
2. A list of existing tables appears for the user to select the desired
table which needs modification
3. User is given a list of existing fields with the option of creating an
explanation text
4. User selects the desired field and clicks on add explanation text
5. Explanation text in the text box and user presses save button
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business None
validations/Rul
es
46
Post A tool tip (which shall contain the explanation text) shall appear when
conditions necessary on all the fields containing an explanation text for the user.

ID UC18: Data manipulation – Repetitive input of similar records

Description To enable users to add new records with prefilled data from existing
records of the same entity type.
Actors All users
Preconditions User is logged on.
Basic Steps 1. User adds a new record
2. User clicks a link “copy from” and enters an identifier of the
record to copy values from
3. User click “apply”
4. The System copies all values from the source record into the
“add” mask
5. User sees and changes certain data e.g. the serial number
6. User clicks “Save”
Alternate Steps
Exceptions
Business
validations/Rul
es
Post The copy of the source record is persisted in the database with some or
conditions none input values changed.

ID UC19: Data manipulation: Data entry approval

User Story “As a role requiring approval - e.g. an external user - I want to enter
data that needs approval by a privileged role to approve - e.g. a
Regulator - before it is permanently reflected in the System. In some
cases, some values like the RAN must be provided by the System
without the ability to change it.”

“As a role privileged to approve I want to review and edit data entered
by non-privileged roles before approving the data and allowing
persistence in the System.”

“As a role privileged to approve I want to see approval tasks in my

dashboard.”

Description To enable a user with assigned validation permissions validate the data
entered by certain user roles which requires approval.

47
Actors User (with validation permissions)
User (without validation permissions)
Preconditions User must be logged in as a user with validation permissions
Basic Steps 1. Data has been entered and submitted for validation.
2. A notification appears in the dashboard of the User about a
pending approval request (or a list of pending approval requests)
3. The user selects the request.
4. If no changes are required, data is approved and a notification is
sent to the initiating user.
5. If changes are required, the approving user can completely
reject the entered data and a notification with the justification of
rejection is sent to the initiating user.
6. The user may start the use case again based on the justification
of rejection.
Alternate Steps 1. The data has been entered and submitted for validation.
2. A notification appears in the dashboard of the User about a
pending approval request (or a list of pending approval requests)
3. The user selects the request.
4. If no changes are required, the entered data is approved and a
notification is sent to the initiating user.
5. If changes are required, the approving user can change / correct
any of the fields and approve the data. A notification of
acceptance - highlighting which modifications have been made -
is sent to the initiating user.
Exceptions None
Business
validations/Rul
es
Post Approved data is accepted in the System and if necessary a RAN
conditions number is automatically assigned to the record by the System.

ID UC20: Data manipulation: Record merging

Description To enable a user to merge two records (duplicates) of the same entity
Actors Administrator
Regulator
Preconditions The user shall be logged on as Administrator/Regulator.
Basic Steps 1. Users focus is on any of the data entry screens
2. User selects record and marks it for merging by pressing the link
“merge” (similar to a “compare product” feature known from
many web shops)
48
 3. The System opens a merge window
4. The System shows a list of records of same entity type as first
record
5. User selects second record from the list provided
6. Merge window shows data from both records side by side
7. User selects one of the two records as the “primary” record
8. User selects the fields to keep the data from as “primary” record,
and the ones as “secondary” record
9. User clicks a “perform merge” button

Alternate Steps
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business All data modifications shall be recorded in a log.
validations/Rul
es
Post Merged records shall be saved and reflected in the System.
conditions The “primary” record gets filled with the correct data according to the
field selections, and all related data from the “secondary” record are re-
linked to the “primary” record, and at the end, the “secondary” record
gets deleted (or flagged as deleted). The System shall keep a history of
merged and deleted records and the merge operation shall be recorded
in the log.

ID UC21: Data manipulation: Duplicate detection

Description To enable users to detect duplicates for records of the same entity
Actors Any user
Preconditions The user shall be logged on and act within his/her functional and data
role permissions.
Basic Steps 1. User selects duplicate detection from the menu
2. List of entities filtered by the user roles is presented
3. User selects the entity
4. User is given a list of all records of the entity
5. User clicks run duplicate detection
6. User is asked to define the combination of columns to run the
duplicate detection
7. User is presented with all duplicate records according to the
duplicate detection rule as set in previous step
8. User is then given the option to merge these records and is
directed to Record merging tool (3.2.4 )
Alternate Steps
Exceptions A proper message is displayed containing information about what went

49
 wrong and what to do next.
Business None
validations/Rul
es
Post
conditions

ID UC22: Data manipulation: UI field input data validation

Description To allow Administrators to provide rules for field input validation.
User Story “As an Administrator, I want to define certain criteria describing valid
data input. For example a numerical PH value must be between 0 and
14.”
Actors Administrator
Preconditions 1. The admin shall be logged on.
Basic Steps 1. The table / entity customization section is open
2. The admin selects an input field e.g. a numeric field of any type
3. The admin provides restrictive rules to limit the allowed values,
for example min 0 max 14 for PH value
Alternate Steps Same shall apply for other field types like text and date.
Exceptions None
Business
validations/Rul
es
Post A user creating / updating a record to a specific entity is not allowed to
conditions enter invalid PH value.

ID UC23: Data manipulation: UI field input coherent validation

Description To allow administrators to provide rules for validation based on the
value of other fields.
User Story “As an Administrator I want to define validation criteria based on other
field values. For example, a field MINIMUM shall always have a lower
number than the correlating field MAXIMUM. Same applies for START
DATE and END DATE.”
Actors Administrator
Any User
Preconditions 1. The admin shall be logged on.
Basic Steps 1. The table / entity customization section is open
2. The admin selects an input field, e.g., a numeric field of any type
3. The admin provides restrictive rule to limit the values allowed to

50
 be greater than a value of another defined field.
Alternate Steps Same shall apply for Numeric: smaller, Date: later and Date: earlier
Exceptions None
Business
validations/Rul
es
Post A user creating / updating a record for a specific entity is not allowed to
conditions enter values violating these particular rules.

3.3.5 Use Case – Data Import

ID UC24: Data import

Description To enable a user to import external data into RAIS.
User Story “As an Administrator, I want to import data into the System from an
external structured data sources like (Excel, XML and CSV) to allow for
bulk imports, e.g., sources or dose records.”
Actors All users with “Import Files” permissions, typically an Administrator and
a Regulator.
Preconditions The user shall be logged on.
Basic Steps 1. User navigates to Tools / Import data menu item
2. User selects target entity for import
3. User uploads the Excel “xslx” or XML file from the computer
4. User selects previously saved mapping of excel columns or XML
nodes / attributes to RAIS entity fields
5. User performs the mapped import
Alternate Steps 1. User navigates to Tools / Import data menu item
2. User selects target entity for import
3. User uploads the Excel “xslx” or XML file from the computer
4. User creates a new mapping of excel columns or XML nodes /
attributes to RAIS entity fields
5. User performs the mapped import
Exceptions In case of failure all data manipulation completed during the data import
must be rolled back.
Business Data import mechanism shall ensure transactional consistency i.e. not
validations/Rul leaving data in an inconsistent state if data import is not successful.
es
Post The uploaded data shall become part of the database and shall be
conditions visible through RAIS.

51
3.3.6 Use Case – Web Services

ID UC25: Web services: Secure data transmission

Description To enable secure data export through an xml interface.
Actors External systems using a RAIS user (e.g. wsuser) which is authorized
to use a specific web service.
Preconditions
Basic Steps 1. External system issues a request with Basic Authentication (see
1st tier authentication “RAISWS”) 11over SSL providing
credentials of wsuser as POST parameters
2. RAIS issues a token valid for only one remote procedure call
3. External system issues a request over SSL to a RAIS https://url
which correlates to the web service method. Relevant
parameters and the authorization token shall be transported by
POST or Query parameters
4. RAIS returns plain XML (without SOAP envelope) to the caller
Alternate Steps Additionally RAIS shall limit a wsuser to allow calls from a certain IP
address or host name.
Exceptions Meaningful errors shall be returned to the caller in XML format.
Business External system can only access web service methods assigned to
validations/Rul their RAIS user.
es
Post None
conditions

3.3.7 Use Case – Dashboard

ID UC26: Dashboard: Availability

User Story “As a user I want to see tasks assigned to my role (such as overdue
processes, data awaiting approval …), simple reports and charts in one
place - my landing page or ‘desktop’. I want to organize and modify the
layout (in-place) according to my needs and also customize the queries
gathering the information shown on the dashboard.”
Description To provide information to every RAIS user according to the functional
role assigned to the user account. (described in sec 3.2.7 )
Actors All users
11
See RAIS 3.3 Extensions 3.6

52
Preconditions The user shall be logged on.
Basic Steps 1. User logs in and is directed to the dashboard (home page)
2. User sees modules according to their roles. By default, RAIS
shall have the 4 modules for every user and an additional Admin
module for Administrator
Alternate Steps 1. User is already logged in
2. User clicks on the dashboard menu item to navigate to the
dashboard area.
Exceptions The modules shall load asynchronously and a proper error message
shall be displayed only on the ones that failed to load.
Business The user shall only see the modules permitted to their data role.
validations/Rul
es
Post None
conditions

ID UC27: Dashboard – Personal space

Description To enable User to organise/personalise their dashboard.
Actors All users
Preconditions The user shall be logged on.
Basic Steps 1. User goes to the dashboard
2. User selects “edit” the dashboard
3. User selects the modules to hide/show (expand/contract)
4. User drags the selected modules to change their order
5. User saves the changes
Alternate Steps 1. User adds a new statistics module
2. User selects a report from menu “Query” or “Statistics” and pre-
sets the report parameters
3. User defines a chart type and columns from the report to feed
the chart
4. User saves the new statistics module

Exceptions A proper message is displayed containing information about what went

wrong and what to do next.
Business Modern UI approach using modern web interaction techniques shall be
validations/Rul followed to enable users to organize their personal space.
es
Post The changes made are saved and reflected in the System.
conditions

ID UC28: Dashboard – Export

53
Description To enable user to export a personalized dashboard.
Actors All users
Preconditions The user shall be logged on.
Basic Steps 1. User goes to the dashboard
2. User selects “export/import” option
3. User saves their personalized dashboard (as a downloadable file
on their System)
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business None
validations/Rul
es
Post A file is saved on the users’ PC which can be imported to RAIS.
conditions

ID UC29: Dashboard – Import

Description To enable the user to import a personalized dashboard.
Actors All users
Preconditions The user shall be logged on.
Basic Steps 1. User goes to the dashboard
2. User selects “export/import” option.
3. User uploads the file of a personalized dashboard
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business When Importing a dashboard, the visual settings from the imported file
validations/Rul are applied. In addition, the content of the statistics module shall be in
es compliance with the user’s data and functional roles.
Post Users’ dashboard is updated to the new imported personal space. New
conditions modules are visible and organized as defined by the imported personal
space.

3.3.8 Use Case – Reports

ID UC30: Reports – Generation
Description To enable all RAIS users to generate reports from the existing records.
User Story „As a user, I want to export reports as pdf, .docx and .xslx including
generated charts where applicable.“

54
Actors All users
Preconditions The user shall be logged on.
Basic Steps 1. User goes to the reports from the menu
2. User selects “list of reports for entities”, “list of reports for
processes” or “default reports”
3. User selects the entity/process for which the report shall to be
generated (or selects a default report)
4. User provides the necessary information on the Filter page such
as dates or any other relevant information
5. User specifies the type of charts to be displayed if the report
offers data for charting
6. User is given the option to preview the report online
7. User selects preview online
8. The report is generated and the user is given the option to filter
the data according to their needs by adding or removing
columns, sorting and filtering with various conditions

Alternate Steps The user is given the option to export the report (in pdf, doc etc) to their
System.
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business None
validations/Rul
es
Post The user can download the report as a file (e.g. pdf, doc or xls)
conditions The user can view the report on their System.

ID UC31: Reports – Data query customization

Description To enable RAIS Administrators to add a new or customize the queries
for reports.
Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. User goes to the reports from the admin panel
2. User selects “list of entities” or “list of processes”
3. User selects the entity/process for which a new report shall to be
generated
4. User clicks on “add new report”
5. User is asked to fill in the details for the report (e.g. name)
6. User clicks add new query
7. User is then directed to QCM, where the user can manually write

55
 a query using SQL syntax or can use visual designer
8. User saves the query
9. User adds charts related to the query
10. User saves the report
Alternate Steps 1. User goes to “reports” from the menu
2. User selects “list of entities”, “list of processes” or “default
reports”
3. User sees the list of entities/processes/default reports
4. User selects the report which needs to be edited
5. User clicks edit query
6. User is then directed to QCM, where the user can manually write
a query using SQL syntax or can use the visual designer
7. User adds/edits charts related to the query
8. User saves the query
User saves the report
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
In case of SQL syntax or similar error, the message shall be descriptive
to guide the Administrator to fix the problem.
Business None
validations/Rul
es
Post The newly added reports shall be saved in the System and are shown
conditions under the list of reports for all users.
The edited reports should be saved and all the generated reports after
editing should reflect the changes made.

ID UC32: Reports – Layout customization

Description To enable RAIS administrators add a new or customize an existing
report such as report layout, report images and figures.
User Story “As an Administrator I want to create or customize reports including
graphs and tables with filters used when viewing the report. Filters shall
only allow values that actually return results.”

Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. User goes to reports from the admin panel
2. User selects “list of entities” or “list of processes”
3. User selects the entity/process for which a new report shall be
generated
4. User clicks on “add new report”
5. User is asked to fill in the details for the report (e.g. name)
56
 6. User creates a new or selects a predefined desired layout
7. User executes the basic steps from Use Case UC32 and
connects it to a block of the report layout
8. User adds report images, figures or customizes header footer
9. User saves the report
Alternate Steps 1. User goes to reports from the admin panel
2. User selects “list of entities” or “list of processes”
3. User selects the entity/process to edit an existing report
4. User selects the report
5. User modifies details for the report (e.g. name)
6. User goes through the Use Case Reports: Data Query
Customization and connects it to a block in the report layout
7. User adds/modifies report images, figures or customizes header
footer
8. User saves the report
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
In case of SQL syntax or similar error, the message shall be descriptive
to guide the Administrator to fix the problem.
Business None
validations/Rul
es
Post The newly added reports shall be saved in the System and are shown
conditions under the list of reports for all users.
The edited reports shall be saved and all the generated reports after
editing shall reflect the changes made.

3.3.9 Use Case – Add-Ons

ID UC33: Add-Ons - import

Description To enable the admin to import external add-ons to RAIS.
User Story “As an Administrator, I want to import customizations made by others
via add-ons without compromising the consistency of the System. I also
want to be able to uninstall an add-on and to restore the System state
prior to the installation of the add-on.”
Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. User selects add-ons from the admin panel
2. User sees a list of all connected add-ons already existing in the
System
3. User selects “connect a new add-on”

57
 4. User is asked to upload the related file
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business Add-ons shall follow sandbox approach. It’s preferable to save the
validations/Rul customizations made by add-ons on a different data storage or different
es database schema in the same database.
Post The connected add-on shall appear as a new menu item throughout the
conditions System.

ID UC34: Add-Ons - export

Description To enable the admin to export related menu items as a RAIS add-ons.
User Story “As an Administrator I want to export customizations in an add-on
package that can be imported at a different RAIS installation.”
Actors Administrator
Preconditions The user shall be logged on as Administrator
Basic Steps 1. User selects add-ons from the admin panel
2. User selects menu items which shall be packed into the add-on
3. User downloads the add-on definition to the local disk.
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business All entity definitions related to the selected menu items (including data,
validations/Rul roles etc.) shall be packed into an add-on. If the admin wants to export
es only certain data, he/she shall delete unwanted data from the tables
first.
Post The downloaded add-on contains all relevant definitions and data to be
conditions imported into another RAIS installation.

3.3.10 Use Case – RAIS Migration Tool

ID UC35: Migration tool

Description To enable admin to migrate from a previous version of RAIS to RAIS
4.0.
User Story “As an Administrator I want to migrate existing data from previous
versions of RAIS into the new System without requiring third party
software.”

58
Actors Administrator
Preconditions At minimum, RAIS 3.2 version is required.
Basic Steps 1. User runs the executable (.exe file) of RAIS migration tool
2. A pre-requisite check is done by the tool to check if the computer
system has all the requirements necessary for RAIS 4.0
3. The log for pre-requisite check is shown
4. The tool migrates all the previously entered data (standard and
custom fields)
5. Migrates all settings
6. Migrates all uploaded files
7. Migrates all customizations
8. Migration complete message for the user
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
The changes performed are reverted back and RAIS is set to the initial
status – same as prior to running the migration.
Business 1. The migration tool shall maintain a log about the process.
validations/Rul 2. The migration tool shall be able to revert back to previous
es version, in case the migration process ends with errors or
unexpected interruptions.
Post RAIS 4.0 shall be installed on the System with all the data from the
conditions previous version.

3.3.11 Use Case – Search and Filter Functionalities

Quick Search

ID UC36: Quick search – For users

Description To enable all RAIS users to quickly find the entity records.
Actors All Users
Preconditions The user shall be logged on.
Basic Steps 1. User selects database entity
2. List of all records is presented to the user with “paging” or “load
more” functionality
3. User types in the keyword in the “quick search” field and presses
enter
4. Search tool provides results of all records containing the
keyword in any of the fields of the entity
Alternate Steps 1. User orders or filters the results by clicking on the column names
of the results grid
2. User types in the keyword in the “quick search” field and presses
enter
3. Search tool provides results of all records containing keyword in

59
 any of the fields of the entity
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.
Business All entities presented in the interface shall be searchable by any field
validations/Rul including the ones not part of the visibile fields of the grid. The
es prerequisite is customizable by using QCM by the Administrator.
Post The filtered results can be selected and worked on by the user.
conditions

ID UC37: Quick search – Customization

Description To enable the Administrator decide which fields of the entity are to be
searched for.
Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. User selects “Customise Search Tool” from the admin panel
2. List of all entities is presented to the user
3. User selects the entity for which the search tool shall be
customised
4. List of all fields are presented to the user
5. User checks the “checkboxes” to select the fields to search by
keyword
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.

Business All entities presented in the interface shall be searchable.

validations/Rul
es
Post Changes made shall be saved and reflected in the System for future
conditions reference.

Advanced Search

ID UC38: Advanced search – For users

Description To enable all RAIS users find the entity records with the possibility to
select all to search.
Actors All Users
Preconditions The user shall be logged on.
Basic Steps 1. User selects the entity
2. List of all records is presented to the user
3. User sees an Advanced search button (next to the quick search
tool bar) on the top of the list
60
 4. User is directed to advanced search page
5. User types in the keyword and selects the entity, process or
process step fields to be search. If necessary, related entity,
process and process step shall be included in the advanced
search.
6. User optionally adds condition rules such as: comparison, flags,
starts with etc.
7. User presses search button
8. Search tool provides results of all records containing keyword in
the selected fields of the entity
Alternate Steps None
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.

Business All entities presented in the interface shall be searchable and all fields
validations/Rul in the entity shall be selectable (except System core fields).
es
Post
conditions

3.3.12 Use Case – File Library

ID UC39: File Library: In-Place File Management
Description Enables users to download, edit or delete files associated with a certain
process, process step or entity. Offers in-place listing in association with
the parent owner.
Actors Authorized Users
Preconditions User shall be logged in with relevant functional and data roles.
Basic Steps 1. User navigates to a process instance, process step or entity
2. A list of associated files is presented to the user
3. User selects a file from the list
4. User downloads or deletes the file
Alternate Steps 1. User navigates to a process instance, process step or entity
2. A list of associated files is presented to the user
3. User selects a file from the list
4. User edits the file metadata or re-associates the file to a different
entity, process, process step
5. User saves the file metadata
Exceptions A proper message for harmful files, maximum size exceeded or library
unavailability shall to be displayed with a relevant explanation.
Business Users who do not have assigned Data and Functional roles are not
validations/Rul allowed to perform any of the operations. Uploading potentially harmful
es file types (.exe, .vbs, .bat etc.) shall be disallowed by default.

61
Post The file is edited, deleted or downloaded to the desired location.
conditions

ID UC40: File library: File management

Description Enables users to view, edit or delete files associated with a certain
process, process step or entity. Offers independent file library listing.
Actors Authorized users
Preconditions User shall be logged in with relevant functional and data roles.
Basic Steps 1. User navigates to the File Library.
2. User sees a list of uploaded files grouped by entity, process or
process step
3. User shall search file by providing a keyword
4. In addition, the user shall filter the results by certain criteria such
as a filename, process/entity name and process step or upload
date
5. User selects the file from the result list
6. User downloads or deletes the file
Alternate Steps 5. User selects a file from the result list
6. User edits the file metadata or re-associates the file to a different
entity, process, process step
7. User saves the file modifications
Exceptions A proper message for harmful files, maximum size exceeded or library
unavailability needs to be displayed with a relevant explanation.
Business Users who do not have assigned Data and Functional roles are not
validations/Rul allowed to perform any of the operations. Uploading potentially harmful
es file types (.exe, .vbs, .bat etc.) shall be disallowed by default.
Post The file is edited, deleted or downloaded to the desired location.
conditions

ID UC41: File library – Upload files

Description To enable RAIS users to attach files to an instance of a process,
process step or to a certain entity.
Actors Authorized Users
Preconditions The user shall be logged on.
Basic Steps 1. User goes to File library from the menu
2. User clicks “upload new file/files” and selects the file/files to be
uploaded
3. User is asked to fill the metadata (name, origin of creation etc.)
4. User is asked to associate the file to a process, process step or
an entity
5. A list of entities, process steps or processes associated with the

62
 user data role is displayed.
6. User makes the selection and the file/files is/are uploaded to the
library and associated with the process/process step/entity
Alternate Steps 1. User is on a process step, process or entity
2. User clicks “upload new file/files” and selects the file/files to be
uploaded
3. User is asked to fill the metadata (name, origin of creation etc.)
4. User saves the changes and the file/files is/are uploaded to the
library and associated with the process/process step/entity
Exceptions A proper message for harmful files, maximum size exceeded or library
unavailability needs to be displayed with a relevant explanation.
Business Uploading potentially harmful file types (.exe, .vbs, .bat etc.) shall be
validations/Rul disallowed by default.
es
Post The uploaded and associated files shall be accessed through the file
conditions library and as well as through the associated process/entity.

ID UC42: File library – Customization

Description To enable RAIS admin to modify the allowed file types to be uploaded
and to set/change the storage location of files.
Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. User goes to File library settings from the admin panel
2. User selects “allowed file types”
3. User sees all the file types allowed to be uploaded
4. User selects “add new file type”
5. User types in the new file type
6. Clicks ok
Alternate Steps 1. User goes to File library settings from the admin panel
2. User selects “store location”
3. User sees the current storage location
4. User clicks “change storage location
5. User is given option to change location path or to store files on a
Database
6. User makes the selection and clicks ok
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.

Business Uploading potentially harmful file types (.exe, .vbs, .bat etc.) shall be
validations/Rul disallowed by default.
es Maximum file size shall be specified by the Administrator.

63
Post The changes made shall be saved.
conditions The new file types shall now be allowed to be uploaded by all users.

3.3.13 Use Case – Document Generation

ID UC43: Document generation
Description To enable automatic generation of documents by merging entity data
into a customisable document template.
Actors
Preconditions The user shall be logged on.
Basic Steps 1. User selects a process from the menu
2. All predefined document forms are listed to the user
3. User selects the document form
4. User selects the output format of the document
5. User clicks on “generate document”
Alternate Steps None
Exceptions A proper message that the document cannot be generated is displayed
with an explanation about the errors, e.g. incomplete information.
Business The System produces a populated document form with data from the
validations/Rul relevant entities in docs or pdf format.
es
Post The generated document is automatically saved on the file library and
conditions is associated with the process/process step it was generated for.

ID UC44: Document generation - customization

Description To enable the admin to customize the document template needed for
the document forms.
Actors Administrator
Preconditions The user shall be logged on as Administrator
Basic Steps 1. User selects document generation from the admin panel
2. User sees the list of existing templates for every process
definition, and can filter them by process
3. User selects the template to be modified
4. User can select the entity fields to be used as document merge
fields
5. User edits the layout of the template by moving the display of the
related entity data and changing the static text and images within
the template
Alternate Steps 1. User selects document generation from the admin panel
2. User selects the desired process definition and clicks create
document template

64
 3. User selects the entity fields to be used as document merge
fields
4. User edits the layout of the template by moving the display of the
related entity data and changing the static text and images within
the template
Exceptions A proper message is displayed containing information about what went
wrong and what to do next.

Business The output file shall be docx or pdf.

validations/Rul
es
Post The changes shall be saved and reflected in all future document
conditions generation.

3.3.14 Use Case – Messaging Feature

ID UC45: Messaging Feature
Description To enable users send and receive messages with attachments in the
context of a process instance / process step, or entity record.
Actors Authorized Users
Preconditions The user shall be logged on.
Basic Steps 1. A certain step requires additional documentation in order to
proceed, i.e. a regulator needs additional documentation to
advance an authorization process
2. The process step that is initiated automatically or by a relevant
user, sends a message to a recipient i.e. A regulator sends a
notification to the user who requested the authorization (user A).
3. The recipient receives a message in his dashboard i.e. User A
receives the notification in his dashboard.
4. Additionally the recipient gets a notification by email including a
direct link to respond within RAIS.
5. The user replies within RAIS by attaching e.g. a .pdf file.
Alternate Steps The message is sent over SMTP, the response is received in an email.
Exceptions
Business
validations/Rul
es
Post The reply (including the file) shall be attached to the authorization
conditions process step originating the message.

65
3.3.15 Use Case – Administrator System Reports

ID UC46: Administrator System logs

Description To enable Administrators to get help from IAEA to address precisely
described and monitored issues.
User Story „As an Administrator I want to be able to send System- and error logs to
IAEA so they can provide further support in case something breaks
down or does not behave as expected.“
Actors Administrator
Preconditions The admin shall be logged on.
Basic Steps 1. The admin navigates to System Reports
2. The admin clicks show log
3. The System displays the log in a web browser
4. The admin can download the log file
5. The admin uses an external email program to ask a third party
for help by attaching the log.
Alternate Steps
Exceptions
Business None
validations/Rul
es
Post
conditions

ID UC47: Administrator System reports

Description To enable Administrators get an overview of the health status of the
System.
Actors Administrator
Preconditions The admin shall be logged on.
Basic Steps 1. The admin navigates to System Reports e.g. to “Statistics”
2. The admin selects one System health report
3. The admin modifies the report parameters as desired.
4. The admin clicks generate
5. The System displays the report in a web browser
6. The admin downloads the report
Alternate Steps
Exceptions
Business None
validations/Rul
es

66
Post
conditions

3.3.16 Use Case – System Backups

ID UC48: System backups: Database Backup

Description To enable RAIS admin perform a backup on a specific entity/entities
in RAIS.
Actors Administrator
System
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. The user navigates to the admin area and selects the backup
menu item
2. The user selects a preferred entity (one, many or all)
3. The user clicks the backup button
4. The System backups the selected parts of the database
Alternate Steps None
Exceptions A proper message is displayed if the backup was not successful.
Business The backup shall be saved separately in a subfolder for each module
validations/Rules (e.g. Sources, Authorization, and Inspection etc.) with the same file
name.
Post conditions The System automatically saves the backup file and displays it in the
file list for an easy restore.

ID UC49: System backups: Database restore

Description To enable RAIS admin restore a backup on a specific entity/entities in
RAIS.
Actors Administrator
System
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. The user navigates to the admin area and selects the backup
menu item
2. The user selects a preferred entity (optional)
3. The user selects a backup file from the list of backups
4. The user clicks the restore button
5. The System restores database
Alternate Steps 1. The user navigates to the admin area and selects the backup
menu item
2. The user selects a preferred entity (optional)
67
 3. The user uploads a backup file
4. The user clicks the restore button
5. The System restores database
Exceptions A proper message is displayed if the restore was not successful.
In case the backup file comes from a different RAIS 4.0 instance a
message for incompatible backup file is displayed.
Business
validations/Rules
Post conditions The System database contains the data from the backup file. The old
data is overridden.

ID UC50: System backups: Delete backup files

Description To enable RAIS admin to delete the saved database files.
Actors Administrator
Preconditions The user shall be logged on as Administrator.
Basic Steps 1. The user navigates to the admin area and selects the backup
menu item
2. The user selects a preferred entity (optional)
3. The user selects a backup file from the list of backups
4. The user confirms and click delete file
5. The System deletes the file
Alternate Steps 1. The user goes to physical location where the backup files are
located
2. The user deletes the backup files manually from each
subfolder
Exceptions A proper message is displayed if the deleting process was not
successful.

Business None
validations/Rules
Post conditions

68
3.4 Entity Relationship Diagrams
The following entity relationship diagrams represent modified default Regulatory
Processes. They show the findings for adaption of the entities for the altered processes
based on the entity relationship diagrams from RAIS 3.X series, which are described in
“RAIS 3.1 Web Administrators Guide - Part II.doc – Annex Entity Relationship Diagrams”.
The altered processes are reflected in certain database tables which are marked with
different colours. The colour legend for the tables is as follow:
• White depicts no change in structure (attributes);
• Grey depicts change in structure (new attributes);
• Blue depicts existing table that was not in the diagrams before.

69
3.4.1 Authorizations
Department

PK PK Department ID

U1 Regulatory Authority Number

Department Name
Legal Person
I1 FK Facility Status ID
FK1,I3 FK Facility ID
I4 FK Region ID
I2 FK District ID
Address Authorization Asso
Phone PK PK Authorization Asso ID
Fax
RAIS_TIME_STAMP RAIS_TEMP
FK1,I2 FK Authorization ID
I1 FK Asso ID
RAIS_TIME_STAMP
Authorization Generator

PK PK Authorization Generator ID
Facility
RAIS_TEMP
PK PK Facility ID Authorization Sealed
FK1,I1 FK Authorization ID
I2 FK Generator ID
U1 Regulatory Authority Number PK PK Authorization Sealed ID
RAIS_TIME_STAMP
Facility Name
Legal Person RAIS_TEMP
I2 FK Facility Status ID FK1,I1 FK Authorization ID
I3 FK Region ID I2 FK Sealed ID
I1 FK District ID RAIS_TIME_STAMP
Address Authorization
Phone
Fax PK PK Authorization ID
RAIS_TIME_STAMP
U1 Authorization Process Number
Authorization Unsealed
FK1,FK2,I2 FK Facility ID
I1 FK Department ID PK PK Authorization Unsealed ID
Date
Expiry Date RAIS_TEMP
Authorization Type FK1,I1 FK Authorization ID
RAIS_TIME_STAMP I2 FK Unsealed ID
FK Author_type ID RAIS_TIME_STAMP
Authorization History Payment_Reqd
Payment_Feedback
PK PK Authorization History ID RA_Reqd
Inspection_Reqd
FK1,I1 FK Authorization ID Additional_Info_Reqd
Status Date Authorization Person
Authorization Status No
PK PK Authorization Person ID
FK2,I2 FK Authorization Status ID
Comments
Authorization History Officer RAIS_TEMP
RAIS_TIME_STAMP
FK1,I1 FK Authorization ID
PK PK Authorization History Officer ID I2 FK Person ID
RAIS_TIME_STAMP
RAIS_TEMP
I1 FK Authorization History ID
FK2,I2 FK Officer ID
RAIS_TIME_STAMP

Officer
Authorization Status
PK PK Officer ID
PK PK Authorization Status ID
Officer Name
Authorization Status I2 FK Sex ID
RAIS_TIME_STAMP I1 FK Authority ID
RAIS_TIME_STAMP

Figure 10

70
3.4.2 Inspection
Non-Compliance Inspection Asso
PK PK Non-Compliance ID PK PK Inspection Asso ID

Name RAIS_TEMP
FK1,I1 FK Category ID FK1,I1 FK Inspection ID
RAIS_TIME_STAMP FK2,I2 FK Asso ID
RAIS_TIME_STAMP

Inspection Generator
Inspection Non-Compliance
Facility PK PK Inspection Generator ID
PK PK Inspection Non-Compliance ID
PK PK Facility ID RAIS_TEMP
RAIS_TEMP FK1,I1 FK Inspection ID
U1 Regulatory Authority Number FK2,I2 FK Generator ID
FK1,I1 FK Inspection ID
Facility Name RAIS_TIME_STAMP
FK2,I2 FK Non-Compliance ID
Legal Person
RAIS_TIME_STAMP
I2 FK Facility Status ID
I3 FK Region ID Inspection Sealed
I1 FK District ID
Address PK PK Inspection Sealed ID
Phone
Fax Inspection RAIS_TEMP
RAIS_TIME_STAMP FK1,I1 FK Inspection ID
PK PK Inspection ID FK2,I2 FK Sealed ID
RAIS_TIME_STAMP
U1 Inspection No
FK2,I3 FK Facility ID
Department FK1,I2 FK Department ID
Regular Inspection Inspection Unsealed
PK PK Department ID
Full Inspection
Announced Inspection PK PK Inspection Unsealed ID
U1 Regulatory Authority Number
RAIS_TIME_STAMP
Department Name RAIS_TEMP
Legal Person FK1,I1 FK Inspection ID
I1 FK Facility Status ID FK2,I2 FK Unsealed ID
FK1,I3 FK Facility ID RAIS_TIME_STAMP
I4 FK Region ID Inspection Status
I2 FK District ID
Inspection History PK PK Inspection Status ID
Address
Phone PK PK Inspection History ID Inspection Status
Fax
RAIS_TIME_STAMP Inspection Preparation Phase
RAIS_TIME_STAMP FK2,I2 FK Inspection ID
Status Date PK PK Inspection Preparation Phase ID
FK1,I1 FK Inspection Status ID
Comments FK1,I1 FK Inspection Status ID
RAIS_TIME_STAMP Pre-Inspection Meeting
Review of Relavent Documents
Officer

PK PK Officer ID

Officer Name Inspection History Officer

FK2,I2 FK Sex ID Inspection History Status Attachments
PK PK Inspection History Officer ID
FK1,I1 FK Authority ID
RAIS_TIME_STAMP PK PK Inspection History Status Attachments ID
RAIS_TEMP
FK1,I1 FK Inspection History ID FK1,I1 FK Inspection History ID
FK2,I2 FK Officer ID Name of Document
RAIS_TIME_STAMP Path
Status
Hyperlink

Figure 11

71
3.4.3 Radiological Events
Inspection Radiation Events

PK PK Inspection ID Radiation Events Report Stakeholders PK PK Radiation Events ID

U1 Inspection No PK PK Radiation Events Report Stakeholders ID U1 Radiation Event Number

I3 FK Facility ID Date
I2 FK Department ID FK1,I1 FK Radiation Events ID Location
Regular Inspection Stakeholder Type Narrative
Full Inspection Stakeholder ID RAIS_TIME_STAMP
Announced Inspection Required Inspection
RAIS_TIME_STAMP Event Analysis FK1,I3 FK Inspection ID
Report Sent to Stakeholders
PK PK Event Analysis ID

RAIS_TIME_STAMP
Event Analysis Radiological Concequences Event Analysis Event Cause
FK1 FK Radiation Events ID
PK PK Event Analysis Radiological Concequences ID Lessons Learnt
PK PK Event Analysis Event Cause ID
Corrective Actions
FK1 FK Event Analysis ID FK1 FK Event Analysis ID
FK2 FK Radiological Concequences ID FK2 FK Event Cause ID
RAIS_TIME_STAMP RAIS_TIME_STAMP

Event Analysis Health Consequences

PK PK Event Analysis Health Consequences ID

Radiological Concequences FK1 FK Event Analysis ID

FK2 FK Health Consequences ID
PK PK Radiological Concequences ID
RAIS_TIME_STAMP
RAIS_TIME_STAMP
Event type description Event Cause
Number PK PK Event Cause ID
Health Consequences

PK PK Health Consequences ID RAIS_TIME_STAMP

Cause
RAIS_TIME_STAMP
Health Consequences

Figure 12

72
3.4.4 Development of Regulations and Guidance
Development Regulations Status

PK PK Development Regulations Status ID

Development Regulations Status

RAIS_TIME_STAMP

Development Regulations History Officer

PK PK Developement Regulations History ID PK PK Officer ID

FK1,I1 FK Development Regulations ID Officer Name

Status Date I2 FK Sex ID
FK2,I3 FK Development Regulations Status ID I1 FK Authority ID
FK3,I2 FK Officer ID RAIS_TIME_STAMP
Comments
RAIS_TIME_STAMP

Development Regulations

PK PK Development Regulations ID

U1 Regulatory Authority Number

Title
Objectives and Description
RAIS_TIME_STAMP

Figure 13

73
3.4.5 Review and Assessment
Review and Assessment History

PK PK Review and Assessment History ID

Department
Status Date PK PK Department ID
FK1,I1 FK Review and Assessment Status ID
FK2,I2 FK Review and Assessment ID U1 Regulatory Authority Number
Reviewer Department Name
Reviewer Organization Legal Person
RAIS_TIME_STAMP I1 FK Facility Status ID
FK1,I3 FK Facility ID
I4 FK Region ID
I2 FK District ID
Address
Phone
Review and Assessment Fax
Review and Assessment Status RAIS_TIME_STAMP
PK PK Review and Assessment ID
PK PK Review and Assessment Status ID
U1 Regulatory Authority Number
Review and Assessment Status FK3,I1 FK Authorization ID
RAIS_TIME_STAMP FK2,I2 FK Facility ID
FK1,I3 FK Department ID
Comments Authorization
RAIS_TIME_STAMP PK PK Authorization ID

U1 Authorization Process Number

FK1,I2 FK Facility ID
FK2,I1 FK Department ID
Date
Expiry Date
Facility Authorization Type
RAIS_TIME_STAMP
PK PK Facility ID FK Author_type ID
Payment_Reqd
U1 Regulatory Authority Number Payment_Feedback
Facility Name RA_Reqd
Legal Person Inspection_Reqd
I2 FK Facility Status ID Additional_Info_Reqd
I3 FK Region ID
I1 FK District ID
Address
Phone
Fax
RAIS_TIME_STAMP

Figure 14

74
3.5 Data Dictionary
The data dictionary sub-chapter provides a detailed overview of the modified database
tables and is based on the entity relationship diagrams described in Section 3.4. Attributes
that are new, modified or contain new content are explained in this section.

3.5.1 Authorization
Authorization Table

Attribute Type Optional? Notes

Payment_Reqd Boolean Yes
Payment_Feedback Boolean Yes
RA_Reqd Boolean Yes
Inspection_Reqd Boolean Yes
Additional_Info_Reqd Boolean Yes

Authorization Status Table

Attribute Type Optional? Notes
Additional content to be added:
Authorization - “Review and Assessment Ongoing”
Nvarchar(50) No
Status - “Pre-authorization Inspection
Ongoing”

3.5.2 Inspection
Inspection
Attribute Type Optional? Notes
- 0 = No
Regular (Planned) Inspection Boolean Yes
- 1 = Yes
- 0 = No
Full Inspection Boolean Yes
- 1 = Yes
- 0 = No
Announced Inspection Boolean Yes
- 1 = Yes

Inspection Status
Attribute Type Optional? Notes
Additional content to be added:
- “Preparation Phase”
Inspection Status nvarchar(50) No
(Additional information is
entered in the ‘Inspection

75
 Preparation Phase’ table
only when this status is
selected)
- “Report attached”
(Additional information is
entered when uploading
the report in the related
‘Inspection History Status
Attachments’ table)
- Enforcement Required (if
selected, it should trigger
enforcement process and
the default inspection
process would proceed)

Inspection Preparation Phase

Attribute Type Optional? Notes
PK Inspection History ID Int No Primary Key
Foreign Key to associate
FK Inspection Status ID Int No records with only status =
“Preparation Phase”
Pre-Inspection Meeting Boolean No Default value = false

Review of Relevant Documents Boolean No Default value = false

Inspection History Status Attachments

Attribute Type Optional? Notes
PK Inspection History status
Int No Primary Key
Attachment ID
Foreign Key to associate
FK Inspection History Status
Int No records from Inspection
ID
History Statuses
Name of document nvarchar(200) No

Path nvarchar(200) No

Status nvarchar(20) Yes Draft or Final

Hyperlink nvarchar(200) Yes

3.5.3 Radiological Events

76
Radiation Events

Attribute Type Optional? Notes

Required Inspection Boolean No
Foreign key of the required
FK Inspection ID Int Yes inspection only if (Required
Inspection = True)

Default = false;
Report Sent to If True a related record in
Boolean Yes
Stakeholders the ‘Radiation Events
Report Stakeholders’ table
must be entered

Radiation Events Report Stakeholders

Attribute Type Optional? Notes

PK Radiation Events Report
int No
Stakeholders ID
Stakeholder Type Char No Facilities = “F” or Authority = “A”
Fictive Foreign Key to Facilities
Stakeholder ID Int No or Authority tables depending of
the Stakeholder Type

3.5.4 Development of Regulations and Guidance

Development Regulations
Attribute Type Optional? Notes
PK Development
Regulations ID
Int No -
Regulatory Authority
nvarchar(50) No Unique identifier
Number
Title nvarchar(255) No
Objectives and
nvarchar(2000) Y
Description

Development Regulations Attachments

Attribute Type Optional? Notes
PK Development Regulations
Int No Primary Key
Attachment ID
Foreign Key to associate
FK Development Regulations ID Int No the attachments with the
Development
77
 Regulations table
Name of document nvarchar(200) No

Path nvarchar(200) No

Status nvarchar(20) Yes Draft or Final

Hyperlink nvarchar(200) Yes

Development Regulations Status

Attribute Type Optional? Notes
PK Development Regulations
Int No - Primary Key
Status ID
Additional content to be added:
- Preparing draft
- Internal Review
nvarchar
Development Regulations Status No - Draft approved
(50)
- External Review
- Approved
- Promulgated

Development Regulations History

Attribute Type Optional? Notes
PK Development Regulations
Int No - Primary Key
History ID
- Foreign Key to
FK Development Regulations associate records with
int No
ID the Development
Regulations table
Status Date Datetime No

- Foreign Key to
associate records with
FK Development Regulations
Int No the Development
Status ID
Regulations Status
table
Comments Nvarchar(2000) Yes

Development Regulations History Officer

Attribute Type Optional? Notes
PK Development Regulations
Int No - Primary Key
History Officer ID
FK Development Regulations int No - Foreign Key to

78
History ID associate the records
with the Development
Regulations History
table
Foreign Key to
FK Officer ID Int No associate records with
the Officers table
RAIS_TIME_STAMP Datetime No -

3.5.5 Review and Assessment Process

Review and Assessment
Attribute Type Optional? Notes
PK Review and Assessment ID Int No Primary Key
Regulatory Authority Number nvarchar(50) No - Unique Identifier
- Foreign Key to
associate records
FK Authorization ID Int No
with Authorization
Table
- Foreign Key to
associate records
FK Facility ID Int No
with the Facility
Table
- Foreign Key to
associate records
FK Department ID int Yes
with the
Department Table
Comments Nvarchar(2000) Yes - Actions taken

Review and Assessment History

Attribute Type Optional? Notes
PK Review and Assessment
Int No - Primary Key
History ID
Status Date Datetime No

- Foreign Key to
associate records
FK Review and Assessment Status
Int No with the Review
ID
and Assessment
Status table
- Foreign Key to
FK Review and Assessment ID Int No associate records
with the Review
79
 and Assessment
table

Comments Nvarchar(2000 Yes

RAIS_TIME_STAMP Datetime No

Review and Assessment History Officer

Attribute Type Optional? Notes
PK Review and Assessment
Int No - Primary Key
History Officer ID
Foreign Key to associate
FK Review and Assessment records with the Review
Int No
History ID and Assessment History
table
- Foreign Key to
associate records
FK Officer ID Int No
with the Officer
table
RAIS_TIME_STAMP Datetime No

Review and Assessment Status

Attribute Type Optional? Notes
PK Review and Assessment Status
Int No - Primary Key
ID
Additional content to be
added:
- Information
Request
- Information
Received
- Inspection Ongoing
- Completed
Review and Assessment Status Nvarchar(50) No - Preparing Report
- Report Approved
- Report Attached

Note: If “Report Attached”,

“Information Received” or
“Information Requested”
are selected, the R&A
(child) process should

80
 trigger the Authorization
(parent) process and
populate the Authorization
History table with the
current R&A status.
RAIS_TIME_STAMP Datetime No

81
4 Technical Requirements (Non-functional)
4.1 Architectural Strategies
The Contractor shall develop the System with technology that is current, stable and in
accordance with recognized best industry practices, technical and professional standards
and in-line with the technical requirements outlined in this document.
The System shall be designed in a way to minimize the dependency from the original
developer for maintenance and implementation of new features. In addition, the software
shall be compatible with the RAIS 3.X servers in Member States provided by the IAEA.

4.1.1 Technology Requirements

Given the management experience that Organizations and Member States have with
previous versions of the System, the System shall be built on a Microsoft based stack
including:Development technology requirements:

• NET framework

• ASP.NET MVC web application framework

The System shall be allowed to be hosted on MS Windows Server or Client with minimum
hardware requirements on an i5-i7 CPU with at least 4GB RAM:

• Minimum required server operating system: MS Windows 2008;

• Minimum required client operating system: MS Windows 7.

Database technology:

• MS SQL Server 2008 R2 (Express shall be supported) or later

o The installer shall include the option to install MS SQL Server express or to
integrate with existing MS SQL instances.

• The software shall store all data in a MS SQL database, with the exception of large
binary data, such as image data, which may be written as separate files within the
same container folder or in a SharePoint environment. The location of these
separate binary data files shall be referenced within the MS SQL database. The
schema used by the MS SQL database shall be documented, and included in the
final deliverables for this SRS.

Client side requirement:

• Firefox

• Chrome

82
 • IE 8.0 and above

4.1.2 Reuse of Software Components

The new System can use parts of previous RAIS versions (code, data schema, etc.).
Considering that this was the norm throughout the evolution of RAIS, a thorough analysis
is required for every aspect of the parts that are being reused to clean out all legacy code,
stored procedures, database schema, and elements or objects (fields, logic, etc.) that are
no longer in use. In case a certain code block is used and is not rewritten, a justification is
required about the code usability and design.

4.1.3 System Architecture

The System shall implement different models which shall be regarded as different views of
the System. None of the models shall exclude the other in the sense that a client-server
model of a system shall also be components based etc. The following shows a high level
view of the models that shall be implemented.
The System shall be built upon independent characteristics such as:

• Client-server model;

• Data Centric – a dynamic driven content generating application elements such as:
business objects, business rules, html elements and content;

• Component based – flexibility of the System to allow adding and removing

components. These components shall be built upon predefined interface which
applies to all System components. The components shall follow a unique
communication protocol;

• Plugin pattern - a software component that adds a specific feature to the System.

Figure 15

83
4.1.4 Client Server Based
The System is a web based Client Server application that allows various internet browsers
based clients to access and manipulate data over a network connection.

4.2 Components Based (Desirable)

The System shall follow a modular approach of loosely coupled encapsulated
components. Components shall have a significant impact on the entire System and shall
be essential in order for the entire System to function. Examples of integral components
that are required are: User Management, Functional Roles and Data Roles. Other
components shall provide optional functionalities like the RAN generation: which if are not
configured and enabled, the functionality is not available in the System.

Figure 16
Components shall:
• Communicate with each other via interfaces that specify the services that other
components can utilize or specify the services that it needs;
• Be substitutable, so that a component shall replace another (via configuration), if
the successor component meets the requirements of the initial component
(expressed via the interfaces). Consequently, components shall be replaced with

84
 either an updated version or an alternative without breaking the System in which the
component operates;
• Build on particular infrastructure provided by the framework. For example, the
means of configuration, data storage, business logic are customized, etc.
Furthermore, components shall:
• Be fully documented;
• Be thoroughly tested;
• Be robust - with comprehensive input-validity checking;
• Able to pass back appropriate error messages or return codes;
• Be designed with an awareness that it shall be put to unforeseen uses.
Examples of System components are:
RAN Generation: This component shall provide means of creating an automatically
generated identifier according to customizable generation and formatting rules.
User Management: This component shall be dependent on Data Roles and Functional Roles
in order to fully function.
Data Role Management: This component shall be dependent on the User Management and
shall provide a way to explicitly allow or restrict individual user’s access to certain data.
Function Role Management: This component is depending on the User Management and
shall allow managing access to certain areas and functionalities of the System.
Dashboard: (including Message Box): This component shall allow users to customize a view
of tasks, their latest edits, System messages, etc. This is expected to provide a
customizable “one glance” overview of the latest activities relevant to the user. The layout
of the dashboard, the content and the data presented in the dashboard shall be
customizable.

Web Services: This component shall provide means of exposing customizable logic as a
secure Web Service. It shall also provide means of consuming data exposed by other web
services, e.g. for importing data from other installations of the same System.

Reporting: This component shall allow for customizable queries to generate reports that can
be viewed in the browser, exported into Word, Excel or PDF where appropriate. It shall
support run time filtering of the results.
Workflow Management: This component shall allow workflows to be managed. A workflow
may define interfaces between business processes or require data entered by a user to be
validated by an authorized user (Message box).
Add-On Management: This component shall allow for add-ons to be installed or removed
from the System. It shall ensure the integrity of the System is not compromised by an add-
on.

4.2.1 Pipeline Components (Desirable)

Pipeline components implement a special interface that allows them to be executed every
85
time dynamic data is manipulated. Therefore data can be checked against certain criteria
and even stored in different places, e.g. in case of approval workflow.

Input Validation: This component shall provide means of checking data consistency (date,
numbers, min, max, regex, etc.) as described in the data definition.

Approval Workflow: This component shall check if the user providing the data has
permissions to write to the database or if the data needs to be approved by privileged user
before persisting the data.

Concurrency Management: This component shall check if the data submitted is not
overwriting changes previously persisted in the database. In such event, the component
shall take appropriate action and provide the violating user a choice of possible
mitigations.

4.2.2 Add-On Based (Desirable)

Building on the components based approach, the System shall provide ways to
accommodate add-ons that may depend on certain components and:
• The System shall enable third-party developers to create encapsulated abilities
which extend an application (e.g. NDR, RWMR);
• The System Add-On shall be uninstalled and therefore restoring the state before the
installation without affecting the System integrity.

4.3 Performance
The System shall have a responsive look and feel at all times. Long running operations or
requests shall avoid blocking the UI. In cases where requests may take some considerable
time (more than 5 seconds) to display the results, a user friendly loader message or
progress bar shall be presented to the user, preferably with an indication on how much
time the operation still needs to complete. The responsive look and feel shall be valid after
a long term System usage when there are a significant number of records inserted into the
database. The considerable time rule shall be enforced for 97% of the database queries
for at least 50 concurrent users.
The System customization possibilities shall not negatively affect the performance when
querying tables with a large number of records, as is the case with the current RAIS
version. Careful considerations are therefore required when developing the entity and
business process customization features, to guarantee acceptable query performance at
any time.
The Administrator of the System shall be notified on his/her dashboard about queries
running unexpectedly long (see “Monitoring”).

4.4 Scalability
The actual load of the System shall greatly depend on the needs of the implementing
country. Some countries use the System on a very small scale (few data records with only
a handful of users), while other countries use it with a very large number of records and
several tens or even hundreds of concurrent users. Therefore, the System shall be
86
designed with flexible scalability in mind, e.g. by supporting load balancing the application
over several servers.

4.5 Security
As the System is a web application used potentially both inside and outside a corporate
network with possible outside connections over the internet and also, taking into account
the nature of the content of the data, the security of the System is of critical importance.
The System shall be developed in such a way that it minimizes the risk of potential
intrusion or malicious script injection.The System shall be highly secured, equipped with
the latest and safest security measures to address Application Security Risks. The
Contractor shall create a Software Security Assurance (SSA) methodology and shall use it
to design the software.

HTTPS and SSL shall be the main communication protocols with respect to RAIS. If any,
Administrators shall be able to use already existing certificates from their institutions or
create new self-signed certificates that shall be later distributed to the System clients.

A certain automated “Denial of Service” defence mechanism shall be implemented by

rejecting a certain IP address that is trying to perform the attack.

The System shall be compliant with the latest TOP 10 security risks such as:

1. https://www.owasp.org/index.php/Top_10_2010-Main
2. https://www.owasp.org/index.php/Top_10_2013-Top_10

4.5.1 User Access

The current version of RAIS is secured by login and password, but this shall be extended
to more modern robust mechanisms. It shall also be possible to allow a user to log in via
multiple mechanisms:
• Active Directory (Windows Integrated Authentication). This mechanism shall be the
primary authentication mechanism when the System is used from within a Windows
Domain environment;
• Username and password with two-factor authentication. When Windows Integrated
Authentication is not possible, the user shall be allowed to log in using his
username and password credentials in combination with second-step verification
mechanism (hardware token, one-time-password, etc.);
• Classic username and password shall also be supported, but shall only be used
when it is not possible to use any of the previous two mechanisms.

In the user-management area, the administrator shall be able to specify the allowed log-in
mechanism for each individual user.

A specific time-locking mechanism shall be implemented and activated after a few un-
successful user login attempts.

87
4.5.2 Encryption

Additionally, every communication through the System architectural layers and all
technically sensitive information (for instance connection strings in web.config) shall be
encrypted using proven robust mechanisms.

Sensitive information stored into the database such as passwords and critical user
attributes shall be encrypted with strong encryption algorithms. In addition, storing System
sensitive information such as inventory of sources, dose register, etc. as plain text into the
database shall be avoided. Encryption shall be used System wide when using business
critical information.

4.6 Maintainability
4.6.1 Monitoring
The System shall provide a way of health monitoring to improve capabilities for remote
supporting in case of misconfiguration or actual exceptions. For example, System logs
organized by categories (Info, Error and Warning) accessible through the UI shall support
this approach.

The dashboard of the Administrator shall list any events that negatively affect the System
health, performance, or any other event that is considered to be important to bring to the
attention of the Administrator (e.g., data modification operation errors, long-running
queries, user has been locked out after performing too much unsuccessful login attempts,
DoS attempts, etc., see Section 3.2.7)

The System shall offer e-mail notification to the Administrator in case that the System
health and performance exceeds normal limits.

The System shall offer a functionality to export System health data to the IAEA for further
technical support.

4.7 Usability
4.7.1 UI requirements
The user interface for RAIS 4.0 shall provide a Modern UI using themes that allow users at
any time to recognize current area they are using (Administration, Customization, Data
Manipulation, Reporting, etc.). Modern UI shall emphasize typography over graphics. It is
a simple, elegant, and clean design trend that shall make use of tiles. Examples of this are
seen in Microsoft’s UI designs for phones and Windows 8 and 10.

The driving principles of the UI shall be:

Clarity: The interface avoids ambiguity by making things clear through language, flow,
hierarchy and metaphors for visual elements. They also ensure users make less mistakes

88
while using them.

Concision: It’s easy to make the interface clear by over clarifying and labelling everything.
If too many things are on the screen, finding what you’re looking for is difficult, and so the
interface becomes tedious to use.

Familiarity: The interface shall reflect the familiar structure of the previous versions of
RAIS. This includes tabs, menu items, and general order of dynamic elements. However,
the interface shall provide a modern “flat” and colourful look and shall improve unwieldy
ways of achieving customization in previous versions of RAIS.

Responsiveness: Firstly, responsiveness relates to speed: the interface shall not feel
slow after update operations. Secondly, the interface shall provide good feedback to the
user on what’s happening and whether the user’s input is being successfully processed.

Consistency: The interface shall allow users to recognize usage patterns, so they can
apply knowledge to new areas and features, provided that the user interface is consistent
with what they already know.

The System shall provide a modern JavaScript driven UI, e.g. based on AngularJS, Ext.JS,
to a lesser extend backbone JS or similar libraries. Previous versions of RAIS are heavily
post back dependent. Since data is not very volatile, the System shall not be considered a
Single-Page-Application (SPA) but include typical SPA look and feel on a low-end
interactivity level. The use of Server Side Events or WebSockets is not required but shall
be useful for proving asynchronous feedback to the user, e.g. in the form of concurrency
warnings. Typical characteristic of the UI shall be the following:

• Document present mostly static piece of information already processed, and add a
bit of interactivity via JavaScript;
• Data input validation, input helpers (like date pickers), population of dropdown lists,
dependencies between fields, user feedback and sorting and paging of lists, and
alike shall look and feel like SPA operations and shall trigger server side actions in
the background;
• Major Model-Granular Submit operations shall cause a full page refresh;
• State and data shall be stored in HTML considering that if data is altered, the page
is refreshed;
• Complex interactions shall be resolved on the server.

4.7.2 Mobile Device Compatibility (Desirable)

While the primary use of the System shall be through classic means of desktop computers
or laptops, usability on mobile devices shall also be taken into account. The UI elements
and navigation shall adjust accordingly depending on the screen resolution (a.k.a.
Responsive Web Design). Usage of proven frameworks like Bootstrap can greatly
contribute to this.

89
4.8 Concurrency
The System shall be able to identify and handle concurrent access to the same data
record for at minimum 50 concurrent users. In order to avoid unintentional overwriting of
another concurrent user’s changes, an optimistic concurrency control mechanism shall be
in place. The System shall present adequate notifications to the users when concurrently
accessing and working a record.

4.9 Multi-Lingual Requirement

As with previous versions of RAIS, the System and all installation and user manuals etc.
shall be available in allofficial UN languages by default (English, French, Arabic, Chinese,
Russian and Spanish). In addition, the System shall provide a user friendly way of adding
a new language, if desired. Refer to “Language customization” feature as described in
RAIS 3.3.

4.10 Auditing and Logging

User activity inside the System shall be logged into the database, and the Administrator
shall be able to consult the user activity. At minimum, the following operations shall be
logged (with username and timestamp):
- Login/logout
- Any sort of customization
Additionally, the Administrator shall be able to enable auditing for any entity for access,
creation, update and deletion. For example, audit access or managing entity data related
to individuals’ medical information.
The Administrator shall be able to search by auditing and logging activity, where the
search feature is applied.
The Administrator shall be able to create reports (PDF) per user within a pre-defined
period of time where the “reports” feature is applied.

90
5 Requirements and Deliverables
5.1 Phased Implementation Plan
RAIS 4.0 shall be implemented following a Three Phase approach. During the Phase
One, the Contractor shall translate the proposed conceptual design into an executive
design. The latter shall include the definition of architectures, design of the application, the
definition of testing procedures, design of scaling procedures and an agile work plan.
Once all project details of the design are well defined and approved, the Contractor shall
proceed to Phase Two; during Phase Two, the Contractor shall write the code and develop
the requested documentation. The IAEA shall evaluate the deliverables of Phase Two for
compliance with the executive design and using the test procedure agreed to in Phase
One. After successful completion of Phases One and Two, the Contractor shall initiate
Phase Three. Phase Three is the six months warranty period that shall include System
maintenance such as fixing bugs and completing non-compliance System features
discovered after the System acceptance.
The deliverables for all Phases shall include detailed documentation and the source code
of the product. This shall give the IAEA the visibility on the quality of the products in terms
of readability and programming style and ensure high quality throughout the duration of the
project.

5.1.1 System Assessment and Acceptance Procedures

The assessment and acceptance procedures shall be different for Phase One and Phase
Two, whereas Phase Three does not require such procedures. The deliverables for Phase
One shall be based on compliance with the specifications and the design guidelines as
described in this SRS and its supporting documentation. Additionally, the design shall also
be in line with the conceptual design. Particular attention shall focus on the testing and
scaling procedures for the next Phase as outlined. This shall include a variety of tests to
ensure performances, stability and security.

For the assessment acceptance of the deliverables of Phase Two, two main criteria shall
be used:
1) Compliance with the design outlined in Phase One;
2) Successful execution of the test procedures.

5.1.2 Project Phases

Phase One: Functional and limitation analysis of RAIS 3.X Series; RAIS 4.0 software
design and work-plan definition.
Phase Objectives:
a) Analyse the existing RAIS 3.X series to outline the functional blocks and the
existing features;
b) Acquire all the necessary information for the design of RAIS 4.0;

91
 c) Develop an optimized design for RAIS 4.0;
d) Produce documentation for the design and testing of all System features and
software components;
e) Define the work plan for Phase Two and Three.
Within three to four months following the entry into force of the Contract, the Contractor
shall deliver the items as stated in:
a) Documents containing extended analysis of the functional blocks and features in
RAIS 3.X Series;
b) Documents containing extended analysis of RAIS 3.X limitations;
c) Paragraph 5.2.1.2 – Documents containing a detailed software project management
and software development plan with meeting schedule;
d) Chapter 4 – Documents elaborating the technology to be used, practises to be used
such as modular: approach, coding conventions and database design approach;
e) Paragraph 5.2.3.1 - Documents containing detailed work plan with dates of
deliverables and milestones for Phase Two;
f) Paragraph 5.2.4.1 - Documents containing detailed performance testing procedure
to be applied in the acceptance of Phase Two;
g) Paragraph 5.2.4.2 - Documents containing detailed scaling procedure to be applied
in the acceptance of Phase Two;

h) Paragraph 5.2.5.2 – SDD document for RAIS 4.0 as described in 5.2.5.2 including:
a. Detailed explanation all the features of RAIS 4.0 to be build;
b. Design considerations;
c. Architectural design;
d. Data design (including Database design diagram and schema diagram);
e. User Interface design;
f. Data Migration Procedures (from RAIS 3.X Series to RAIS 4.0) with
examples;
g. Implementation of test and scaling procedures.

Phase Two: Development of RAIS 4.0

Phase Objectives:
a) Develop all features required for RAIS 4.0;
b) Develop user manuals for RAIS 4.0;
c) Develop the reference documentation to allow third parties develop new code
modules in RAIS 4.0.
Within nine to twelve months of acceptance by the IAEA of the deliverables specified in
92
Phase One, the Contractor shall complete the delivery of the System in accordance with
all items as stated in the respective requirements as per the SRS including Section 5.2
and its subsections

Phase Three: Warranty phase for System maintenance

Phase Objectives:
Provide support in fixing discovered bugs and non-compliant System features.
Within six months of acceptance by the IAEA of the deliverables specified in Phase Two,
the Contractor shall comply with items as stated in:

a) Section 5.2 - Requirements for RAIS 4.0 Development:

i. Paragraph 5.2.10.

5.2 Additional Requirements for RAIS 4.0 Development; Meetings,

Reviews, Testing and Data Deliverables

5.2.1 Meetings

1. The Contractor shall participate in at minimum 3 one-week meetings in Phase One

of the project to discuss the details of the System features, Use-Cases and other
System details from the RAIS 4.0 SRS. At least one of the meetings will be held at
IAEA’s headquarters in Vienna, Austria. The rest may be conducted virtually
through an on-line meeting tool such as WebEx.

2. The Contractor shall develop an agile work plan and apply development framework
(such as SCRUM). The work plan shall be in addition to the conceptual design
document. The Contractor shall organize regular sprint meetings during the
planning, review or retrospective phases. The designated IAEA Technical Officer
(TO) shall attend these meetings and shall be updated with the latest project status.
The meetings will be held at Contractor’s premises with IAEA TOs present on site or
virtually through an on-line meeting tool such as WebEx.

3. The Contractor shall participate in a final 5-days meeting for the presentation of the
final software product to the IAEA-NSRW management, at the IAEA’s headquarters
in Vienna, Austria.

4. Presentation to IAEA-NSRW management of the final software product. The

software shall be validated using the Use Cases laid out in RAIS 4.0 SRS and other
real-life scenarios as provided by IAEA Regulatory Experts.

93
5.2.2 Point of Contact
1. The Contractor shall provide a single point of contact (POC), responsible for the
overall technical developments and for any communication with the IAEA on matters
related to the Software Development Project. Change to the single POC shall
require the written approval from the IAEA throughout the course of the Project.

2. The Contractor’s POC shall possess and be able to demonstrate strong facilitation
and communication skills and fluency in English (oral and written).

5.2.3 Work review

1. The Contractor shall develop a detailed work plan with clear deliverables/milestones
which shall be maintained up-to-date throughout the duration of the project
providing details as addressed in each sprint.

2. The Contractor shall develop beta versions of the software incorporating requested
modifications from IAEA-NSRW; an operational version of the software shall be
continuously available throughout the entire sprints of the work.

3. The Contractor shall provide deliverables via a secure cloud sharing mechanism
(such as secured FTP), and set up a robust online ticketing system (such as TFS).
The Contractor shall assign full privileges to the designated IAEA TO to view and
manage sprint backlogs, tasks, bugs, sprint burnout charts, code review, etc. in
order to track the progress during the development. The selection of the cloud
services shall be approved by the IAEA to ensure accessibility within the IAEA
network.

4. Develop and maintain a file or database system containing all data from the
ticketing system with the tasks, bugs, backlog information, etc., and names of the
developers and engineers.

5. The RAIS 4.0 System, prior to acceptance by the IAEA (end of Phase two), shall be
subject to IT Security and code quality evaluation. The initial design will need to go
through an Microsoft Threat Modelling exercise done by the IAEA where high risks
identified need to be resolved by the Contractor. The evaluation shall furthermore
be conducted by using application security and code quality tools such as Acunetix
and HP Fortify provided by the IAEA. The Contractor will need to ensure that Critical
and High risk issues are resolved. Finally, the final implementation will include a
penetration test done by the IAEA where any High and Medium risk issues identified
need to be resolved by the Contractor. The Contractor shall make all the necessary
modifications to satisfy the IAEA software application standards.

94
5.2.4 Testing and Scaling
1. The Contractor shall provide a documented performance testing procedure to
show how the System performs with regards to responsiveness and stability under
a particular workload such as data processing of a few hundred thousand records
per entity of the main processes. The workload shall be defined by the IAEA TO.

2. The Contractor shall provide a documented vertical and horizontal scaling

procedure to show how the System handles growing amount of work (such as
increasing the number of data and concurrent users).

5.2.5 Data and other Deliverables

The Contractor shall provide the following:
Documentation
1. All documentation shall be provided in the English language (design information,
installation, configuration, assistance, training, test code). All use of third-party
items shall be explicitly described and communicated to the IAEA. All
documentation shall adhere to the highest IT industry standards, i.e. following the
standards as recommended by IEEE.

2. Software Design Documentation for RAIS 4.0 which details the provisions, including
specific coding instructions, unit test cases, for developing each unit or module of
the System. It shall include development procedures for issue tracking and
configuration management and any other information that aids in building the
functionality of the System:
i. Preparations related to the development of each software unit and other
items that shall assist in explaining the functionality of the software shall be
documented;
ii. Description of the development methodologies;
iii. RAIS 4.0 Code documentation.

Implementation Plan and System Updates Implementation Plan – describes how

the System shall be deployed as a commercial System

3. Release Notes –summary information concerning the (most) current release of the
system being built. Typically includes major new features and changes and
identifies known problems and workarounds.

4. RAIS 4.0 User manuals in all UN languages

i. Regulatory Model
ii. Users Guide
iii. Administrators Guide
iv. Installation Manuals
v. Troubleshooting Guide

95
Software

5. RAIS 4.0 Source Code – a set of files containing the complete software code that
shall have the ability to be opened in a particular development environment such as
Visual Studio and shall allow source code compilation to reproduce a fully working
application in a debug mode.

6. RAIS 4.0 – System (Application) Software – file or set of files containing the
application or software code on discs or other media. It shall represent a highly
customizable web-based software System based on the SRS documents and is
compatible with RAIS computer hardware donated by IAEA to Member State users.
The System interface shall be available in all UN Languages.

7. RAIS 4.0 One-Click-Installer that shall install a fresh copy of RAIS 4.0 or modify
existing version on a server. The installer shall install and configure all necessary
prerequisites such as Internet Information Services (IIS), MS SQL Server, etc. It
shall extract all the necessary RAIS 4.0 files to a desired location and create the
necessary databases with the System data and start a fully functional working
System.

8. RAIS 4.0 Migrator Tool that shall migrate data from previous RAIS versions (3.2 and
3.3). The migration tool shall be documented containing examples on how to
perform the migration with a rollback possibility. The migration tool shall be in the
English language.

9. Test Data –dummy data used for testing that is not sensitive or live.
i. Provide sample representative data to use in test activities;
ii. Ensure that testing results simulate production results.

10. The IAEA shall be entitled to all intellectual property and other proprietary rights
including, the source code and materials which the Contractor has developed for
the IAEA under the Contract and which bear a direct relation to or are produced or
prepared or collected in consequence of, or during the course of, the performance
of the Contract.

96
6 Appendix
6.1 System Features Figures
The following figures point out the vision or show a direction for the new RAIS User
Interface. The purpose is to explain the desired clean and intuitive UI that the new RAIS
4.0 shall have.

6.1.1 Dashboard

Figure 17

97
6.1.2 Reports

Figure 18

6.2 UI Requirements Figures

Figure 19

98
Figure 20

Figure 21

99
Figure 22

Figure 23

100
 Figure 24

6.3 UI Customizations Figures

Figure 25

Figure 26
101
 RAIS 4.0
Software Requirements Specifications
Processes Supporting Document

Prepared By
IAEA
SRS - Processes Supporting Document for RAIS 4.0

Contents
1 Regulatory Processes: ................................................................................................ 3
1.1 1.1 Authorization Process........................................................................................ 4
1.1.1 Licensees and Registrants (Authorization Holders) ........................................ 4
1.1.2 Scope of Authorization .................................................................................... 4
1.1.3 Authorization Types ........................................................................................ 4
1.1.4 Authorization Information ................................................................................ 5
1.1.5 Specific Information for Import/Export Authorization ....................................... 5
1.1.6 Specific Information for Transfer Authorization ............................................... 6
1.1.7 pecific Information for Transport Authorization ................................................ 6
1.2 Review and Assessment Process ........................................................................... 6
1.3 Inspection Process .................................................................................................. 7
1.4 Enforcement ............................................................................................................ 8
1.5 The Emergency Preparedness Process (Radiation Events) ................................... 9
1.6 Development of Regulations and Technical Guidelines Processes ......................... 9
2 Management Processes ............................................................................................ 10
2.1 Development of Policies Processes ...................................................................... 10
2.2 Processes Related to Monitoring and Measurement............................................. 10
2.3 Self-Assessment ................................................................................................... 10
2.4 Independent Assessment: ..................................................................................... 11
2.5 Control of Records Processes............................................................................... 11
3 Support Processes .................................................................................................... 12
3.1 Use of External Support ........................................................................................ 12
4 Technical Services .................................................................................................... 13
5 General Improvements .............................................................................................. 13
5.1 Improving the Description of Regulatory Functions: .............................................. 13
5.2 Management & Support Processes....................................................................... 14
5.3 Technical Services: ............................................................................................... 14
5.4 Other Issues: ......................................................................................................... 14
6 References ................................................................................................................ 15
7 Regulatory Processes Workflow Diagrams ............................................................... 15
7.1.1 Authorization Process ................................................................................... 16
7.1.2 Inspection Process ....................................................................................... 17
7.1.3 Enforcement Process ................................................................................... 18
7.1.4 Radiation Events........................................................................................... 19
7.1.5 Review and Assessment ............................................................................... 20

2
SRS - Processes Supporting Document for RAIS 4.0

1 Regulatory Processes:

Introduction
For the regulatory body to meet its responsibilities there are several core functions that a
regulatory body shall fulfil. The core functions of the regulatory body are:

• Authorization and notification;

• Review and assessment of facilities and activities;
• Inspection of facilities and activities;
• Enforcement of regulatory requirements;
• Development of regulations and guides;
• Emergency Preparedness and Response;
• Communication and consultation with interested parties.

In fulfilling the core functions there are also several supporting functions that shall be
available within the regulatory body. These supporting functions are necessary enablers in
fulfilling the core functions, and a regulatory body cannot operate satisfactorily without
most of them (See Section 6, Reference 4). The supporting functions are:

• Administrative functions;
• Legal support;
• Research and development;
• Advisory committees;
• External expert support;
• Liaison with other governmental organizations;
• International cooperation.

In addition, management functions are necessary to enable the regulatory body to sustain
an efficient and effective organization with sufficient competent staff.
All these functions should be organized in their associated processes and shall be
represented in the regulatory body’s integrated management system (See Section 6,
Reference 4).

RAIS 4.0 shall include by default all core processes of the regulatory body that it
implements its regulatory functions effectively and in line with the IAEA safety standards. It
shall also assist the regulatory body to document and trace each step taken in each
process.

RAIS 4.0 shall be customisable to add a supporting process if the regulatory body decide
to do so.

In the following sections detailed description on the core processes and how RAIS 4.0
shall be designed to fulfil the steps of each process. Diagrams are given as Annexes to
this document describing the steps of each core process and the inputs, outputs, human
and non-human resources needed and the rules of each step.

3
SRS - Processes Supporting Document for RAIS 4.0

1.1 Authorization Process

The system of authorization differs considerably from one country to another. RAIS 4.0
shall be designed to cover effectively the wide variation in authorization systems.

Authorization is considered to be a process starting with an application. By default, RAIS

4.0 shall use the following steps:

• Application;
• Review for documentation completeness;
• Assessment;
• Approval or rejection;
• Issuance of authorization certificate;
• Subsequent action: e.g. the authorization can later be modified, amended,
suspended or withdrawn.

These steps shall be customized in accordance with the national authorization system.
The authorization process defines the history of the authorization. Each step is a status,
defined by date, responsible officer and separate status number, if applicable. The process
itself is identified by a RAN, the authorization process number, which remains unchanged
throughout the process.

1.1.1 Licensees and Registrants (Authorization Holders)

In some countries, the facility itself is to be authorized for all practices in which the facility
is active regardless of its internal organization. In other countries, the departments within
the facility have the legal status to be authorized separately.

RAIS shall be able to manage both situations. Facility identification for the authorization
shall be mandatory, but additional department identification shall also be possible.

1.1.2 Scope of Authorization

Depending on the regulatory system in the country, authorizations may cover all sources in
the facility or particular sources. Authorizations may also be issued without the
specification of a source, but just for the Radiation practice itself or for maximum permitted
radioactivity in a specific period of time.

1.1.3 Authorization Types

RAIS 4.0 shall include by default a set of authorization types which shall be common for
the majority of facilities and activities. For each authorization type, a predefined set of
information shall be included. This set shall be customized in the installation phase. Also,
RAIS 4.0 shall offer the possibility of introducing new types of authorization if necessary.
The following authorization types shall be predefined in RAIS 4.0:
1. Import authorization;
2. Export authorization;
4
SRS - Processes Supporting Document for RAIS 4.0

3. Transfer authorization;
4. Authorization to use/operate;
5. Storage authorization;
6. Authorization to release radioactive substances into the environment;
7. Transport authorization;
8. Authorization to produce radioisotopes;
9. Authorization to manufacture devices, e.g. radiation generators or associated
equipment.

Multi-stage authorizations shall not be provided by default, but RAIS shall have the
flexibility to allow countries to introduce these types, if necessary.

1.1.4 Authorization Information

All authorization types share a base set of information such as the authorization holder
(licensee or registrant), date, expiry date. This base information shall be defined by default
in RAIS 4.0 and includes:
• Authorization holder, e.g. facility or department;
• Sources authorized;
• Persons involved, e.g. responsible person, radiation protection officer, workers;
• Full record of the authorization process;
• Officers responsible for each step of the authorization process.

In addition to the base information, RAIS 4.0 shall include other information for specific
types of authorizations as described in Section 1.1.5.

1.1.5 Specific Information for Import/Export Authorization

For example, several scenarios are possible for importing radiation sources:
• All sources covered in the import authorization are imported in a single action;
• Multiple import actions are carried out under one single import authorization. In each
import action, only a part of the authorized sources is imported;
• The authorized facility does not import the authorized sources, fully or partially.
• There might be a significant time difference between issuing the import authorization
and the import actions;
• Sources can be imported by the user facilities themselves or through a third party,
e.g. dealers.

Similar possibilities apply to export authorization.

RAIS 4.0 shall offer the possibility of entering data on several import actions for a single
import authorization, and the possibility of identifying the actually imported subset among

5
SRS - Processes Supporting Document for RAIS 4.0

the sources authorized for import. For each import action, the relevant data set shall
include the date, the bill of lading number and the customs clearance number.

Additionally, for import of sealed radioactive sources of particular security groups, a

security plan for the import/export period may be requested, depending on the applicable
regulatory system.

1.1.6 Specific Information for Transfer Authorization

In addition to the base information, a transfer authorization shall specify, information about
the recipient facility and the type of transfer and namely:
• Recipient facility or department;
• Recipient authorization to receive the source;
• Date of transfer;
• Type of transfer, i.e. permanent or temporary. In the latter case, information shall be
submitted about the return of the source to the origin.

1.1.7 Specific Information for Transport Authorization

In some cases, a specific authorization shall be required for the transport of radioactive
material. In RAIS 4.0, the transport authorization shall include the following information:
• Package type;
• Package category;
• Transport index (TI);
• Transport mode(s), including multimode transport;
• Consignor;
• Consignee;
• Carrier;
• Consignee authorization, which allows to receive the source;
• Place of origin;
• Destination;
• Date of shipment;
• Date of receipt;
• Exclusive use (y/n);
• Special arrangement (y/n);
• Existence of a security plan for transport of sealed sources having specific security
classes.

1.2 Review and Assessment Process

6
SRS - Processes Supporting Document for RAIS 4.0

The purpose of this process is to review and assess information related to safety, technical
and other information in order to (See Section 6, Reference 5):

• As part of the authorization process, verify the adequacy of the proposed safety
measures;
• Determine whether the facility or activity complies with the regulatory requirements
and the authorization.

This review and assessment of information shall be performed prior to authorization and
again over the lifetime of the facility or the duration of the activity, as specified in the
regulations promulgated by the regulatory body or in the authorization. Review and
assessment shall be undertaken in order to enable the regulatory body to make a decision
or series of decisions on the acceptability of the facility or activity in terms of safety. (See
Section 6, Reference 4)

For significant risk sources, unusual or complex facilities or activities, the regulatory body
also verify the contents of the documents submitted by means of site inspection where the
radiation sources shall be installed or used.

By default, RAIS 4.0 shall enable the regulatory body to apply review and assessment for
the authorization applications. The process of review and assessment shall include the
following steps:

• Extract relevant information from all inputs;

• Establish a review and assessment plan (identify key issues/tasks, milestones,
assigned resources – internal/external);
• Conduct review and assessment activities;
• Collect and integrate assessment results, and request additional information if
needed;
• Document the conduct of review and assessment and results;
• Propose authorization conditions;
• Provide feedback into the authorization process.

The expected output of the review and assessment process shall be reports and
documents covering review and assessment results and proposed conditions for
authorization. (See Section 6, Reference 4)

1.3 Inspection Process

Similarly to the authorization process, inspection shall be considered in RAIS 4.0 to be a

process consisting of:
• Carrying out inspection;
• Report preparation;
• Report verification;
• Report approval;

7
SRS - Processes Supporting Document for RAIS 4.0

• Sending the report to the inspected facility.

These steps shall be part of the history of the inspection. In every step, the responsible
officers can be identified. In this way, information about joint inspections carried out by
officers from different authorities shall be managed by RAIS 4.0.

RAIS 4.0 shall be able to identify whether the entire facility is inspected or only one of its
departments. It shall also be possible to identify the inspected sources among the existing
set in the inspected facility or department.

RAIS 4.0 shall provide the inspection type through three attributes: regular vs. non-regular,
announced vs. non-announced and comprehensive vs. partial.

The frequency of regular inspection is practice specific. The default values are given in
Table 1. The regulatory authority shall define its own inspection frequencies in the Setup
phase. RAIS 4.0 shall use this information to assist the regulatory authority in building its
inspection programme for any period.

1.4 Enforcement

In case of non-compliance, the regulatory authority may decide to apply some

enforcement actions according to its enforcement policy. RAIS 4.0 shall include a
predefined set of non-compliances categorized according to the severity (See Section 6,
Reference 6). It is up to the regulatory authority to modify the list according to its own
system (see Table 4). This list shall be adjusted by the regulatory authority during the
installation phase.

The information on enforcement actions includes, as applicable:

• Set of non-compliances leading to enforcement action;
• Inspection on the basis of which the enforcement action was decided;
• Officer(s) responsible for enforcement action;
• Due date;
• Response of facility/department;
• Follow-up inspection;
• Close of the enforcement action.

8
SRS - Processes Supporting Document for RAIS 4.0

1.5 The Emergency Preparedness Process (Radiation Events)

The regulatory authority may be involved, to varying degrees, in the preparedness and
response to radiation events depending on the national system. RAIS 4.0 shall include
data on radiation events, useful from the regulatory authority’s point of view:
• Date and location of the event. The location shall be specified as an address or
geographical coordinates (e.g. for events occurring in remote areas);
• Extent of the event and the emergency response level. RAIS 4.0 shall provide
default lists for classification of the emergency response levels and event extents;
• The facility involved, if any;
• The sources involved;
• Causes and radiation consequences of the event. RAIS 4.0 shall provide default
lists of possible causes and possible consequences;
• Remedial actions taken and lessons learnt;
• The persons exposed to radiation due to an event. Persons can be members of the
public, workers and, if the event is related to medical exposure, patients. Exposed
workers shall be identified individually. For patients and members of the public,
RAIS 4.0 shall provide their identification either as individuals or as group of people;
• The doses received by the exposed individuals or groups and the health
consequences thereof. RAIS 4.0 shall provide a default list of possible health
consequences;
• IAEA notification and assistance provided;
• The reporting chain about the event, including data on the reporting organizations
or facilities and to whom the report was sent to;
• IAEA notification of the event and the support received from IAEA, if applicable.

1.6 Development of Regulations and Technical Guidelines Processes

Development of regulations and technical guides is the responsibility of the regulatory

body. By default, RAIS 4.0 shall provide the process of developing the regulations and the
technical guides to include:

• Developing of the draft regulation (or review of the regulations);

• Review of the draft internally;
• Approval of the draft;
• Sending the draft for comments;
• Incorporating the comments in the draft;
• Finalising the draft;
• Approval of the regulations.

The technical guidelines shall follow the same flow of processes.

9
SRS - Processes Supporting Document for RAIS 4.0

In case of reviewing existing regulations or technical guides, the first step shall be the
proposals for changes, and then the flow shall continue as above.

2 Management Processes
2.1 Development of Policies Processes

The regulatory body need to develop and disseminate within the organization a set of
policy documents that guide the discharge of the regulatory mandate and the achievement
of a mission. The policies may be available to all stakeholders taking into consideration the
needs of confidentiality and security. Some policies shall guide the internal workings of the
regulatory body; others may impact the regulated facilities and activities

RAIS 4.0 shall assist the regulatory body in managing the development of polices process
to include:

• Review and analysis of relevant information/requirements and lessons learned;

• Draft of policy based on evidence and involvement of relevant experts;
• Consultation with internal and external stakeholders;
• Draft of the implementation plans of the proposed policy;
• Impact/cost-benefit assessment of proposals;
• Refinement of proposals into new policies;
• Approval of the policy by senior management, including the implementation plans.

2.2 Processes Related to Monitoring and Measurement

The effectiveness of the regulatory body management system needs to be monitored and
measured to confirm the ability of the processes to achieve the intended effective
regulatory system and to identify opportunities for improvements. The monitoring and
measurement shall be done through self-assessment and independent assessment.

2.3 Self-Assessment

This is an internal process and management tool intended to review the regulatory body
current status, processes and performances against IAEA safety standards, and provide
further development and improvement of the existing regulatory system. Self-assessment
is a learning and enquiring process, and an integral part of the establishment and
development of a regulatory body to become an effective organization. IAEA has
developed a Self-Assessment Tool called Self-Assessment of Regulatory Infrastructure for
Safety (SARIS). SARIS is a software which contains different questionnaires based on
IAEA Safety Standards, which shall be periodically used for assessment of the national
regulatory infrastructure for safety. SARIS is used for the preparation for review missions
such as the Integrated Regulatory Review Service (IRRS). Self-assessment process
includes the following steps:

• Identifying the modules to be answered and appointing the questions responders

and the analysts;

10
SRS - Processes Supporting Document for RAIS 4.0

• Answering the questions of the identified modules;

• Analysis of the answers;
• Developing of action plan to address gaps identified;
• Follow-up the implementation of the action plan.

2.4 Independent Assessment

As part of monitoring and assessment, the regulatory body need to conduct independent
assessment on a regular basis to evaluate the effectiveness of processes in meeting and
fulfilling its goals, strategies, plans and objectives. The independent assessment is also
needed to determine the adequacy of the work performance and leadership and identify
opportunities for improvement. In order to provide international independent assessment,
IAEA developed the “Regulatory Review Services” (IRRS). IRRS provides a peer
evaluation of the regulatory infrastructure in relation to the relevant IAEA safety standards.

RAIS 4.0 shall include the possible steps to be taken to conduct IRRS mission and to
develop action plan for improvement. These steps shall include:

• Identify the modules;

• Answer SARIS questions (it shall be connected to self-assessment part);
• Complete the Advance Reference Material (ARM);
• Review IRRS mission report;
• Amend the action plan;
• Implement the action plan;
• Review the implementation of the action plan (go for self-assessment).

2.5 Control of Records Processes

The regulatory body need to keep extensive records of their work and their interactions
with authorised and interested parties. Effective record numbering, storage and
management systems shall ensure that relevant records are identifiable and readily
retrievable and need to be adopted by the regulatory body. RAIS 4.0 shall offer the
possibility of managing the records and the information of the regulatory body to include:

• Audit reports;
• Staff surveys
• Staff records (dose records etc.);
• Safety cases;
• Assessment reports;
• Inspection reports;
• Authorisation certificates;
• Management reports;
• Communication and consultation with interested parties.

The regulatory body is required to establish a regulatory system for protection and safety

11
SRS - Processes Supporting Document for RAIS 4.0

that includes provision of information to, and consultation with, parties affected by its
decisions and, as appropriate, the public and other interested parties, commensurate with
applicable legislation. RAIS 4.0 shall offer management of information related to the
consultation and communications with interested parties to include:

• List of different interested parties (stake holders, public, governmental authorities,

non-governmental originations, trade unions, professional and academic
organisations, news, media, neighbouring countries, etc.);
• Sets of communications policies with information to be provided to stakeholders;
• Ways to contact different interested parties;
• Regulatory decisions in consultation with interested parties;
• Feedback records from the interested parties.

3 Support Processes
3.1 Use of External Support

Provided that regulatory bodies aren’t entirely self-sufficient, they may need advice or
assistance, from external experts or other technical organisation in all technical or
functional areas necessary to discharge its responsibilities for review and assessment or
inspection. The regulatory body should have full information about support organizations
or experts that can be used for advice or assistance. RAIS 4.0 shall offer the possibility to
manage all information related to the available support organisations or experts that can
be used by the regulatory body. This information shall include:

• List of possible organizations for advice or assistance;

• List of available experts and their qualifications who shall be used by the regulatory
body for advice or assistance;
• Human resources available and their competence;
• Technical tools and equipment of the organisation;
• Research activities carried by the organizations.

RAIS 4.0 shall also offer the possibility of managing the use of external support services
process by the regulatory body. This process shall include the following steps:

• Identification of the area (in review and assessment or in inspections) that requires
external support;
• Search on the availability of organisations or experts (within RAIS) that can carry
the job;
• Preparation of the Terms of Reference for the task conducted by the expert or the
organisation;
• Approval of the Terms of Reference including the time frame for submitting the
report to the regulatory body;
• Contract arrangements with the organization or the experts;

12
SRS - Processes Supporting Document for RAIS 4.0

• Follow-up by the regulatory body with the expert or the organisation;

• Receipt of the report from the expert or the organisation
• Review of the report by the regulatory body;
• Approval of the report by the regulatory body;
• Implement the report by the regulatory body.

4 Technical Services

RAIS 4.0 shall also offer the possibility of managing information on technical service
providers. These are facilities which are active in the radiation practice service provider.
Service providers shall be authorized to use radiation sources and be subject to an
inspection just as any other facility. However, these have a special type of authorization or
accreditation.

By default, information about accreditation only includes the certificate number,

accreditation date, and the expiry date as applicable. Other information shall be added
during the installation phase.

5 General Improvements

General improvements expected by the new RAIS 4.0 shall include the following:

5.1 Improving the Description of Regulatory Functions:

• Authorization: describe authorization types through a field type rather than a menu
item;
• Scope of authorization: practices covered (select from the list of facility practices)
• Multiple selections of departments in authorization, inspection, etc.;
• Full implementation of Guidance on Import and Export of Radioactive Sources
(GIERS);
• Inspection process: preparation phase;
• Inspection planning menu shall include calendar, system for inspectors to be invited
for inspections by email (including uploaded documents of last inspections);
• For all regulatory processes:
o Interfaces;
o Responsibilities for each stage;
o Process resources, drivers and constraints;
o Process monitoring;
o Process documentation;
o Conditionally display fields as place holders for additional information of each
stage;
o Shared sub processes (e.g. filing, technical support, legal support, etc.)

13
SRS - Processes Supporting Document for RAIS 4.0

5.2 Management & Support Processes

• List management processes and support processes;

• Interface with regulatory processes
• Should be flexible and should have process description;
• Functionalities: forward to next step, return to previous step, reminder, monitor
process performance, definition of open and closed processes;
• Paperless process management of processes;

5.3 Technical Services:

• Training courses: accreditation institutes (e.g. under organizations & authorities).

5.4 Other Issues:

• Complete review of internal tables (nuclides, half time, exemption levels, etc.) and
adding interfaces thereof;
• Complete review of the catalogues (manufacturers, models, etc.);
• Extension: Management.

14
SRS - Processes Supporting Document for RAIS 4.0

6 References

1. INTERNATIONAL ATOMIC ENERGY AGENCY, Safety Requirements on Governmental, Legal and

Regulatory Framework for Safety, GSR Part 1 (2010)
2. INTERNATIONAL ATOMIC ENERGY AGENCY, Radiation Protection and Safety of Radiation Sources:
International Basic Safety Standards, GSR Part 3 (2012)
3. INTERNATIONAL ATOMIC ENERGY AGENCY, The Management System for Facilities and Activities,
Safety Standards Series No. GS-R-3, Vienna (2006)
4. INTERNATIONAL ATOMIC ENERGY AGENCY, Organization, Management and Staffing of a Regulatory
Body, DS472
5. INTERNATIONAL ATOMIC ENERGY AGENCY, Regulatory Body Functions and Processes, DS473

7 Regulatory Processes Workflow Diagrams

15
SRS - Processes Supporting Document for RAIS 4.0

7.1.1 Authorization Process

16
SRS - Processes Supporting Document for RAIS 4.0

7.1.2 Inspection Process

17
SRS - Processes Supporting Document for RAIS 4.0

7.1.3 Enforcement Process

18
SRS - Processes Supporting Document for RAIS 4.0

7.1.4 Radiation Events

19
SRS - Processes Supporting Document for RAIS 4.0

7.1.5 Review and Assessment

20