Attachment J.5_ECMP Technical and Performance Requirements.doc

Comptroller of the Currency Office of Management

Business Relations and

Project Management Office (PMO)

ECMP

Technical and Performance Requirements August 2, 2011 Version 3.0 Document Control Project Name Economics Computing Modernization Project

Project Acronym

ECMP

Document Title ECMP Technical and Performance Requirements Document Date August 2, 2011 Document Version 3.0

Client Organization Economics (ECON)

Primary Client Contact Debbie Kligman Primary Author Marcy BonDurant

Contributing Authors Sarah Noh PMO Project Manager Deborah Spears, Rodney Piette

Supporting Contractor TeraThink

Contract Number

TCC-07-HQ-D-0052

Task Order Number

TCC-10-HQ-0009

Deliverable Number 05.003 Version Name Final Version

Open Text Document Category System Development

Open Text Document Type

Requirements Document Open Text Document Number 263569 Table of Contents

Introduction

11.1 Document Purpose and Scope

11.2 Project Background

11.2.1 OCC Economics

21.2.2 The Economics Computing Modernization Project

31.3 Assumptions and Constraints

Solution Requirements Overview

42.1 Scope

42.2 Solution Delivery

52.3 Environments

72.4 Architecture

82.5 Users, Roles, and Permissions

82.6 Analysis

92.6.1 Applications

92.6.2 Data

92.6.3 Programs

Technical Requirements

103.1 Context

103.2 Requirements

103.2.1 Hosting Requirements

113.2.2 Environment Requirements

113.2.3 Architecture Requirements

123.2.4 Telecom and Network Requirements

123.2.5 Operating System Requirements

133.2.6 Database Requirements

133.2.7 Server Requirements

133.2.8 Storage Requirements

143.2.9 Memory Requirements

143.2.10 CPU Requirements

Performance Requirements

154.1

154.2

Capacity Requirements

165.1

165.2

165.2.1 Baseline Capacity

185.2.2 Capacity Scalability

Solution Availability Requirements

206.1

206.2

Recoverability Requirements

227.1

227.2

227.2.1 Ad Hoc Recovery Requirements

227.2.2 Disaster Recovery Requirements

237.2.3 Transferability Requirements

Security Requirements

248.1

248.2

Operations Requirements

269.1

269.2

269.2.1 Analytic Operations Requirements

279.2.2 Solution’s System Administration Operations Requirements

289.2.3 Solution Reporting Operations Requirements

Data Management Requirements

3010.1

3010.2

3010.2.1 Data Management Requirements

3110.2.2 Metadata Management Requirements

3110.2.3 Reference Data Requirements

3210.2.4 Data Security Requirements

3210.2.5 Data Acquisition Requirements

3210.2.6 Data Obtainment Requirements

3410.2.7 Data Load Requirements

3510.2.8 Data File Creation Requirements

3510.2.9 File QA Requirements

3610.2.10 Data File Transformation Requirements

3710.2.11 Content Promotion and Versioning Requirements

3710.2.12 Archival and Retrieval Requirements

3910.2.13 Data Migration Requirements

Solution Support Requirements

4011.1

4011.2

4011.2.1 Change Management Services

4111.2.2 Configuration Management Services

4211.2.3 Solution Monitoring and Notification Services

4311.2.4 Environment Management Services

4411.2.5 Hardware and Software Management Services

4411.2.6 Network Management Services

4511.2.7 Data and Metadata Management Services

4511.2.8 Database Management Services

4511.2.9 Security and Control Services

4611.2.10 Capacity Planning Services

4611.2.11 Help Desk Services

4811.2.12 Code Conversion, Parallelization, and/or Optimization Services for SAS Programs

4811.2.13 SLA Management Services

4911.2.14 Risk Management Services

4911.2.15 License Management Services

4911.2.16 Disaster Recovery Services

IT Accessibility Requirements

5012.1

5012.2

5012.2.1 Functional Performance Criteria

5012.2.2 Applicable Technical Standards

5012.2.3 Information, Documentation and Support

Audit and Accountability Requirements

5113.1

5113.2

5113.2.1 General Audit and Accountability Requirements

5113.2.2 Audit Logging of Account Management Activities

5113.2.3 Audit Logging of Information Security Controls

5213.2.4 Audit Logging of Data Change and Access

5213.2.5 Audit Record Content

5213.2.6 Audit Record Retention

5313.2.7 Protection of Audit Information

A-1Appendix A Tool Classification Scheme

B-1Appendix B Data Classification Scheme

C-1Appendix C Requirements Priority Matrix

D-1Appendix D Acronyms

List of Figures

6Figure 2–1 ECM Notional Environment Architecture

Figure 2–2 ECM Environment Promotion Model

List of Tables 5Table 2–1 Delivery Phases

Table A–1 Tool Classification Scheme A-1 Table B–1 Data Classification Scheme B-1 Table D–1 Acronyms D-1

1 Introduction

Document Purpose and Scope

This document defines the technical and performance requirements for the Office of the Comptroller of the Currency’s (OCC) Economics Computing Modernization Project (ECMP). Additionally, this document provides the tool classification scheme for all tools employed by OCC Economics and the data classification scheme for all data used by OCC Economics and relevant to the Economics Computing Modernization (ECM) solution.

The scope of this document is limited to the technical and performance requirements required to deliver the ECM solution. Functional requirements are incorporated into the ECMP Solution Use Case Model. Also excluded from these requirements are the associated business processes that will be implemented within the OCC and between the OCC and the solution provider to support the ECM solution. The Solution Support Requirements detail the services the solution will require, and inferences may be drawn as to the associated required business processes.

Offerors should carefully note that the language of the Technical and Performance Requirements document and all associated documents is intended to convey requirements without predisposition toward any specific software product, platform, or technology except insofar as technical requirements are specifically described. The OCC will consider any cost-effective technology solution that successfully addresses the use cases and requirements and effectively supports the business objectives of the OCC Economics Department. In addition, the OCC encourages Offerors to view these requirements as guidelines to meet the business objectives of OCC Economics. As long as the OCC’s performance requirements are met (see Section 4) and the Offeror demonstrates that its proposed solution offers best value, the OCC will entertain all innovative ideas that meet or exceed these objectives and the spirit of the associated requirements.

Project Background

OCC Economics

The primary mission of Economics within the OCC is to deliver economic and quantitative analysis to policymakers and bank examiners. OCC Economics supports on-site and off-site supervision of banks, provides current economic analysis, supports policy development, and conducts original research to support the OCC mission of ensuring a safe and sound national banking system.

Examples of activities performed by OCC Economics include:

· Examination of banks’ use of financial models

· Fair-lending screens and fair-lending exams

· Examiner training and industry outreach

· Research on current and emerging issues in banking, finance, and economics

· Participation in international and interagency working groups

· Analysis and briefings focused on assessment of risks in the aggregate, both domestic and international

· Interagency policy development and coordination

· Economic impact analyses

To fulfill these responsibilities, OCC Economics employs a team of economists, mathematicians, statisticians, financial and policy analysts, and technology professionals to perform highly complex, resource-intensive data processing and financial modeling. Given the nation’s dynamic banking system and its increasing exposure to international developments, the assessment of risk in the banking system and the associated responsibilities for economic analysis require sophisticated data processing, data storage, and computing systems. Moreover, to keep pace with changes in the environment, these resources must (a) change, expand and, or contract as necessary; (b) support a diverse set of needs and applications; and (c) be maintained, integrated, organized, and secured to ensure OCC Economics is able to fulfill its current mission as well as meet increasingly complex challenges.

OCC Economics has outgrown its current computing infrastructure, which consists of individualized workstations, servers, and highly distributed storage resources. As data volumes and modeling requirements continue to expand, this infrastructure fails to meet the needs of OCC Economics. In addition, the current infrastructure will likely pose increasing risks of several types, including unwanted duplication of large data sets and possible substandard conformance with information technology (IT) security requirements.

The Economics Computing Modernization Project

The OCC has initiated ECMP to address emerging requirements that today’s infrastructure environment cannot support. In mid-2009, the OCC initiated the project with OCC Information Technology Services (ITS). OCC’s Business Relations and Project Management Office (PMO) was engaged in the project in December of 2009.

The primary strategic objective of ECMP is to create an infrastructure and associated management systems for OCC Economics computing that will mitigate computing risks, provide a scalable approach to OCC Economics’ rapidly expanding data and application requirements, and support OCC Economics’ mission. Specifically, the project will:

· Identify a highly available, redundant, externally hosted solution that ensures high performance even for mobile users and supports all current applications without unwanted data or hardware redundancy

· Implement a scalable solution to accommodate large and/or unexpected requirements for additional data retention and analysis capacity, as well as additional users and applications

· Utilize a security strategy that ensures that sensitive data is adequately protected and that all data is backed up and retrievable on a pre-defined schedule The scope of ECMP is limited to the technical solution that meets the business objectives described in the ECMP Statement of Objectives (SOO), which can be found in Appendix B of the Request for Proposal (RFP). Improvements or changes to OCC Economics’ business processes not necessitated by the solution are not in scope. Rationalization of the OCC Economics’ tools and data sets is also not in scope, except that the solution may provide OCC Economics with new techniques to manage data and applications.

Assumptions and Constraints In developing these requirements, the following assumptions were made and constraints encountered:

· Proposed solutions must include the hosting of the OCC Economics infrastructure, applications, and data within the continental United States (CONUS) by an external vendor located within CONUS.

· SAS will continue to be the primary technology used by OCC Economics staff to manipulate and analyze data.

· In addition to SAS, the suite of other analytical software products in use throughout the department will continue to be used and must be included in the proposed solution as defined in Appendix A.

· Changes to OCC Economics’ business processes, tools, and data sets are to be minimized and should only result from changes required to support the successful implementation of the technical solution for users.

2 Solution Requirements Overview

This overview provides a high-level context for the requirements in this document. The detailed solution processes referenced herein can be found in the ECMP Solution Use Case Model.

The OCC requires an externally hosted solution to support OCC Economics computing needs. The solution provider will have experience with hosting federal clients, be able to meet the OCC security requirements, and be experienced in providing end-to-end support of a hosted solution (including user support). In addition, the provider will have experience implementing a computing environment for clients conducting analysis against very large data sets using both SAS and non-SAS applications.

Scope

The processes deemed in scope for the ECM solution include:

· Obtaining Data

· Loading Data

· Preparing Data

· Conducting Analysis

· Managing Data

· System Administration

Solution Delivery

The OCC anticipates delivery of the solution in three phases, as detailed in Table 2–1, subsequent to the successful completion of a pilot . Phases 1 and 2 are implementation phases; Phase 3 is an expansion of the implementation completed in Phases 1 and 2 to include all OCC Economics users and data. It should be understood that Phases 2 and 3 incorporate the previous phase’s requirements and functionality. This document defines the requirements for all three phases of delivery. Requirements specific to Phase 2 or 3 are indicated as such.

Table 2–1 Delivery Phases

In this initial phase, users will connect directly to the solution’s infrastructure, which will be a part of the OCC network. Users may also connect from their OCC desktop.

In this phase, the user will establish a connection (via VPN or some other form of connection utility) from their OCC desktop to their virtual desktop that will be part of the solution. This connection supplements the connections established in Phase 1.

Environments

The OCC anticipates the solution will consist of the following five data content environments (hereafter referred to as environments)

· Development

· Staging

· Production

· User

· Collaboration

It is important to note that the OCC does not envision a traditional physical architecture with completely segregated environments. The storage arrays of each environment must be logically separate (i.e. separate logical units [LUN]) however, all other architectural components, such as the computing and networking resources, can be shared. Data analysis will be conducted in all five environments. The following figure is a notional representation of the architecture envisioned for the ECM solution.

Figure 2–1 ECM Notional Environment Architecture

The development, staging, and production environments will be used to promote content through a standard configuration management process. Content in the production environment will be available to all users on a read-only basis and only the OCC System Managers will have full control over the content.

The user environment will be an environment partitioned for individual users. In this environment users will be able to read and execute jobs against production data, but they will only be able to save results into the partitioned user or collaboration environments. Also, in this environment users will be able to manipulate any content they obtain and load themselves into either the user or collaboration environment storage areas.

The OCC requires a shared storage area, herein referred to as the collaboration environment, in which users can share their files and conduct joint analysis. Users will move their files from their personal workspace in the user environment to folders in the collaboration environment established on their behalf by the OCC system manager. These folders will be accessible to multiple users (as determined when the folder is established and amended as necessary) according to the file/folder permissions set by the OCC system manager. This environment is a collaboration space and contains data that is typically associated with narrowly focused projects or still in an early development phase, as contrasted with the production environment which contains data that is stable, has formal production processes, and may be shared more broadly.

In addition, the collaboration environment is the environment from which the user’s files will be retrieved for promotion through the development and staging environments to the production environment, as requested. The users will determine which data in the collaboration environment to retrieve for promotion and will make a request for promotion to the data manager. The data manager will retrieve and promote the content to the development environment. The data manager will then promote it to the staging environment and submit a request to the system manager for promotion to promote it to the production environment . Although described herein as a separate environment, OCC is open to alternate methods of providing this type of work area. The following figure depicts the promotion model envisioned for the ECM solution.

Figure 2–2 ECM Environment Promotion Model

Architecture

The OCC expects that the solution will include both physical and virtual components. The expectation is that all functions and components of the solution that require high input/output (I/O) support, such as SAS, will be physical to the degree necessary to accommodate the I/O requirements described in Section 4. Further, the OCC expects that virtual desktops will be deployed for all solution users. Beyond these two expectations, the OCC is indifferent to the mix of virtual and physical components employed by the solution provider as long as the performance requirements are met.

Users, Roles, and Permissions

At the completion of all three phases, OCC envisions up to 150 users will execute the Obtain Data, Load Data, and Prepare Data processes to populate data into their personal workspace in either the user or collaboration environments. In addition, these users execute the Conduct Analysis processes, which can also result in the creation of data. Their individual data will be stored in either the user environment or the collaboration environment. They may execute analysis against their own data in either of these environments or against data in the production environment on a read-only basis.

In addition, the OCC envisions up to 20 users designated as data managers who will execute the Obtain Data, Load Data, and Prepare Data processes for all production data. This represents the majority of source data that will be housed in the solution. These users will have primary responsibility for promoting content from the development to the staging environment and for retrieving user content from the collaboration environment and promoting it through the development environment to the staging environment.

System administration will be performed by the OCC system manager role (with functions described in the use case models), which will be fulfilled either by an individual or a small group of two to five users. The system manager will have sole responsibility for promoting content from the staging to the production environment. In addition, he will have secondary responsibility for promoting content from the development to the staging environment and for retrieving user content from the collaboration environment and promoting it through the development environment to the staging environment. Alternately, the OCC system manager may simply be the interface to the solution provider who actually manages the solution. This decision will be made at the time of solution implementation and the OCC will welcome input from the solution provider.

Analysis

OCC Economics conducts independent original research, examination of banks’ use of financial models, and policy analysis, some of which may be ad hoc. This type of work generally concludes with the production of research papers, policy papers or recommendations, supervisory findings and presentations. OCC Economics also conducts operational, repeatable analysis that typically results in quarterly reports, data sets used in analysis, and/or models used in analysis; however, unlike most operational reports, these periodic reports are often modified through their lifecycle.

2.1.1 Applications

The primary applications used by OCC Economics are from the SAS product portfolio. In addition, Stata, Matlab, and R are used extensively . The solution will support the SAS portfolio during Phase 1 and all other applications in Phase 2. These applications (except for SAS, which resides on both clients and servers) are currently client-based. They may be run optimally as server-based and the OCC is open to solutions that may increase performance, promote cost effectiveness, and ease maintenance . Some of these applications are available in both Windows and Linux distributions.

2.1.2 Data

Data sets range in size up to 20 terabytes (TB) and most fall into three data families . The solution will store sensitive data including bank examination data and personally identifiable information (PII) and appropriate security and safeguards must be implemented to accommodate it in accordance with OCC security requirements. Additional detail on the amount of data the solution must accommodate can be found in Sections 5 and in Appendix A.

2.1.3 Programs

OCC Economics programs employ all Base SAS procedures. In general, the majority of OCC Economics analytic programs import source data that is recombined with other source data, perform at least one sort on the data, use data step processing, and employ macros to a high degree. Many of the OCC Economics users’ analytic programs are highly sequential and can be optimized for parallel processing to a limited degree. (In such programs, Step B cannot run until Step A has completed because the output of Step A is an input to Step B.) However, to the extent that an individual program can be decomposed and individual components run in parallel to expedite processing, the solution must be capable of doing this for SAS programs. All of these aspects of the OCC Economics analytic programs must be accommodated in the solution.

3 Technical Requirements

Context

This section provides technical requirements for the ECM solution including hosting, environment, architecture, and telecom and network requirements. It also includes requirements in the following hardware and software areas: operating system (OS) , databases, servers, storage, memory, and central processing units (CPU).

Many requirements in this section refer to the performance and capacity requirements in Sections 4 and 5, respectively. The OCC assumes that the technical configuration of any solution will be highly targeted to achieve the capacity and performance expected and therefore has referenced those requirements as appropriate. In several requirements, the OCC refers to the solution provider owning and managing various aspects of the hardware. The OCC anticipates that the solution provider will assume all ownership and responsibility for the items identified.

Requirements

Hosting Requirements SUPL1 The solution shall be hosted off-site and not at OCC.

SUPL2 The location must be within CONUS and must be staffed by United States (U.S.) citizens or lawful permanent residents.

SUPL2.1 The solution provider shall provide staff who meet all OCC on-boarding security requirements.

SUPL3 The solution shall be housed in a Tier-3 or higher facility that provides redundant power and cooling.

SUPL4 The solution provider shall allow remote log-in to all solution interfaces.

SUPL5 The solution provider shall adhere to a certification and accreditation (C&A) process that meets moderate standards of the Federal Information Security Management Act (FISMA) and is based on National Institute of Standards and Technology (NIST) 800.53 R3. The OCC will administer the C&A process and develop the findings.

SUPL5.1 The solution provider shall address all findings to be in compliance with the aforementioned standards within six months of the completion of the C&A process.

SUPL6 The solution provider shall be the sole submitter of invoices to the OCC; the invoices shall include any third-party vendor support.

SUPL7 The solution provider shall ensure that all third-party vendors adhere to the same monthly invoicing periods as the solution provider.

Environment Requirements

SUPL8 The solution shall provide development, staging, production, collaboration, and user environments.

SUPL9 The solution shall provide all hardware and internet connectivity for all required environments.

SUPL10 The solution provider shall be capable of providing all software licenses (including those for the middleware and OS) at the OCC’s discretion.

SUPL11 The solution shall provide a production environment architected to prevent the interruption of processing and loss of data and to ensure failover (as defined in the Recoverability Requirements).

SUPL12 The solution provider shall perform health checks on all environments, including documenting, identifying, designing, and executing the checks.

SUPL13 The solution shall limit access to environments based on user access permissions authorized by OCC system and data managers.

SUPL14 The solution shall allow the system administrator to establish shared directories in the solution environments.

SUPL15 The solution shall provide and co-locate SASWork with the processors and database(s) in all environments.

Architecture Requirements

SUPL16 The solution shall provide an architecture that is dedicated to the OCC to the extent necessary to secure and safeguard sensitive data (e.g., bank examination data), as defined in the Security Requirements.

SUPL17 The solution shall provide an architecture that consists of both virtual and physical components.

SUPL17.1 The solution shall provide an architecture in which the segments of the solution architecture that host computing and storage for I/O intensive programs and processes are physical to the extent necessary to meet the Performance Requirements.

SUPL17.2 The solution shall provide an architecture that provides virtual, remote desktops to all users to enable access to the solution (Phase 2).

Telecom and Network Requirements

SUPL18 The solution provider shall own and manage the solution network and telecommunications from the termination point of the OCC network.

SUPL19 The solution shall provide network connectivity scaled to support the Performance Requirements and Capacity Requirements.

SUPL20 The solution provider shall accept OCC network equipment at the solution site.

SUPL21 The OCC will provide an Active Directory domain controller, including all hardware and software, for system/user authentication. The solution provider shall physically locate the domain server(s) at the solution site. NOTE: The OCC does not have an Identity Management system in front of their Active Directory.

SUPL21.1 The solution shall provide a domain server that will be managed by OCC staff.

SUPL22 The solution provider shall use OCC-provided equipment, adhering to the solution provider’s specifications, to connect to the solution.

SUPL23 The solution shall ensure that all equipment and applications connecting, either physically or logically, to the solution are located on the OCC network.

Operating System Requirements

SUPL24 The solution provider shall own and manage the OSs for all solution components.

SUPL25 The solution shall provide and support the optimal OSs for each segmented area of the solution as required by the OCC applications resident in those segments.

Database Requirements

SUPL26 The solution provider shall own and manage the database(s) associated with all solution-supported applications; the OCC will own the data stored in these databases.

SUPL27 The solution shall provide database(s) scaled to support the Performance Requirements and Capacity Requirements.

SUPL28 The solution shall provide Open Database Connectivity (ODBC) to the solution data for SAS applications and other applications designated by the OCC to be used concurrently with SAS, including—but not limited to— Stata, Tableau, and Matlab.

SUPL29 The solution provider shall employ consistent, effective, and transparent database management as defined further in the Database Management Services.

Server Requirements

SUPL30 The solution provider shall own and manage the application servers and web servers (for SAS Enterprise BI Server and SAS Internet, among others) from the hardware through the OS level.

SUPL31 The solution shall provide server(s) scaled to support the Performance Requirements and Capacity Requirements.

SUPL32 The solution shall allow remote connections to the servers.

SUPL33 The solution shall allow SAS/Connect to connect to the internal SAS servers and SAS servers outside the solution (e.g. Wharton Research Data Services [WRDS]).

Storage Requirements

SUPL34 The solution provider shall own and manage the storage hardware and software.

SUPL35 The solution shall provide storage hardware and software that is compliant with all Data Security Requirements.

SUPL36 The solution shall provide storage scaled to support the Performance Requirements and Capacity Requirements.

SUPL336 The solution shall provide file systems that have hot failover capability to ensure recoverability (e.g., RAID 5, RAID 1, and RAID 10).

SUPL38 The solution shall contain tiered storage for archival of content.

SUPL39 The solution shall attach all storage to the hardware via fiber cabling, switches, and host bus adapter (HBA) cards.

Memory Requirements

SUPL40 The solution provider shall own and manage the solution memory.

SUPL41 The solution shall provide memory scaled to support the Performance Requirements and Capacity Requirements.

SUPL42 The solution shall provide memory compatible with the solution-provided hardware.

CPU Requirements

SUPL43 The solution provider shall own and manage the solution CPUs.

SUPL44 The solution shall provide CPUs scaled to support the Performance Requirements and Capacity Requirements.

SUPL45 The solution shall provide, at minimum, 64-bit processors compatible with the OS.

4 Performance Requirements

Context

Performance requirements define attributes that will enable solution responsiveness under expected usage conditions. The OCC is mainly concerned with: 1) obtaining a cost-effective increase in the speed of processing analytic programs, and 2) maintaining a minimum I/O throughput of 75 megabytes (MB) per second on all processing CPU cores to support the increased processing speeds. The OCC is cognizant that performance and capacity are closely linked, and capacity requirements can be found in Section 5.

Requirements

SUPL47 The solution shall sustain a minimum I/O throughput of 75 MB per second on all processing CPU cores running up to 60 concurrent jobs in all environments even if part of the computing architecture becomes inoperable.

SUPL48 The solution provider will retain all temporary resources, such as temporary files, until an interrupted job completes successfully, in the event that part of the computing architecture becomes inoperable during a job process.

SUPL49 The solution provider shall dynamically allocate environment resources to meet peak demand periods.

SUPL50 The solution provider shall supply a method to assign priorities to computing jobs in the solution.

SUPL51 The solution shall dynamically reallocate resources to give the necessary resources to higher-priority jobs.

SUPL52 The solution shall authenticate solution users located at OCC headquarters within two seconds 95% of the time.

SUPL53 The solution shall execute 95% of all transactions (screen refreshes) within one second, as measured from OCC headquarters.

SUPL54 The solution shall ensure any single transaction does not exceed five seconds, as measured from OCC headquarters.

5 Capacity Requirements

Context

Capacity requirements identify the amount of data that must be stored in the solution, the number of computing sessions that will run in total and concurrently, the number and types of applications that must be supported by the solution, and the number of users that must be able to access the solution. The OCC has compiled a profile for the types of SAS computing sessions to be executed and their associated data and user attributes. This profile can be found in Attachment J.6 – SAS Recommended Architecture of the RFP. Please note: Storage figures are based on the size of currently uncompressed data sets. In the event that the offerors propose an application and/or appliance that will compress data, the amount of storage needed would be reduced by that compression factor.

In addition, this section defines the expectations of the OCC with regard to capacity scalability. The OCC anticipates the ability to scale up capacity as demand increases. The OCC also desires the ability to scale down as demand decreases, to the extent allowable by the solution architecture.

Requirements

Baseline Capacity SUPL55 At implementation, the solution shall provide a minimum storage capacity for Phase 1 equal to:

· 60 TB of data in the collaboration environment

· 27 TB of data in the development environment

· 12 TB of data in the staging environment

· 12 TB of data in the production environment

· 102 TB of data in the user environment

· 73 TB of data in the archive tiers SUPL56 The solution shall provide a minimum of 62 TB of sort space for SAS Work to support the Performance Requirements in Phase 1.

SUPL344 The solution shall provide capacity sufficient to store the virtualized user desktops (Phase 2).

SUPL57 The solution shall provide additional storage capacity for Phase 3 equal to:

· 5 TB of data in the collaboration environment

· 1.7 TB of data in the development environment

· 1.1 TB of data in the staging environment

· 1.1 TB of data in the production environment

· 10 TB of data in the user environment

· 4 TB of data in the archive tiers SUPL58 The solution shall provide an additional 3 TB of sort space for SAS Work to support the Performance Requirements in Phase 3.

SUPL59 The solution shall provide processing capacity sufficient to support the total number of computing sessions for each session type, as defined in Attachment J.6 – SAS Recommended Architecture of the RFP.

SUPL60 The solution shall provide processing capacity sufficient to support the total number of concurrent computing sessions for each session type, as defined in Attachment J.6 – SAS Recommended Architecture of the RFP.

SUPL61 The solution shall provide processing capacity sufficient to support the total number of users for each session type, as defined in Attachment J.6 – SAS Recommended Architecture of the RFP.

SUPL62 The solution shall be capable of simultaneously processing multiple user jobs submitted via batch, via the virtual user desktop, via remote submit through SAS/Connect, and via a direct submit through a terminal-server remote connection to the server console.

SUPL63 The solution shall provide adequate temporary storage for all processes requiring such storage, as defined further in the Data Management Requirements.

SUPL64 The solution shall support a minimum of 12,000 files referenced (i.e., opened) by a single program.

SUPL65 The solution shall support all required desktop applications on the virtual desktops (Phase 2).

SUPL66 The servers shall support designated server applications, including web server requirements as necessary, as defined in the Tool Classification Scheme.

SUPL67 The solution shall support disaster recovery storage adequate to retrieve 1.2 TB of important data within 1 week with the remaining data categorized as normal data within 1 month.

SUPL68 The solution shall deliver adequate audit record storage capacity to support the Audit and Accountability Requirements.

SUPL69 In the event audit storage capacity reaches 75%, the solution shall send a notification to the OCC system manager.

SUPL70 In the event of audit storage capacity being reached or exceeded, the solution shall first make a backup of the existing logs and then overwrite the oldest audit logs.

Capacity Scalability

SUPL71 The solution architecture must be scalable to seamlessly increase storage and processing capacity in all environments for increased performance and redundancy.

SUPL71.1 The solution shall provide for the annual growth of Phase 1 data equal to:

10% of the data in the collaboration environment

10% of the data in the user environment

10% of the data in the archive tiers

8 TB of data in the development environment

4 TB of data in the staging environment

4 TB of data in the production environment SUPL71.2 The solution shall provide for the annual growth of Phase 3 data equal to:

10% of the data in the collaboration environment

10% of the data in the user environment

10% of the data in the archive tiers

0.5 TB of data in the development environment

0.3 TB of data in the staging environment

0.3 TB of data in the production environment

SUPL71.3 The solution shall provide for annual growth of SAS Work space of 30%.

SUPL72 The solution architecture must be scalable, to the extent feasible based on the solution architecture, to seamlessly decrease storage and processing capacity in all environments.

SUPL73 The solution architecture must be scalable to seamlessly allow the addition of software to all environments.

SUPL74 The solution architecture must be scalable to seamlessly allow the removal of unused software from all environments.

SUPL75 The solution architecture must be scalable to seamlessly allow the addition of users to all environments.

SUPL76 The solution architecture must be scalable, to the extent feasible based on the solution architecture, to seamlessly allow the removal of users from all environments.

SUPL77 The solution architecture must be scalable to seamlessly allow the addition of data to all environments.

SUPL78 The solution architecture must be scalable to seamlessly allow the removal of unused data from all environments.

SUPL79 The solution architecture must be scalable to seamlessly increase networking capacity to support the Performance Requirements.

SUPL80 The solution architecture must be scalable, to the extent feasible based on the solution architecture, to seamlessly decrease unused networking capacity.

SUPL81 The solution architecture must be scalable to seamlessly allow additional storage to be added to the archive tiers defined in the Archival and Retrieval Requirements.

6 Solution Availability Requirements

Context

Solution availability requirements identify when all or part of the solution and associated applications must be available for use. Required solution availability is also used in determining when maintenance may be performed. This section specifically defines the OCC’s “up time” expectations as opposed to the recoverability requirements in Section 7, which define the data recovery and disaster recovery expectations of the OCC.

Requirements

SUPL82 The solution provider shall ensure the production, collaboration, and user environments, and their supporting infrastructure, are available to all authorized users 24 hours a day, seven days a week.

SUPL83 The solution provider shall ensure that applications deemed critical (Tier 1) in the Tool Classification Scheme are available 24 hours a day, seven days a week.

SUPL84 The solution provider shall ensure that the production, collaboration, and user environments, and their supporting infrastructure, are maintained such that portions of the infrastructure can be taken down for upgrades or maintenance without affecting overall availability.

SUPL85 The solution provider shall provide a total production, collaboration, and user environment/infrastructure uptime percentage of 99%.

SUPL86 The solution provider shall ensure that the development and staging environments, and their supporting infrastructure, are available to all authorized users 24 hours a day, seven days a week excluding scheduled maintenance periods.

SUPL87 The solution provider shall ensure that all applications deemed non-critical (Tier 2) in the Tool Classification Scheme shall be available 24 hours a day, seven days a week excluding scheduled maintenance periods that shall be limited to no more than four continuous hours and shall not occur on weekdays.

SUPL88 The solution provider shall request approval from the OCC for all unscheduled maintenance periods 10 business days prior to the anticipated disruption.

SUPL89 The solution shall automatically notify the OCC system manager of any unexpected solution outage. The notification shall include the following information:

· Environment name

· Date and time of outage

· Error code

· Error description

· Names of processes running at time of outage SUPL89.1 The solution provider shall notify the OCC system manager of the root cause of any outage as soon as it determined and of the associated action plan no later than 24 hours after the outage.

SUPL90 The solution shall ensure infrastructure availability that meets all Solution Availability Requirements and service level agreements (SLAs) without regard to resource competition, electrical outages, or solution maintenance.

7 Recoverability Requirements

Context

Recoverability requirements support the ad hoc recovery of content lost through user error, solution readiness and recovery in the event of a solution emergency or a declared disaster, and the movement of OCC content to another provider or location, as necessary.

Requirements

Ad Hoc Recovery Requirements SUPL92 The solution shall provide weekly full backups and daily differential backups of all hosted servers (OS through application layer excluding SAS Work and the Staging environment) and maintain backups that can be accessed in accordance with the relevant SLA for a minimum of six months.

SUPL92.1 The solution shall backup the OS software, all other software, and all data.

SUPL92.2 The solution provider shall deliver to the OCC the output of the most recent full weekly backup, written to tape, on the first business days of January and July.

SUPL92.2.1 The solution provider shall provide any necessary encryption keys to the OCC for use in accessing the data on tape.

SUPL92.2.2 The solution provider shall provide any necessary specifics regarding the media and format of the tapes to the OCC as well as any hardware specifications needed to access the data on tape.

Disaster Recovery Requirements

SUPL93 The solution shall include at least one other Tier-3 or higher hosting facility located in a different CONUS geographic area from the primary facility to provide a redundant disaster recovery.

SUPL94 The solution shall failover and recover all applications, OS software, and data identified as important within 1 week to the designated location in the event of a disaster; the recovery time objective (RTO) for all applications, OS software, and important data is one week. The recovery point objective (RPO) for this category is a maximum of 24 hours (the time since the last full or differential back-up took place).

SUPL339 The solution shall failover and recover all data identified as normal within 1 month; the RTO for normal data is one month. The RPO for this category is a maximum of 24 hours (the time since the last full or differential back-up took place).

SUPL340 The solution shall provide the ability to identify data as important or normal through the metadata model.

SUPL96 The solution shall use encrypted media for all failover activities involving data transfer.

SUPL97 The solution shall provide the same level of network and solution performance from the OCC to the failover location as to the primary location.

SUPL98 The solution shall provide internal database controls to ensure the following activities occur in the event of a solution failure:

· Roll back incomplete transactions

· Restore the solution to its last consistent state before the failure occurred

· Reapply all incomplete transactions previously submitted by the user

· Validate internal database consistency to ensure no duplicate transactions

· Report any data or transactions that failed to process completely SUPL99 The solution shall segment jobs to facilitate restart at the point of failure in the event of a failure.

SUPL100 The disaster recovery plan for the solution shall fully address each contingency consideration described in NIST SP 800-34.

Transferability Requirements

SUPL101 The solution provider shall support the secure transfer and preservation of the OCC’s data and applications to a different geographic location or a different solution provider’s infrastructure, if requested.

8 Security Requirements

Context

This section provides the security requirements for the ECM solution. These requirements are subject to modification based on factors such as changes to Federal laws/regulations or OCC security requirements. All referenced documents are publicly available and will be provided by the OCC, as requested. There are currently no Cyberscope requirements for the solution. If, however, it is determined that service providers which provide solutions that include OCC systems (e.g. federal government systems) must comply with these requirements, then Cyberscope compliance reporting will be applicable.

Requirements

SUPL102 The solution shall deliver integrated security functionality that is compliant with the Use Clause No. 1052.245-8008, Information Security Requirements for Unclassified OCC information Technology Resources (March 2010).

SUPL103 The solution shall provide the ability to deactivate existing users without losing any historical solution information associated with the user.

SUPL104 The solution shall provide the ability to re-activate a previously deactivated user without losing any historical solution information associated with the user.

SUPL105 The solution shall isolate security functionality from non-security functionality.

SUPL106 The solution shall interact with the OCC’s instance of Microsoft Active Directory to determine user authorization.

SUPL107 The solution shall provide a single sign-on mechanism to provide seamless application access upon validating the user credentials, unless not technically feasible.

SUPL108 The solution shall deliver role-based access control implemented through group access rights.

SUPL109 The solution shall temporarily lock a user account after three consecutive failed login attempts.

SUPL111 The solution shall provide real-time, online security monitoring and reporting as defined in the Solution Monitoring and Notification Services requirements.

SUPL112 The solution shall ensure that all components that comprise the OCC environment are configured and maintained only by appropriately authorized, OCC-credentialed personnel.

SUPL113 The solution shall control physical access to the solution provider’s server room that contains routers, firewalls, web-servers, database servers, and application servers supporting the ECM solution. All spaces used to support the ECM solution, including office spaces in the building, shall be under lock and key during non-business hours. The solution shall log all physical access to the solution and provide logs upon request.

SUPL113.1 The solution shall control access to the building with security services commensurate with the facilities' designation as a Tier-3 or higher facility.

9 Operations Requirements

Context

This section contains operational requirements for the ECM solution. The ECM solution must be designed to support efficient operations and the analytic, system administration, and reporting operations required. Detailed information on the operations performed by OCC Economics can be found in the ECMP Solution Use Case Model.

Requirements

Analytic Operations Requirements

SUPL114 The solution shall provide the ability for an authorized user to initiate an analysis activity through a system command.

SUPL115 The solution shall provide the ability to conduct analysis in all environments.

SUPL116 The solution shall provide the ability to conduct analysis against any data selected, subject to access rights.

SUPL117 The solution shall provide the ability to connect to external databases while conducting analysis (e.g. SAS Connect).

SUPL118 The solution shall provide for concurrent access to data sets by multiple users.

SUPL119 The solution shall save interim analytical output in the selected environment.

SUPL120 The solution shall provide the ability to identify analytical output as final.

SUPL120.1 The solution shall require user-defined metadata be applied to all analytical output identified as final, as defined in the solution’s metadata model SUPL120.2 The solution shall save analytical output designated as final in the selected environment.

SUPL121 The solution shall provide a method to identify analytical output that must be deleted and sanitized, as per the Data Security Requirements.

SUPL121.1 The solution shall delete and sanitize from the selected environment any analytical output that has been identified for deletion.

Solution’s System Administration Operations Requirements

SUPL122 The solution shall provide the ability to create new user accounts.

SUPL123 The solution shall require the appropriate metadata for each account based on the metadata model.

SUPL124 The solution shall assign a unique identification (ID) to each individual with a user account.

SUPL125 The solution shall provide the ability to define user groups.

SUPL126 The solution shall provide the ability to update, add, or delete privileges associated with user groups.

SUPL127 The solution shall provide the ability to assign access rights to solution functions, data, and reports to a user group(s).

SUPL127.1 The solution shall provide the ability to control access to solution functions based on assigned user group(s).

SUPL127.2 The solution shall provide the ability to control access to data based on assigned user group(s).

SUPL127.3 The solution shall provide the ability to control access to reports based on assigned user group(s).

SUPL128 The solution shall provide the ability to assign access rights to solution functions, data, and reports to individuals.

SUPL128.1 The solution shall provide the ability…