ISMP Att A SOW Att B and Att C.DOC

ATTACHMENT A:

STATEMENT OF WORK

Table of Contents

10 INTRODUCTION

10.1 BACKGROUND

30.2 OBJECTIVE

40.3 SCOPE

40.3.1 Scope Included

50.3.2 Scope Excluded

51 PORTFOLIO SYSTEM REQUIREMENTS

51.1 LVS SYSTEM REQUIREMENTS

51.1.1 Overview/System Concept

61.1.2 Assumptions

71.1.3 Functional Requirements

71.1.4 Non-Functional Requirements

81.1.5 Conceptual Data Structure

81.1.6 Security Requirements

81.2 WBL SYSTEM REQUIREMENTS

81.2.1 Overview / System Concept

91.2.2 Assumptions

101.2.3 Functional Requirements

151.2.4 Non-Functional Requirements

151.2.5 Conceptual Data Structure

151.2.6 Security Requirements

161.3 NSTS SYSTEM REQUIREMENTS

161.3.1 Overview / System Concept

171.3.2 Assumptions

181.3.3 Functional Requirements

211.3.4 Non-Functional Requirements

211.3.5 High Level NSTS Data Structure

221.3.6 Security Requirements

222 CONSOLIDATED HOSTING ENVIRONMENT REQUIREMENTS (LVS, WBL, NSTS)

222.1 Overview/System Concept

242.2 Technical Architecture

242.2.1 High-Level Architectural View

252.2.2 Physical High-Level Architectural View

262.2.3 LVS Technical Architecture

282.2.4 WBL Technical Architecture

302.2.5 NSTS Technical Architecture

322.3 Infrastructure Performance and Operational Requirements

322.3.1 Performance Requirements

342.3.2 Operational Requirements

363 CONTRACTOR PERFORMANCE REQUIREMENTS

363.1 Overview

373.2 Methodology Compliance

373.3 Task 1: Establish Infrastructure to Support System Portfolio (LVS, WBL, and NSTS)

373.3.1 Scope of Work

383.3.2 Schedule and Task Description

383.3.3 Task 1.1 Support Facility Certification and Accreditation

393.3.4 Task 1.2 Obtain Infrastructure Purchase Approval

403.3.5 Task 1.3 Install Infrastructure for Development Environment

403.3.6 Task 1.4 Install Infrastructure for System Testing Environment

403.3.7 Task 1.5 Install Infrastructure for Primary Production Environment

413.3.8 Task 1.6 Install Infrastructure for Secondary Production and Staging Environments

413.3.9 Task 1.7 Transition Approach

423.3.10 Task 1.8 Portfolio Enrollment Module

423.3.11 Deliverables and Milestones

443.3.12 Acceptance Criteria

443.4 Task 2: Develop and Implement the LVS

443.4.1 Scope of Work

443.4.2 Schedule and Detailed Task Descriptions

443.4.3 Task 2.1 Develop Software Development Plan

453.4.4 Task 2.2 Develop Quality Assurance Plan

453.4.5 Task 2.3 Validate Requirements

453.4.6 Task 2.4 Develop Deployment Plan

453.4.7 Task 2.5 Develop Configuration Management Plan

463.4.8 Task 2.6 Develop Detailed Design

463.4.9 Task 2.7 Develop System Architecture Document

463.4.10 Task 2.8 Conduct Design Review

463.4.11 Task 2.9 Develop System

473.4.12 Task 2.10 Perform System Security Risk Assessment

483.4.13 Task 2.11 Develop System Security Plan

483.4.14 Task 2.12 Develop IT Contingency Plan and Perform Testing

493.4.15 Task 2.13 Develop System Test Plan and Testing Scripts

493.4.16 Task 2.14 Conduct System Test

493.4.17 Task 2.15 Develop Workshop Materials

503.4.18 Task 2.16 Develop User Guide and Training Materials

503.4.19 Task 2.17 Install Acceptance Test System at Application Service Provider (ASP)

503.4.20 Task 2.18 Support Acceptance Testing

513.4.21 Task 2.19 Conduct Engineering Review

513.4.22 Task 2.20 Conduct Workshops

513.4.23 Task 2.21 Support Development of System Accreditation Documentation

533.4.24 Task 2.22 Support Roll-out Planning

533.4.25 Task 2.23 Conduct Readiness Review Demonstration

533.4.26 Task 2.24 Roll-out System to NRC (Includes Production Install and Training)

543.4.27 Task 2.25 Support Licensee Start-up

543.4.28 Task 2.26 Develop System Refinement Recommendations

543.4.29 Task 2.27 Support Lessons Learned Study

543.4.30 Task 2.28 Support Security Architecture Analysis

553.4.31 Deliverables and Milestones

583.4.32 Acceptance Criteria

583.5 Task 3: Develop and Implement the WBL

583.5.1 Scope of Work

593.5.2 Schedule and Detailed Task Descriptions

593.5.3 Task 3.1 Develop Software Development Plan (SDP)

593.5.4 Task 3.2 Develop Quality Assurance Plan (QAP)

593.5.5 Task 3.3 Validate Requirements

593.5.6 Task 3.4 Develop Deployment Plan

603.5.7 Task 3.5 Develop Configuration Management Plan (CMP)

603.5.8 Task 3.6 Develop Detailed Design

603.5.9 Task 3.7 Develop System Architecture Document (SAD)

603.5.10 Task 3.8 Conduct Design Review

603.5.11 Task 3.9 Develop System

613.5.12 Task 3.10 Update System Security Risk Assessment

623.5.13 Task 3.11 Update System Security Plan

633.5.14 Task 3.12 Update IT Contingency Plan and Perform Testing

633.5.15 Task 3.13 Develop STP and Testing Scripts

633.5.16 Task 3.14 Conduct System Test

643.5.17 Task 3.15 Develop Workshop Materials

643.5.18 Task 3.16 Develop User Guide and Training Materials

643.5.19 Task 3.17 Install Acceptance Test System at Application Service Provider (ASP)

653.5.20 Task 3.18 Support Acceptance Testing

653.5.21 Task 3.19 Conduct Engineering Review

653.5.22 Task 3.20 Conduct Workshops

653.5.23 Task 3.21 Support Development of System Accreditation Documentation

673.5.24 Task 3.22 Support Roll-out Planning

673.5.25 Task 3.23 Conduct Readiness Review Demonstration

683.5.26 Task 3.24 Roll-out System to NRC (Includes Production Install & Training)

683.5.27 Task 3.25 Support Licensee Start-up

683.5.28 Task 3.26 Develop System Refinement Recommendations

683.5.29 Task 3.27 Support Lessons Learned Study

693.5.30 Task 3.28 Support Security Architecture Analysis

693.5.31 Deliverables and Milestones

723.5.32 Acceptance Criteria

723.6 Task 4 Hosting and Operational Support

723.6.1 Task 4.1 Hosting & Operational Support for LVS, WBL, NSTS

753.7 Task 5 Maintenance

753.7.1 Task 5.1 System Maintenance for LVS, WBL, NSTS

763.8 Task 6 User/Help Desk Support

763.8.1 Task 6.1 User/Help Desk Support for LVS, WBL, NSTS

783.9 Task 7: WBL (v1.x) Development (Optional - 1 Yr)

783.10 Task 8: WBL (v2.x) development (Optional - 1 Yr)

783.11 Task 9: WBL (v3.x) development (Optional - 1 Yr)

793.12 Task 10: NSTS (vx.x) development (Optional - 1 Yr)

793.13 Task 11: WBL Agreement State License data entry support

804 DESIGN AND IMPLEMENTATION CONTROLS

804.1 General Design and Implementation Controls

814.2 Detailed Design and Implementation Controls for Security

814.2.1 System Security Requirements

834.2.2 Additional Security Considerations

834.3 Detailed Controls for Engineering, Development and Testing

844.4 Engineering the Solution

874.5 Detailed Controls for Training

884.6 Detailed Controls for Ongoing Support

895 OTHER TERMS AND CONDITIONS

895.1 Government Furnished Equipment

895.2 Performance Requirements

895.3 Travel

905.4 Reporting Requirements

905.4.1 Weekly reports and meetings

905.4.2 Project Management Plan

905.4.3 Monthly reports and meetings

905.4.4 Provide data for earned value management reporting

926 REFERENCES

0 INTRODUCTION TC "INTRODUCTION" \f C \l "1"

0.1 BACKGROUND TC "1.1 BACKGROUND" \f C \l "1"

The events of September 11, 2001, heightened the nation’s concern regarding the use of radioactive materials for a malevolent act. The potential for such an attack has been of particular concern because of the widespread use of radioactive materials (often contained in sealed sources) in the United States and abroad by industry, hospitals, and academic institutions. A major impetus for this project is the need to control radioactive materials that could be used in a radiological dispersal device or “dirty bomb” – a conventional explosive that carries radioactive materials and releases them on detonation. The Nuclear Regulatory Commission (NRC) has been proactively working on material “real time” tracking capability since 2005.

In late 2006 and early 2007, the Government Accountability Office (GAO) conducted a test of the NRC controls governing the issuance of licenses for possessing certain types of radioactive materials and for enforcing possession limits on the quantities of those materials. Subsequently, GAO reported that they were able to obtain radioactive materials licenses for two fabricated companies, modify the licenses to raise the possession limits, and utilize the augmented licenses to receive quotes for purchasing radioactive materials from legitimate licensees.

At a July 12, 2007, Senate Committee on Homeland Security and Governmental Affairs Permanent Subcommittee on Investigations (PSI) hearing following GAO’s report, it was suggested that the NRC should consider establishing a web-based licensing (verification) system that would allow suppliers to validate purchaser licenses and the authorized quantity that a purchaser could obtain. GAO, NRC, and Congress deemed this as a necessary and urgent IT initiative to protect the nation from the threat of malevolent use of radioactive materials.

In an effort to better track radioactive materials, the NRC developed a comprehensive action plan outlining a number of specific steps to address the concerns raised by the GAO report and in the Senate Committee hearing. Part of this plan consists of establishing an Integrated Source Management Portfolio of automated tools for credential tracking (license and certificate), inspection tracking, item tracking (devices and sources), and license verification. The portfolio consists of three systems – (1) the National Source Tracking System (NSTS) which is in production, (2) the Web-Based Licensing (WBL) system which is in development, and (3) the License Verification System (LVS) which is in the planning phase. A description of each system is provided below.

0.1.1 NSTS TC "1.1.1 NSTS" \f C \l "1"

The NSTS which received an authority-to-operate (ATO) in December 2008, tracks the transfer of responsibility of sealed sources of radioactive materials. This tracking spans the life cycle of the source from manufacture through shipment receipt, decay and burial. It supports controlled authorizations and accountability for licensed suppliers and licensed recipients of sealed sources. The successful implementation of NSTS satisfies NRC’s commitment to Congress to develop source tracking capabilities and satisfies the International Atomic Energy Agency’s Code of Conduct’s call for a national, central database of high-risk sources.

NSTS helps the NRC:

· monitor the location, possession and disposal of radioactive sources of concern throughout the country;

· improve accountability and give better information to decision makers;

· detect and act on tracking discrepancies;

· conduct inspections and investigations;

· communicate radioactive source information among Government agencies;

· respond in the event of an emergency;

· verify legitimate import, export, ownership, and use of radioactive sources; and

· further analyze hazards attributable to the possession and use of radioactive materials.

1.1 0.1.2 WBL TC "1.1.2 WBL" \f C \l "1" The WBL is envisioned as a NRC material licensing and inspection system. WBL manages the licensing life-cycle from initial application, license issuance, amendment, reporting, and de‑licensing; it provides a computerized record of each specific license; and it tracks inspections related to the licenses. WBL is designed to maintain information on NRC material licensees but, in the future, will also include Agreement State licensing information. WBL shall replace two aging legacy systems, the licensing tracking system (LTS) and the inspection planning system (IPS).

Once WBL is established, it is envisioned that the NRC will use this modern licensing/ inspection platform to incorporate other types of materials ‘license’ tracking systems in the future. This would include systems such as:

· Reciprocity tracking system (RTS) – used to track Agreement State licensee requests for reciprocity.

· Transportation Approval Package Information System (TAPIS) – used to maintain information about NRC certified packages and quality assurance programs used by companies involved in transportation of radioactive material.

· BARTO System – used to track the proposed and actual schedules for spent fuel package reviews. (Note: TAPIS and BARTO combined are called the – Storage and Transportation Information Management System (STIMS)).

· National Sealed Source and Device Registry System (NSS&DRS) – used to maintain fundamental information about device and source certificates of registration.

· Import/Export Licensing process – used to track licenses issued for international import and export of radioactive material. (Note: See appendices AA-AE for description of the systems mentioned above).

WBL shall help the NRC:

· streamline the materials licensing processes for Licensees and NRC staff;

· support related licensing inspection activities;

· establish an information technology architecture that can support Web based communication with the licensees;

· provide a licensing information repository to support other related systems (e.g., NSTS, LVS);

· provide a modern framework that can be leveraged to incorporate other systems.

1.2 0.1.3 License Verification System (LVS) TC "1.1.3 License Verification System (LVS)" \f C \l "1" The LVS is envisioned as a “national verification system” that would access NRC and Agreement State licensee information and be used for purposes of detecting and preventing unauthorized parties with malicious intent from obtaining radioactive materials. The LVS is planned to be an integrated service that shall broker information stored in WBL and NSTS to provide the validations to ensure that (a) a license is valid and accurate; (b) a licensee is authorized for acquiring quantities and types of radioactive materials; and (c) the current levels of licensee inventory tracked sources is within the possession limits. The LVS shall be designed to handle request transactions for validation functions. It shall work in much the same way as the approval process for a credit card purchase. When a merchant checks to verify a credit card the only information returned is whether or not the transaction is approved. LVS shall take in the validation request and, through examination of information available from both NSTS and WBL, will provide a response indicating whether or not a license is valid and a pending purchase is within the bounds of the possession limits and inventory.

LVS shall help the NRC:

· enable authorized licensees nationwide to confirm the validity of a licensee seeking to obtain radioactive material and to confirm the licensee’s possession compliance;

· enable Government authorities to view specific information on Supplier and Receiver licensees as necessary to verify shipments of radioactive materials;

· prevent misrepresentation or fictitious claims by an entity of its authorization to possess and use radioactive materials.

0.2 OBJECTIVE TC "1.2 OBJECTIVE" \f C \l "1"

Within the U.S. NRC, the Office of Federal and State Materials and Environmental Management Programs (FSME) develops, implements and oversees the regulatory framework for industrial, commercial, and medical uses of radioactive materials, uranium recovery activities and the decommissioning of previously operating nuclear facilities and power plants. In addition, FSME conducts extensive environmental assessments in support of these regulatory functions. The NRC implements these regulatory programs in coordination with partners at other Federal agencies, the States, the NRC Regions, and Tribal Governments.

FSME has been charged with implementation of an Integrated Source Management Portfolio that supports the FSME mission in a manner that protects public health and safety, provides for the common defense and security, and protects the environment.

The objective is for the Contractor to:

· Establish the Infrastructure to Support the FSME systems (LVS, WBL, and NSTS)

· Develop and Deploy IT systems that support the FSME mission

· Provide System Hosting and Operational Support, Maintenance, and User and Help Desk Support

These tasks will support the new business practices needed to improve security for radioactive materials. The Contractor shall provide all personnel, materials, hardware, software, supplies, equipment, travel, and other direct costs necessary to accomplish the performance of the tasks described in Section 3.

0.3 SCOPE TC "1.3 SCOPE" \f C \l "1"

0.3.1 Scope Included TC "1.3.1 Scope Included" \f C \l "1"

This SOW includes development, testing, training, and deployment of the LVS and WBL systems; operational and maintenance support, user support, and hosting of LVS, WBL and NSTS. These tasks cover a broad range of activities including:

· system Infrastructure Setup

· system Development, Testing, and Deployment

· system Operational Support

· database and application hosting for the LVS, WBL, NSTS systems

· maintenance of all LVS, WBL and NSTS infrastructure that is external to the NRC headquarters campus

· database and application software maintenance for the LVS, WBL and NSTS

· help desk establishment to provide comprehensive user support for all systems

This SOW is comprised of the following 11 tasks:

1. Task 1: Establish Infrastructure to Support System Portfolio (LVS, WBL, and NSTS)

2. Task 2: Develop and Implement the License Verification System (LVS)

3. Task 3: Develop and Implement the WBL

4. Task 4: Hosting and Operational Support

5. Task 5: System Maintenance

6. Task 6: User Support / Help Desk

7. Task 7: WBL (v1.x) Development (optional)

8. Task 8: WBL (v2.x) Development (optional)

9. TASK 9: WBL (v3.x) Development (optional)

10. Task 10: NSTS (vx.x) Development (optional)

11. Task 11: WBL Agreement State License Data Entry Support (optional)

0.3.2 Scope Excluded TC "1.3.2 Scope Excluded" \f C \l "1"

This SOW does not cover any Portfolio related costs or effort by NRC staff.

1 PORTFOLIO SYSTEM REQUIREMENTS TC "PORTFOLIO SYSTEM REQUIREMENTS" \f C \l "1"

1.1 LVS SYSTEM REQUIREMENTS TC "1.4 LVS SYSTEM REQUIREMENTS" \f C \l "1" The Section below summarizes the LVS high-level system requirements which are included as Appendix A of this SOW.

1.1.1 Overview/System Concept TC "1.4.1 Overview/System Concept" \f C \l "1" The LVS shall provide a way for certain licensees nationwide to confirm the license validity and maximum possession limit compliance of other licensees seeking to obtain radioactive materials. LVS shall also allow authorized Government authorities to verify certain information about licensees authorized to supply or obtain radioactive materials. LVS shall enable the NRC to support its materials safety program functions in ensuring safety and security for the possession and use of radioactive source materials and it will address the security vulnerabilities identified by the GAO in the NRC’s radioactive materials licensing process.

LVS is envisioned as a ‘broker’ that queries information stored in other existing NRC systems, such as the NSTS and the WBL. LVS itself shall not store licensing or source information and shall maintain ‘read-only’ access to these other NRC systems. LVS shall, however, track and store information about licensee relationships and verification requests.

The Context Diagram above shows the direct users of LVS (Receiver and Supplier Licensees) and describes how the users and automated systems will interface.

1.1.2 Assumptions TC "1.4.2 Assumptions" \f C \l "1"

· WBL and NSTS shall provide the data necessary for LVS to verify license and maximum possession limits (licensing information stored in LTS shall be used until WBL is deployed).

· WBL shall be expanded to become a national system containing license data for both NRC and Agreement State licensees.

· Maximum possession limit data will be stored in WBL in a standardized format as much as possible to facilitate verification calculations.

· Source inventory data will be stored in NSTS in a standardized format as much as possible so that this data can be easily compared with the maximum possession limits from WBL.

· LVS shall only provide source inventory verifications on category levels supported by NSTS.

· LVS, WBL, and NSTS shall be hosted at the same data center. These systems will leverage shared resources at the data center as appropriate.

· LVS shall support various user roles to provide different functionality for licensee users and Government agency users.

1.1.3 Functional Requirements TC "1.4.3 Functional Requirements" \f C \l "1" The functional requirements define the intended behavior of the system from the NRC business point of view. They describe what actions and processes will exist in the system and how they will behave. The LVS functional requirements have been documented using the ‘use-case technique’ which is a way of describing the behavior of a system from the viewpoint of the users that interact with the system. The LVS Use Case (UC) Model below displays the LVS high-level Use Cases (ovals) and how the Use Case Actors, both human and automated, (shown as stick figures) will interact with LVS.

LVS requirement details are provided in Appendix A of this SOW – LVS High Level Requirements.

1.1.4 Non-Functional Requirements TC "1.4.4 Non-Functional Requirements" \f C \l "1" Non-Functional Requirements define the non-behavioral attributes of the system. These include characteristics such as workload, response time, data integrity, data capacity, reliability, backup and recovery, maintainability, expandability, hosting facility capabilities, human factors (usability), record keeping requirements, and special requirements (e.g., Section 508 compliance). LVS shall operate under the same non-functional requirements as WBL. For details on the Non‑Functional requirements, refer to the WBL system requirements which are included as an appendix to this SOW and the Infrastructure and Operational Requirements in Section 3.3. LVS has a maximum user count of: 55,000 users (2,500 concurrent).

1.1.5 Conceptual Data Structure TC "1.4.5 Conceptual Data Structure" \f C \l "1" LVS has limited data that it tracks. LVS is essentially a ‘broker’ that communicates with WBL and NSTS in order to verify license and source inventory information. LVS does not itself store the license or source inventory information.

The key data that LVS does store and track is the Radioactive Materials Requests that a Receiver Licensee initiates. LVS also stores the status and resolution of these requests. The table below shows the data structure of the Radioactive Materials Request table.

SEQ CHAPTER \h \r 1 Sample Radioactive Materials Request Table

1.1.6 Security Requirements TC "1.4.6 Security Requirements" \f C \l "1" Refer to Section 4.2.1 of this SOW for LVS security requirements.

1.2 WBL SYSTEM REQUIREMENTS TC "1.5 WBL SYSTEM REQUIREMENTS" \f C \l "1" The Section below summarizes the WBL system requirements which are included as Appendix B of this SOW.

1.2.1 Overview / System Concept TC "1.5.1 Overview / System Concept" \f C \l "1" The WBL system will leverage modern web technologies to support the NRC’s licensing and inspection processes by tracking the license application processes (new licenses, renewals, amendments, and terminations); providing computerized records of each specific license; and planning and tracking inspection activities. WBL shall also support e-Gov by allowing licensees to submit and track the progress of license actions through a web interface. WBL* will replace two legacy mainframe systems -LTS for its licensing tracking capability and the IPS for its inspection planning and tracking capability.

The Context Diagram below shows the major classes of users and the system interfaces that form the context for WBL.

WBL System Context Diagram

1.2.2 Assumptions TC "1.5.2 Assumptions" \f C \l "1"

· WBL shall be built by adapting a product called the Radioactive Material License System (RADMAT). The NRC has obtained unlimited rights to this product through a license agreement executed with the State of Ohio’s Department of Health.

· Initially, WBL shall only store NRC license information. The WBL shall be designed to be scalable to accommodate the addition of license and maximum possession limit information from Agreement States.

· Maximum possession limit data will be stored in WBL in a standardized format as much as possible to facilitate verification calculations.

· The user base for WBL shall include authorized NRC staff, Licensees, and partner Government Agencies. The maximum user count is 10,000 users (200 concurrent).

· LVS, WBL, and NSTS shall be hosted at the same data center. These systems will leverage shared resources at the data center as described in Section 2 – Consolidated Hosting Environment Requirements.

1.2.3 Functional Requirements TC "1.5.3 Functional Requirements" \f C \l "1" The functional requirements define the intended behavior of the system from the NRC business point of view. They describe what actions and processes will exist in the system and how they will behave. The WBL functional requirements have been documented using the ‘use-case technique’ which is a way of describing the behavior of a system from the viewpoint of the users that interact with the system.

The WBL Use Case Models shown on the following pages display the WBL Use Cases (ovals) and how the Use Case Actors, both human and automated, (shown as stick figures) will interact with WBL.

The use cases diagrams are grouped into the following categories:

· Licensing Use Cases – Internal: This functional group contains use cases that are used by internal WBL users (e.g., NRC staff) to enter, track, and modify licensing related information.

· Inspection Use Cases – Internal: This functional group contains use cases that are used by internal WBL users (e.g., NRC staff) to enter, track, and modify inspection related information.

· Licensing Use Cases – External: This functional group contains use cases that are used by external WBL users (e.g., Licensees, State Agencies, Other Government Agencies) to enter, track, and modify licensing related information.

· System Administrator and Reporting: This functional group contains use cases that are used for system administration and reporting purposes.

WBL requirement details are provided in Appendix B of this SOW – WBL System Requirements Specifications.

WBL Licensing Use Cases – Internal

WBL Inspection Use Cases – Internal

WBL Licensing Use Cases – External

WBL System Administrator and Reporting Use Cases

1.2.4 Non-Functional Requirements TC "1.5.4 Non-Functional Requirements" \f C \l "1" Non-Functional Requirements define the non-behavioral attributes of the system. These include characteristics such as workload, response time, data integrity, data capacity, reliability, backup and recovery, maintainability, expandability, hosting facility capabilities, human factors (usability), record keeping requirements, and special requirements (e.g. Section 508 compliance). For details on the Non-Functional requirements, refer to the WBL system requirements which are included as an appendix to this SOW and the Infrastructure and Operational Requirements in Section 3.3.

1.2.5 Conceptual Data Structure TC "1.5.5 Conceptual Data Structure" \f C \l "1" Below is a conceptual data model that shows the major data entities of WBL as well as the associations / relationships between the data entities.

WBL Conceptual Data Model

1.2.6 Security Requirements TC "1.5.6 Security Requirements" \f C \l "1" Refer to Section 4.2.1 of this SOW for WBL security requirements.

1.3 NSTS SYSTEM REQUIREMENTS TC "1.6 NSTS SYSTEM REQUIREMENTS" \f C \l "1" The Section below summarizes the NSTS system requirements which are included as Appendix C of this SOW. The NSTS has been built according to these requirements.

1.3.1 Overview / System Concept TC "1.6.1 Overview / System Concept" \f C \l "1" The NSTS tracks the manufacture, possession and transfer of individual radioactive sealed sources by U.S. radioactive materials and import/export licensees. It tracks the sources throughout their entire life-cycle. The major functions provided by NSTS include:

· the ability to record information about individual sealed sources including important source characteristics such as: make, model, serial #, isotopes, activity, activity date, and status;

· the ability to record the list of individual sources that are currently associated with each license (an inventory);

· the ability to track the transfer of possession of an individual source from one licensee to another and from one status to another (e.g., ‘active’ to ‘lost’);

· the ability to see a full history of transfers and status changes for an individual source;

· the ability for the licensing agencies (NRC, Agreement State agencies, and DOE) to maintain the license information of their respective jurisdictions, including the ability to record source such incidents: e.g., lost, stolen, destroyed, irretrievable, and found sources;

· the ability to import data files submitted by licensees and other stakeholders;

· the ability to schedule and generate both pre-programmed and ad-hoc reports, to upload electronic files of source and license information from external systems, and to extract source information for use by other federal agencies; and

· the ability to provide event monitoring and alert notifications to enhance the timely reporting and monitoring of NSTS data integrity.

NSTS System Context Diagram

1.3

1.3.2 Assumptions TC "1.6.2 Assumptions" \f C \l "1"

· Source inventory data will be stored in NSTS in a standardized format as much as possible so that this data can be easily compared with the maximum possession limits from WBL.

· NSTS currently tracks category 1 and 2 sources. In the future, NSTS may track additional source category types. NSTS’ current scalable design can accommodate tracking additional sources that fall within lower category levels.

· The user base for NSTS includes NRC staff, licensees, and Government agencies. The maximum user count is 20,500 users (1,000 concurrent).

· LVS, WBL, and NSTS shall be hosted at the same data center. These systems will leverage shared resources as described in Section 2 – Consolidated Hosting Environment Requirements.

1.3.3 Functional Requirements TC "1.6.3 Functional Requirements" \f C \l "1" The functional requirements define the intended behavior of the system from the NRC business point of view. They describe what actions and processes will exist in the system and how they will behave. The NSTS functional requirements have been documented using the ‘use-case technique’ which is a way of describing the behavior of a system from the viewpoint of the users that interact with the system.

The NSTS Use Case Models shown on the following pages display the NSTS Use Cases (ovals) and how the Use Case Actors (both human and automated, shown as stick figures) will interact with NSTS.

The use cases diagrams are grouped into the following categories:

· Licensee Use Cases: This functional group contains use cases that are used by licensees to enter, track, and modify source and source transfer information.

· Licensing Agency Use Cases: This functional group contains use cases that are used by licensing agency users to enter, track, and modify source and source transfer information.

· System Administrator and Timer Use Cases: This functional group contains use cases that are used for system administration, automated alerts, and interfacing purposes.

NSTS requirement details are provided in Appendix C of this SOW – NSTS System Requirements Specifications.

NSTS Licensee Use Cases

NSTS Licensing Agency Use Cases

NSTS System Administrator and Timer Use Cases

1.3.4 Non-Functional Requirements

Non-Functional Requirements define the non-behavioral attributes of the system. These include characteristics such as workload, response time, data integrity, data capacity, reliability, backup and recovery, maintainability, expandability, hosting facility capabilities, human factors (usability), record keeping requirements, and special requirements (e.g., Section 508 compliance). For details on the non-functional requirements, refer to the NSTS system requirements which are included as an appendix to this SOW and the Infrastructure and Operational Requirements in Section 3.3.

1.3.5 High Level NSTS Data Structure TC "1.6.4 High Level NSTS Data Structure" \f C \l "1" Below is a high-level data model that shows the major data entities of NSTS as well as the associations / relationships between the data entities.

1.3.6 Security Requirements TC "1.6.5 Security Requirements" \f C \l "1" Refer to Section 4.2.1 of this SOW for NSTS security requirements.

2 CONSOLIDATED HOSTING ENVIRONMENT REQUIREMENTS (LVS, WBL, NSTS) TC "2 CONSOLIDATED HOSTING ENVIRONMENT REQUIREMENTS (LVS, WBL, NSTS)" \f C \l "1"

2.1 Overview/System Concept TC "2.1 Overview/System Concept" \f C \l "1" The consolidated hosting environment will house LVS, WBL and NSTS and is expected to include both a primary site and a secondary (failover) site each with redundant components within its site. It is also expected that the three systems will share several components of the hosting environment. This includes: physical facility hosting, common networking components, telecommunication lines between sites, hosting services support staff, etc. However, each system will have its own protected region within the consolidated hosting environment as well. The diagram below shows a conceptual representation of the consolidated hosting environment.

The Contractor shall use a portion of the secondary site infrastructure as a staging area used for formal user acceptance testing prior to promoting a release to production.

The Contractor shall provide development and testing environments. These environments do not necessarily need to be housed within the consolidated hosting environment.

The Contractor shall implement the infrastructure such that it is scalable to accommodate for inclusion of optional license types such as RTS, STIMS (TAPIS, BARTO), NSSDRS, GLTS, and Import export licenses.

2.2 Technical Architecture TC "2.2 Technical Architecture" \f C \l "1" This Section describes the high-level architectural design that the Contractor must implement. It also describes specific technologies that LVS and WBL are expected to use and specific technologies that NSTS currently uses.

2.2.1 High-Level Architectural View TC "2.2.1 High-Level Architectural View" \f C \l "1" Although each of the three systems’ specific technologies may differ, they must all use a multi‑tiered web architecture that logically separates the three classic partitions of an information system – Presentation (User Interface), Logic, and Data.

The diagram above shows a conceptual high-level architectural view of a properly designed multi-tiered Web application. It illustrates an information system divided into the three classic partitions – the Presentation (User Interface), Logic, and Data layers. These layers ensure that each of the main architectural areas of the application remain distinct from each other. That is, each of these partitions has its own domain in which specific aspects of functionality are addressed. The diagram above is provided for your information.

· Presentation Layer

The Presentation layer (sometimes referred to as the User Interface layer) is comprised mainly of visual components that make up the user-interface and defines how a user interacts with the system. The user interface must be clear and concise, leveraging the best practices of visual design to create an intuitive environment for the user. The presentation layer is the one most directly responsible for Section 508 compliance.

· Logic Layer

The Logic layer is where the business rules of the application reside. The business logic of the system is encapsulated in multiple well-defined discrete business objects (components) that work together under the direction of one or more controller objects which determine the order in which the business objects are called. The Logic layer also contains multiple special-purpose business objects called ‘data access objects’ that are responsible for actually performing operations on the data itself.

· Data Layer

The Data layer is where the application’s data resides. This layer is responsible for the long-term storage of data collected or generated by the system. The relational database management system’s (RDBMS) data integrity and transactional capabilities are used to ensure data integrity. This includes referential integrity features (e.g., primary key / foreign key relationship constraints) and logical unit-of-work features (e.g., atomic rollback or commit).

2.2.2 Physical High-Level Architectural View TC "2.2.2 Physical High-Level Architectural View" \f C \l "1" In Production, these logical layers are implemented physically for each system as separate clusters that are protected and controlled via firewalls, routers, switches and security appliances. The high-level physical architectural components include:

· Border Routers and Global Traffic Manager – These components are the entry point for the users. They are a shared component of the consolidated hosting environment that examines the user request to determine which system (LVS, WBL, NSTS) to route the request to. The Global Traffic Manager serves as an SSL Accelerator, load balancer, and traffic monitor.

· Perimeter firewall – This firewall provides a gateway to the system’s Demilitarized Zone (DMZ). The users will access the system’s Web Server through this firewall. This configuration will isolate the external users from the back-office system.

· Web Server Cluster – The web servers provide web content to the end-users.

· Application Zone firewall – This firewall provides a gateway from the DMZ to the back-office systems. Access to users of the back-office systems is granted via a secure connection and is restricted to only users with authorized access permissions.

· Application Server Cluster - The application servers are used to process user requests. They contain the logic engine that receives user requests, calls the database layer, applies business rules, and sends the results back to the web cluster for display to the user.

· Data Zone firewall – This firewall provides a gateway from the application servers to the database servers. Access to the database servers is granted via a secure connection and is restricted to only users with authorized access permissions.

· Database Server Cluster – This cluster consists of multiple database servers and a shared SAN storage grid. It houses and protects the application data, enforces data layer integrity rules, and provides data level logic via stored procedures and triggers.

Below is a list of hardware components that are part of the existing NSTS hosting environment. NRC expects that these components would be shared by LVS, WBL, and NSTS in a consolidated hosting environment. The list below is provided here to show the Contractor what’s currently being used. However, the Contractor would be allowed to propose comparable hardware and software.

Specific Shared Hardware

2.2.3 LVS Technical Architecture TC "2.2.3 LVS Technical Architecture" \f C \l "1" LVS is currently in a planning phase and the application itself will be developed as part of this Integrated Source Management Portfolio SOW. LVS shall use the established technologies that NSTS uses currently. This includes: Linux servers, Oracle application and database servers, and Java web development tools.

Below is a more specific list of hardware and software that may be used for LVS. It is provided here to show what’s currently being considered. The Contractor is allowed to propose comparable hardware and software.

Development / Test Hardware

Web/Application Zone

Data Zone

All Zones

Production Hardware

Web Zone

Application Zone

Data Zone

All Zones

Development / Test Software

Oracle Application Server, SE

Production Software

Oracle Application Server, SE

2.2.4 WBL Technical Architecture TC "2.2.4 WBL Technical Architecture" \f C \l "1" The RADMAT system is currently being adopted for internal NRC use by migrating the LTS data to the RADMAT environment and by minimally adapting the system to initially serve as a replacement for LTS. It is expected that this Integrated Source Management Portfolio contract will further adapt RADMAT in order to provide all the WBL functionality.

WBL shall use the established technologies that RADMAT uses currently. This includes Windows servers, Microsoft Internet Information Services (IIS) web/application servers, Microsoft SQL Server database servers, and .NET web development tools.

Below is a more specific list of hardware and software that may be used for RADMAT. This list is provided to show what’s currently being considered, however, the Contractor is allowed to propose comparable hardware and software.

Development/Test Hardware

Web/Application Zone

Data Zone

All Zones

Web Zone

Application Zone

Data Zone

All Zones

Development/Test Software

2.2.5 NSTS Technical Architecture TC "2.2.5 NSTS Technical Architecture" \f C \l "1" NSTS is currently in use. Ongoing operations and maintenance of NSTS shall be performed as part of this Integrated Source Management Portfolio SOW. Currently, NSTS uses Linux servers, Oracle application and database servers, and Java web development tools.

Below is a more specific list of hardware and software that is currently used for NSTS. This list is to show what’s currently being used. The Contractor is allowed to propose comparable hardware and software.

Development/Test Hardware

Web/Application Zone

Data Zone

All Zones

Web Zone

Application Zone

Data Zone

All Zones

Development/Test Software

Oracle Application Server, SE

Oracle Application Server, SE

2.3 Infrastructure Performance and Operational Requirements TC "2.3 Infrastructure Performance and Operational Requirements" \f C \l "1"

2.3.1 Performance Requirements TC "2.3.1 Performance Requirements" \f C \l "1" SEQ CHAPTER \h \r 1The Performance Requirements define non-behavioral attributes of the systems that cover overall performance and robustness. This includes characteristics such as workloads, response time, data integrity, data capacity, reliability, maintainability, and expandability.

2.3.1.1 External Workloads

The infrastructure must provide enough storage, processing, and memory resources to accommodate periodic batch data loads as described in the WBL and NSTS requirements documentation (see Appendices B and C).

2.3.1.2 Throughput, Response Times, and Internal Function Workload SEQ CHAPTER \h \r 1The infrastructure must provide acceptable response times for all functions of the systems. In particular: the systems must present screens to the user within 5 seconds of the user request; the systems must complete sort operations within 5 seconds of the sort and save request; the systems must save data to the database within 5 seconds of the save request; the systems must display the results of a search operation within 30 seconds of the search request; and the systems must present the user with a measurable indication of progress if there is more than a 10 second processing delay. These response times apply to the expected number of concurrent users as described in each system’s requirements (see Section 2 – Portfolio System Requirements). (See appendix A, B, C)

2.3.1.3 Data Quality, Integrity, and Accuracy

SEQ CHAPTER \h \r 1The infrastructure must fully utilize the data integrity, logging, and transaction management capabilities available in the Oracle and MS SQL Server database software to ensure data integrity. This includes referential integrity features (e.g., primary key / foreign key relationship constraints) and logical unit-of-work features (e.g., atomic rollback or commit). Each system must also provide the ability to generate a unique identifier for a record created in the system. Through system and database constraints, the Contractor shall ensure that the generated identifier may not be altered by any user at any time.

2.3.1.4 SEQ CHAPTER \h \r 1Data Retention, System Capacity, and Communications Capacity The operational infrastructure must retain all operational and historical data for the life of the systems.