Revised_RFP-000002_with_Track_Changes.pdf

EDGAR Redesign (ERD) Requirements Gathering RFP

Page 3 of 67 RFP: SECHQ1-16-R-0017

Section A - See SF 1449

Section B - Supplies or Services and Price/Cost

B.1 Contract Line Item/Price Structure The period of performance for this contract shall not exceed 30 months from the date of award. The 30 months includes 18 months to fulfill the non-optional requirements of the contract and 2 additional optional periods, each 6 months in duration for Acquisition Support. However, it is important that the main deliverable of this contract, the Functional Requirements Document (FRD), be of high quality and be complete so that it can be used as the foundation document to support a competitive process to identify the best solution approach, design and implementation of a new electronic disclosure solution environment to replace the existing EDGAR system. The Contractor is encouraged to develop a reasonable schedule that can deliver a high quality and a complete FRD sooner than 18 months if the quality and completeness are not compromised.

CLIN Description CLIN Type

Total CLIN Price

0001 Functional Requirements Gathering (18 months)

POP: 10/01/2016 – 3/31/2018

FFP $

0002 Additional Expertise and Support Not Needed on a Fixed Basis

POP: 10/01/2016 – 3/31/2018

LH $

0003 Option: Acquisition Support (6 months)

POP: 04/01/2018 – 09/30/2018

FFP $

0004 Additional Expertise and Support Not Needed on a Fixed Basis

POP: 04/01/2018 – 09/30/2018

LH $

0005 Option: Acquisition Support (6 months)

POP: 10/01/2018 – 03/31/2019

FFP $

0006 Additional Expertise and Support Not Needed on a Fixed Basis

POP: 10/01/2018 – 03/31/2019

LH $

Page 4 of 6768 RFP: SECHQ1-16-R-0017-000002

Section C - Statement of Work

C.1 Introduction The Electronic Data Gathering, Analysis, and Retrieval (EDGAR) system at the heart of the SEC has served the agency and investors admirably over the years, however as the SEC regulatory regime has grown in response to changing market realities and associated Congressionally required new rules such as those arising from the Dodd-Frank Wall Street Reform and Consumer Protection Act, the existing system has become overly complex, expensive to operate, and more difficult to efficiently evolve. As a result, the SEC has started a multiphase EDGAR Redesign (ERD) Program to deliver a new electronic disclosure solution.

The ERD Program began by canvassing specific SEC stakeholders, namely the specific Divisions and Offices who interact with EDGAR, to create a shared view within the SEC of what the ERD Program is, on what and where it should focus, and what the final deliverable should be. This initial phase is complete and thus this contract will begin the second phase of the Program, focusing on the development and delivery of comprehensive functional and non-functional requirements for a new electronic disclosure solution which will replace EDGAR.

The purpose of the ERD Program is not merely to give EDGAR a technology refresh. It is meant to address: how form filings are created and submitted; the evolving needs of the SEC, investors, and markets’ access to form filing disclosures; and all of the information and data directly and indirectly associated with these requirements. These disclosures are an essential element of the SEC’s mission to protect investors, maintain fair, orderly and efficient markets, and facilitate capital formation.

The primary objective of this contract is to define the detailed comprehensive functional and non-functional requirements necessary to build the new electronic disclosure solution. The SEC requires gathering and analysis of functional and non-functional requirements with enough specificity to be the basis for a future competitive process where vendors will propose how they would deliver against the functional and non-functional requirements developed, create the associated design, and the ultimate implementation approach. As the final deliverable of this contract, the detailed comprehensive functional and non-functional requirements shall address all facets of the new electronic disclosure solution to include: business functions, capabilities, processes, technology, and architecture.

The SEC anticipates a subsequent competitive acquisition for designing, developing, transitioning, and integrating the new electronic disclosure solution as the anticipated next step in its ERD Program. The cornerstone of that acquisition will be the functional and non-functional requirements, principles, build criteria, constraints, analysis, etc. that are the output from this contract.

C.2 Background

C.2.1 The Electronic Data Gathering, Analysis, and Retrieval (EDGAR) System The SEC was created by the Securities Exchange Act of 1934 as an independent regulatory agency. The SEC administers statutes that protect the investing public by providing full disclosure of required SEC filings, regulating the nation’s securities markets, and policing and preventing fraud and manipulation in the securities and financial markets. A primary means of sustaining a fair and open market is to ensure full disclosure of corporate-related information.

With the increasing complexity and volume of filings under Federal securities laws in the 1970s and 1980’s, the SEC determined that the existing paper filing system was inadequate to meet the objectives of the full disclosure program. To address the problem, the SEC initiated a pilot program in 1984 to investigate the feasibility of filing corporate information electronically. Based on the success of the pilot program, the EDGAR system was initiated as the Electronic Disclosure platform for the SEC. Congress

Page 5 of 6768 RFP: SECHQ1-16-R-0017-000002 authorized the development and implementation of an operational EDGAR system in 1987. The goals of EDGAR included: facilitating efficient filings, providing support for one-stop filing, enhancing the timeliness and availability of filings to the public, and increasing the effectiveness of SEC personnel in performing their review and auditing functions. The EDGAR system became operational in 1992 and now supports the following major functions of the electronic filing life cycle:

1) Submission of the file (header and document(s)) by filers to the SEC;

2) Receipt and acceptance of the file (header and document(s)) by the SEC;

3) Data validation, business validation, parsing/shredding (non-destructive), etc.;

4) Data/Document storage and retrieval;

5) Data dissemination worldwide and form filing access to the public;

6) Analysis and review capabilities by SEC staff;

7) On-line filer assistance and support; and

8) Coordinated and effective SEC/Filer interactions.

Designed as a stand-alone system to include all hardware, applications, and systems software, EDGAR has now been in existence for over thirty (30) years. With the exception of the addition of new hardware and software and a significant amount of new functionality, the current version of EDGAR has been in existence since 2001. Over the last 8 – 10 years, the number of filings made on EDGAR has tripled, submission size has more than doubled, and total data received has quadrupled. To keep up with the ever-changing environment EDGAR resides in, Contractor support services are currently being used to develop new functionality, operate and monitor the system, and maintain the hardware and software integral to

EDGAR.

C.2.1.1 EDGAR’s Ancillary Systems To provide additional value and benefit to the SEC and its stakeholders, EDGAR interfaces with many other external systems as well. These systems include, but are not limited to:

1) BDRA – Broker Dealers Risk Assessment

2) PFRD – Private Fund Reporting Depository

3) IARD – Investment Advisors Regulatory Depository

4) IAPD – Investment Advisor Public Disclosure

5) SRTS – SRO Rule Tracking System

6) EFFS – Electronic Form Filing System

7) PDS – Public Dissemination Service

8) EM – EDGAR Momentum

C.2.2 Understanding the EDGAR Redesign Context Over time, new capabilities, functionalities, processes, rules, and regulations have been added to the EDGAR system. These facets are all tightly coupled within a monolithic architecture. This architectural model struggles to support the efficient and effective change and evolution of the system as well as its many capabilities.

The ERD Program seeks to address the architectural limitations of EDGAR by creating a solution environment which identifies the functions that based on technical and/or performance reasons should be tightly coupled to each other as the “core”, as well as other capabilities/functions essential to a robust electronic disclosure environment, which are candidates for being loosely coupled to the core. The value of this architectural goal is to enable an environment which can support the ongoing and parallel evolution of solutions, capabilities and functions, as well as an ongoing business ownership and governance approach better aligned to the major users of various elements of the solution environment.

This approach will facilitate ongoing capability evolution by providing greater capacity and flexibility for the releases associated with the “core” of the new environment insulating and isolating loosely-coupled

Page 6 of 6768 RFP: SECHQ1-16-R-0017-000002 components from the core. In doing so, the solution will be vital and effectively serve its many stakeholders for at least another thirty (30) years.

EDGAR has had numerous “modernizations” since its inception including introducing the ability to process highly structured data (e.g. XML/XBRL). The ERD Program seeks to define and implement a new electronic disclosure solution which will simplify how changes to the core can be implemented with an eye toward reducing complexity and time to delivery. ERD provides the opportunity to identify additional methods for supporting form filing analysis and reviews, as well as assess the processes and tools used to ingest, store, disseminate the information, and data associated with form filings more effectively, while minimizing human intervention, and increasing the value of form filings to investors and the markets.

The SEC seeks to reduce the burdens of the disclosure regime through rule and regulatory reviews through the delivery of a new electronic disclosure solution. The ERD Program itself seeks to address these burdens by providing solutions which will address the creation and electronic submission processes associated with form filings. Further, ERD seeks to identify and implement solutions and processes, which will benefit all stakeholder groups through reducing complexities associated with present form filing processes, increasing the value and usability of the form filings, as well as making the information and data associated with the form filings easier to find, print, search, and analyze.

C.2.3 Program Governance, Structure, and Approach The ERD Program is a major strategic initiative of the SEC and as such, has broad agency interest as well as across Division/Office stakeholders. As a result, the success of this program requires mechanisms for the ongoing involvement, buy-in, and oversight of the program by the internal stakeholders. To facilitate this, the ERD Governance Board (the Board) has been established and is comprised of senior managers from across the agency. The Board will provide ongoing periodic oversight, review, and input on the progress of the program. The Board is critical in reinforcing that ERD is an SEC-wide program.

The Contractor’s access to individual SEC SMEs is essential to its successful development of robust and detailed functional and non-functional requirements. While the Contractor will meet with individual SMEs and/or conduct small ad-hoc meetings with groups of SMEs, the SEC has also established a “Working Group” (WG) construct to provide the Contractor with a formal tool for bringing together a group of SMEs to discuss a specific topic over several meetings. The WG, therefore, is a tool for enabling the Contractor to establish sustained interactions on topics with the same group of SMEs from across the SEC. All proposals to convene WGs require approval by the Board in order for the SEC to ensure SME workload balance.

Page 7 of 6768 RFP: SECHQ1-16-R-0017-000002

C.2.3.1 ERD Governance Structure A governance structure for the ERD program has been established and is depicted in Figure C-1 below.

FIGURE C-1. ERD GOVERNANCE STRUCTURE.

C.2.3.1.1ERD1 ERD Governance Oversight Board The ERD Governance Oversight Board is comprised of Senior Officers from each of the stakeholder Divisions and Offices discussed in Section C.2.4.1. The Board is an essential function to ensure broad support for the program and to ensure that internal SEC SMEs are available to support the program. The major functions of the Board include:

1) Reviewing, and formally accepting, the Monthly Board Package, which is minimally comprised of:

a) Minutes from the previous meeting;

b) Monthly Status Report Board Presentation; and,

c) Presentations (as applicable), which include:

i) A rolling 3-month view of the activities that may require specific input or time from SEC SMEs;

ii) An overarching plan and schedule for the calling of the WGs so that the Board can understand, identify, allocate, and ensure that the associated specific resources (e.g.

SMEs) required to keep the plan on schedule are made available;

iii) A review of the calling of specific WGs, to include:

(1) The Topic(s) of the WG;

(2) The skills/SMEs required to support the WG;

(3) Expected outcomes/deliverables of the WG; and,

(4) The expected timeframe & time-demand of the WG.

iv) All WG outputs/deliverables (as applicable).

v) Other COR requested presentations.

While it is important for the contractor to understand this governance model, the contractor will report to and take direction from the ERD Program Manager/COR in concert with the Director of

Governance Board

ERD

Program Office

Working Group 1 Working Group 2 Working Group 3 Working Group n

Page 8 of 6768 RFP: SECHQ1-16-R-0017-000002

OSI. Actual interactions with the Board will only be on specific request of the COR. The contractor will, however, be essential in producing many of the presentations for Board meetings.

C.2.3.1.2 ERD Program Office (PO) The ERD Program Office is contained within the Office of Strategic Initiatives (OSI) which, at minimum, includes the Director of OSI, the Program Officer/COR, and the Technical Program Manager. The role of the ERD PO is to manage the ERD Program, and its associated contracts.

C.2.3.1.3 ERD Working Groups (WG) The ERD Program has defined Working Groups as a structure for addressing specific aspects of the new electronic disclosure solution. WGs are the vehicle for establishing an interaction with SEC SMEs on various topics where more than one meeting is required to flesh out the topic(s). WGs were set up to facilitate the formation of functional and non-functional requirements, and the discussions that lead to them The SEC anticipates that approximately 25 working groups will be needed to assist the Contractor in developing the functional and non-functional requirements for the future Electronic Disclosure system at the SEC. However, the Working Group construct is merely a tool to access multiple SEC SMEs at once, and the Contractor’s requirements gathering methodology and past experience with developing requirements for similar systems may be a better indicator of how many working groups will be needed.

WGs will be a critical method for ensuring the progress of specific functional and non-functional requirements essential to the final deliverable.

C.2.4 ERD Stakeholders The ERD Program has numerous internal and external stakeholders that it serves and is committed to ensuring the needs of all stakeholders are considered and addressed in the new electronic disclosure solution. Sections C.2.4.1 and C.2.4.2 should be considered to be representative, but not all inclusive, of ERD stakeholders.

C.2.4.1 Internal ERD Stakeholders A key element for achieving Program success is the ongoing involvement and oversight of the SEC Divisions/Offices in every aspect of this Program. Core internal stakeholders include Corporation Finance (CF), Investment Management (IM), Trading and Markets (TM), and Office of Financial Management (OFM). Examples of other internal stakeholders that are not direct users of EDGAR include the Division of Economic Risk and Analysis (DERA), the Division of Enforcement (ENF), the Office of Compliance Inspections and Examinations (OCIE), and the Office of Public Affairs (OPA).

C.2.4.12 External ERD Stakeholders The ERD Program, like EDGAR, has numerous external stakeholders whose interests it must consider.

These include, but are not limited to:

1) Investors;

2) Markets – (through the data and information provided to Public Dissemination Service);

3) Nationally Recognized Statistical Rating Organizations; and

4) The Form Filers:

a) Individual Filers;

b) Company Filers;

c) Filer Agents;

d) Transfer Agents; and

e) Training Agents.

C.3 Objectives

C.3.1 Targeted Enhancements

Page 9 of 6768 RFP: SECHQ1-16-R-0017-000002

The SEC requires the Contractor to assist in addressing the limitations of EDGAR and to identify the functional and non-functional requirements for delivering new capabilities/solutions and processes for the benefit of its’ numerous stakeholders. Some examples of topics/areas to be addressed include:

1) The functionalities, capabilities, and processes for assigning and managing appropriate access rights and controls, where appropriate, to the new electronic disclosure environment required for filing with the SEC as an individual, or as part of a company;

2) Establishing a methodology and approach for assigning, revoking, and managing internal SEC access to the new electronic disclosure environment that reduces complexity, increases manageability, and supports auditability and control;

3) Creating specific entity landing pages, for various filer types, as the point of entry for form filers and the locus for providing and updating important specified form filer information. These filer pages would provide an “investor side” methodology for exposing company or individual filer information not deemed confidential, as well as facilitating how investors might gain access to the specific company or individual filings, exhibits, and other information.

i) Appropriate Entity Information;

ii) Entity and Filing Meta Data;

iii) Previous Filings, attachments, exhibits, and associated functionality;

iv) Filing status for in-process filings, dates for their next regulatory filing deadline; and

v) A specific place for filer/SEC communications and tracking of such things as:

(1) SEC comment letters; and

(2) SEC/Filer responses.

4) Accommodating novice, intermediate, and expert filers by way of specific tools/wizards for determining which form filings should be filed, application(s) for creating form filings, the creation of naming conventions for form filings that are more descriptive, etc.;

5) Creating improved tools and processes for efficient and effective submission and acceptance of form filings to include validation, quality assessment, parsing/shredding (non-destructive), and storing the structured, semi-structured, and non-structured information and data associated with a form filing;

6) Rationalizing and optimizing how form filings may be electronically submitted to maximize their value and usability to the various stakeholders and minimize overall complexity;

7) Defining data and document repositories essential to maximizing the value of structured data for downstream external analysis and analytics, the tagging of (key) narrative sections of form filings identified as sections associated with material disclosures, and the ability to compare new form filings with previous submissions;

8) Creating the ability to compare new form filings with previous submissions;

9) Creating the ability to provide investors and SEC personnel with various views of a form filing optimized to their purpose and able to support inflight analysis;

10) Creating the ability to gain access to the new electronic disclosure solution to create, submit, review, update, print, route, download, or query, a form filing regardless of the web browser and/or operating system used;

11) Creating the ability to establish effective methods for SEC/Filer interactions to support filer questions/help, notifications for when form filings have been received, formal SEC comment alerts directed to specific form filers concerning a filing as well the responses back to the SEC, and the capture, storing and exposure of associated SEC/Filer interactions;

12) Creating the ability to more effectively capture information/data about form filers (company or individual), when they file, and what they file, etc.;

13) Establishing effective and manageable dynamic data dictionaries which evolve alongside the new electronic disclosure solution for internal data repositories to support ongoing value and use of all data captured in the new electronic disclosure solution;

Page 10 of 6768 RFP: SECHQ1-16-R-0017-000002

14) Establishing effective and manageable data repositories within the environment designed to support ongoing changes associated with evolving SEC organizational structures, rule changes, new form filings or filer types, etc.;

15) Establishing effective solutions, APIs, and data feed protocols for the dissemination of data outside of the environment to support SEC analytic uses as well as to feed the public dissemination platform; and

16) Establishing overarching capabilities for the effective, efficient capture and reporting of data concerning the performance, issues, capacities and health of the new environment.

C.3.2 Major Thematic Objectives The SEC ultimately wants the ERD Program to achieve much more than the following objectives.

However, these objectives provide the Contractor with thematic areas of focus that should be kept in mind as they create the comprehensive functional and non-functional requirements for a new electronic disclosure environment to replace EDGAR:

1) Maximize information/data usability – improved use of automation to capture, make available, digest, use, and enhance the discovery of more data than is currently possible;

a) Establish information and data repositories which maximize data/information availability, use, controls, security, auditability, reporting, and ongoing management.

2) Minimize complexity – Simplify the solution and associated capabilities and processes;

a) Reduce environmental complexity and the associated cost of maintaining and evolving the new electronic disclosure environment;

b) Deliver an architecture that enables a distributed solution and loose coupling of capabilities and functionalities; and

c) Make use of COTS solutions where applicable and supportable to increase functional vitality and promote efficient evolution.

3) Simplify additions, or changes – providing a technical and software architecture that can increase greater flexibility and efficiency in delivering ongoing changes (e.g. new or altered rules or functional capabilities):

a) Increase the ease of modifying and delivering new functions and capabilities via loose coupling;

b) Enable more frequent and less complex release schedules for the solution core as well as the associated capabilities; and

c) Establish effective processes to support the environment and its capabilities, functions, and processes.

4) Enable Richer Analytics – benefits derived from ingesting more structured data to enable off-environment analytics of data regarding filers, filings, entities, etc.;

a) Establish effective and controlled protocols and methodologies for data dissemination to support off-solution analysis, analytics, and feeds to third-party market distributors.

5) Identify streamlined process of creating and submitting form filings – essential downstream benefits to investors, markets, and SEC staff responsible for reviewing form filing submissions:

a) A significant constraint of this objective is the reality that this program cannot depend on significant changes to the existing SEC rule regime as a basis for delivering benefits to the program stakeholders. Right-size the solution core to eliminate valueless SEC and filer burden.

C.3.3 Final Deliverable – Detailed Comprehensive Functional Requirements Document (FRD) The primary objective of this contract is to define the detailed comprehensive set of functional and non-functional requirements necessary to deliver the new electronic disclosure solution. These functional and non-functional requirements will be the basis for a subsequent contract, which will determine future proposed solution approaches and subsequent associated designs to fulfill these requirements and build the future environment.

Page 11 of 6768 RFP: SECHQ1-16-R-0017-000002

Within this SOW the definition of “functional and non-functional requirements” is critical. The following definitions are meant to provide clarity and guidance in what is being sought as the output for this contract.

For purposes of this contract, “functional requirements” means a thorough and precise articulation of all of the capabilities, functions, components and associated processes required to effectively describe a comprehensive system. This includes not merely describing the incremental facets of an environment, but also how all of the capabilities, functions and components fit together into a systemic environment.

Non-functional requirements are characteristics, attributes, or constraints of a system. Non-functional requirements can be divided into two main categories:

• Execution attributes, such as security, recoverability and usability; and

• Evolution attributes, such as testability, maintainability, flexibility, extensibility and scalability, which are embodied in the structure of the system.

The ultimate goal of this contract and FRD is to document requirements in enough detail so that the future Offerors can propose viable solutions and designs as part of a competitive procurement, and is NOT to deliver requirements for buildable components that can be assigned to a team of developers to start coding.

Meeting the goals and objectives of the ERD Program requires a detailed understanding of the functional role of an electronic disclosure environment, which can only be achieved through an in-depth understanding of how EDGAR serves its various stakeholders today. To ensure a detailed level of understanding of EDGAR, as background for the creation of a new electronic disclosure environment, the SEC will make available detailed EDGAR documentation to the Contractor. The ERD Program requires the development of functional and non-functional requirements which express a full rethinking of the electronic disclosure environment in light of new and emerging technologies, architectural options, capabilities, stakeholder needs, and ongoing significant changes in the markets.

The FRD is further discussed in Section C.4.2.1.4.

C.4 Task Requirements

C.4.1 Program Management The Contractor shall provide the following program management support activities for its work on this contract:

1) Schedule Management;

2) Risk and Issue Management;

3) Program documentation creation and management; and

4) Resource Management.

The Contractor shall plan, monitor, and coordinate across WGs and non-WG activities. The Contractor shall also be responsible for the control and management of the program and its resources, including program scope, costs, and timelines for the delivery of the detailed comprehensive functional and non-functional requirements. The Contractor’s program management responsibilities shall include all activities necessary to ensure the accomplishment of timely and cost effective performance in accordance with standards of quality that equal or exceed the requirements contained in this Statement of Work.

At a minimum, The Contractor’s approach to program management shall include:

Page 12 of 6768 RFP: SECHQ1-16-R-0017-000002

1) A trained, experienced PM staff focused on ensuring adequate resources with appropriates skills and adherence to schedules and communicating effectively amongst its tasks and with clients, customers, and staff;

2) A trained, technically-proven staff, current in the systems, technologies, and services employed by the SEC;

3) A high degree of awareness of advances in information technology having potential impact on electronic disclosure computing environments as well as the impact and advantages of such advances in information technology;

4) An effective program for problem identification, assessment, escalation to the COR, mitigation, and resolution to ensure that positive and timely actions, at all levels of the Contractor’s organization, occur to address known and anticipated problems;

5) An effective program for risk identification, assessment, escalation to the COR, mitigation, and resolution to ensure that positive and timely actions, at all levels of the Contractor’s organization, occur to address known and anticipated risks;

6) An effective program for timely, flexible response to SEC needs;

7) An effective program for communicating and coordinating amongst all of the tasks in this contract to ensure decisions made in one area are coordinated throughout;

8) A feedback process to monitor, assess, and act upon those aspects of contract performance requiring corrective action or redirection or otherwise needing attention ;

9) Planning and coordination of all contract activities;

10) A plan and schedule of personnel, and budgetary resources with notification to the SEC COR on a regular basis of any personnel and budgetary variances; and

11) A quality management program that:

a) Adheres to a formal process for senior level review for all artifacts;

b) Provides for quality management of overall contract performance, including relationships with subcontractors and vendors, and all other contractual obligations;

c) Monitors the performance of work and reports problems, issues, risks immediately to the SEC

COR;

d) Coordinates the performance of work amongst the tasks of the contract and prevents duplication and idleness;

e) Establishes and maintains clear and effective procedures to ensure the quality of the products delivered to the SEC;

f) Ensures delivery of all products in accordance with the requirements of this Statement of

Work and individual Task Orders; and

g) Includes resource-loaded schedules reporting progress against base-lined schedules and risk mitigation.

C.4.1.1 Organization and Responsibilities The Contractor shall establish and maintain a program management organization that manages, supervises, and oversees the activities of all Contractor personnel. The Contractor shall establish a program management organization in accordance with the intended allocation of work, technical approach, reporting requirements, and management practices. The Contractor shall appoint a Program Manager (PM) who will be responsible for the Contractor’s performance on all tasks. The PM shall be the primary interface between the COR and the PM’s corporate management on all matters relating to the program. The PM is a key person on this contract.

C.4.1.2 Program Support The Contractor shall, as directed by the COR, schedule, participate, and/or facilitate all SME interviews, WGs, and meetings designed to collect information in order to review, analyze, and document the functional and non-functional requirements of capabilities, functionalities and associated processes.

Page 13 of 6768 RFP: SECHQ1-16-R-0017-000002

The Contractor is responsible for the creation of schedules, agendas, action item lists, and meeting minutes in support of all meetings between the Contractor and SEC personnel.

C.4.1.3 Business and Technical Writing Support The Contractor shall create business and technical documents, minutes, reports, presentations, functional and non-functional requirements, analyses, and other minor deliverables specified by the COR. Deliverables are expected to be free of grammatical errors, clear and concise, easily understood, appropriate to the intended audience, and to use plain language. All deliverables will be submitted to the COR. In the event of deliverables that do not have specific due dates in the statement of work, the COR and the Contractor’s Program Manager shall propose a delivery date that will be approved by the COR.

C.4.1.4 Coordination, Communication, and Cooperation between Activities The Contractor shall ensure that the appropriate coordination, communication, and consistency exist between and across teams and WGs so that all topics spanning across multiple aspects of the functional and non-functional requirements of the new electronic disclosure solution are treated as enterprise topics receiving the appropriate consideration and attention to be fully addressed. Thus, the need for coordination, communication, and cooperation is necessary to ensure that each topic is sufficiently developed in the detailed comprehensive functional and non-functional requirements.

The Contractor shall ensure that as the functional and non-functional requirements of various aspects of the new electronic disclosure environment are defined and that there is ongoing review and consideration of how these pieces fit, interact, depend on, and influence each other.

The Contractor shall ensure that:

1) The information garnered from the SME interviews and Working Groups is not “siloed” within those groups or within specific Contractor personnel/teams (Program community access to all information); and,

2) Interviews and time allotted with SEC Division/Office staff and other SMEs are maximized through providing enough lead time when scheduling the meeting as well as providing the following materials at least two (2) business days prior to the meeting (list is not meant to be exhaustive):

a) Detailed Agendas;

b) Clear articulation of the specific outcomes of the meeting/WG; and,

c) Minutes from any associated previous meetings:

i) Previous decisions, agreements, action items, etc.;

ii) Topics that are identified that may require additional working sessions or WGs to address; and

iii) Output that needs to be shared with other WGs due to potential cross topic impact.

The Contractor shall ensure that the entire team is aware of dependencies and decisions that are made within the context of this program so that they can communicate any potential changes to the appropriate team members who may depend on that dependency or decision. For example, if one Working Group is gathering functional and non-functional requirements for an externally hosted environment and another Working Group is gathering functional and non-functional requirements for an internally hosted environment the work of each group must be coordinated. The Contractor is responsible to ensure that the functional and non-functional requirements are coordinated and make sense from one aspect of this contract to all others.

C.4.2 Contract Deliverables Management and success of this contract will be manifested through developing and providing the deliverables defined within the contract.

Page 14 of 6768 RFP: SECHQ1-16-R-0017-000002

The primary deliverable for this contract is the detailed comprehensive Functional Requirements Document (FRD). Additional detail regarding this final deliverable can be found in Section C.4.2.1.4. The FRD, and the functional and non-functional requirements detailed within it, will be used as the basis for soliciting solution approaches, the final design, and the implementation, of the new environment.

All other contract deliverables will be in support of creating the FRD. When appropriate, the Contractor will use SEC SMEs to assist with the identification of functional and non-functional requirements that shall be documented in the FRD. The ERD PO will provide support to ensure that cross-agency SMEs are made available to facilitate the efficient and effective progress of the program while managing the program’s demand on SMEs to ensure balance.

The FRD and its supporting deliverables are outlined within this section. These documents will be reviewed by the ERD PO as the Contractor produces and delivers them. The Contractor shall use best practices in program management and report on its progress at predefined intervals, as specified in the contract and directed by the COR.

Program Management reporting by the Contractor shall generally be through the following mechanisms:

1) Program Management Plan (PMP);

2) Integrated Master Schedule (IMS);

3) Weekly Status Reporting (WSR);

4) Monthly Status Reporting (MSR); and

5) Monthly Status Report Board Presentation (MSRBP).

The SEC expects all deliverables to undergo quality review, as defined in Section C.4.2.1.3, and to adhere to the quality parameters outlined therein.

All deliverables, work products, invoices, contract files, and other documentation, drafts and finals, created for or used by the ERD PO and the Contractor will be posted on an internal SEC SharePoint site.

Contractor personnel and SEC staff will have appropriate access to the SharePoint site. The content management of the SharePoint site is not within scope of this contract. The Contractor shall submit all documents to the SEC for inclusion on the SharePoint site.

C.4.2.1 Contract Deliverables to be Periodically Updated The SEC requires periodic updates to the following deliverables throughout the Period of Performance.

Table F-1 in Section F.3 provides due dates and update parameters. Any material changes to these deliverables following acceptance are subject to review and approval by the COR.

C.4.2.1.1 Program Management Plan (PMP) The Contractor shall develop, maintain, and execute a Program Management Plan (PMP). (Deliverable 1) ).This Plan shall include all required elements necessary for developing the comprehensive Functional Requirements Document (FRD) and other deliverables. The PMP shall contain internal reporting relationships; define interfaces between the Contractor and its subcontractors (as applicable); and be used to perform project oversight and control.

The PMP shall contain the following:

1) Roles and Responsibilities of all parties;

2) Assumptions, Constraints, Risks and Risk Mitigation, and Dependencies;

3) Resource Management;

4) Subcontractor Management;

5) Quality Assurance and Control Plan (see Section C.4.2.1.3);

6) Document Change Management; and

7) Personnel Management, including:

Page 15 of 6768 RFP: SECHQ1-16-R-0017-000002

a) How the Contractor shall train and orient staff for this Contract; and

b) How the Contractor shall provide the additional skills outlined in Section H.12.

The Contractor shall provide the draft PMP within five30 days of the contract start date. The COR will provide comments on the initial PMP within thirty (30) calendar days after it is received. The Contractor shall revise the initial PMP in response to SEC comments and deliver the revised PMP to the SEC within fifteen (15) business days after receiving comments. Once approved, the Contractor shall keep the PMP up to date and provide details in the WSR and MSR as to where the program stands against the plan. The Contractor shall update the PMP at least semiannually thereafter or as directed by the COR.

C.4.2.1.2 Integrated Master Schedule (IMS) The Contractor shall create and maintain an Integrated Master Schedule for all of the tasks, activities, and deliverables in this contract. (Deliverable 2)). The Contractor shall use the same IMS structure and format that it currently uses with its Program Management methodology, and shall ensure that its personnel are adequately trained and experienced in using its IMS structure, format, and application.

An Integrated Master Schedule (IMS) is critical to the success of the ERD Program. Once the IMS is accepted by the SEC, it will be base-lined. The Contractor shall keep the IMS updated as changes occur for IMS status reporting. The Contractor shall create, update, manage, adhere to, and analyze all schedules for the ERD Program. While the IMS Status Report is a part of the MSR and WSR, which will identify minor concerns, the Contractor shall notify the COR immediately of any substantial scheduling issues.

The IMS shall be in accordance with work breakdown structures (WBSs). The Contractor shall provide ongoing analysis of labor, schedule, risk, trigger dates, resource needs, dependencies, discrepancies, conflicts, and performance as specified in this SOW. This schedule is to be provided to the COR no later than 45 calendar daysone (1) month afterfrom the contract start date. After the IMS has been accepted and base-lined, the SEC will keep the original approved IMS on the SEC’s ERD SharePoint site. Any modifications made to this deliverable must be auditable; containing, at a minimum, the change made, the responsible party for the change, the party who authorized the change, the date of the change, and the reason for the change. The actual change to the base-lined IMS shall be made to a separate file to ensure version control, and will also be stored on the SEC’s ERD SharePoint site. Each change to the IMS requires another copy to be placed on the SEC’s ERS SharePoint site so that the ERD PO and the Contractor can see a complete history of the IMS.

C.4.2.1.3 Quality Assurance and Control Plan/Control Management

C.4.2.1.3.1 Quality Control The Contractor shall develop and maintain an effective quality control program to ensure services are performed in accordance with this SOW. The Contractor shall develop and implement procedures to identify, prevent, and ensure non-recurrence of defective services. The Contractor’s quality control program is the means by which the Contractor is assured the work represents the best output of the contracting firm and is ready for review by the appropriate parties of the SEC and complies with the requirement of the contract. With respect to all deliverables, quality first applies to the specific value of the deliverable with respect to thoughtfulness, depth and clarity, second it applies to the quality of the writing (grammar, spelling, syntax) and/or the appropriateness of the presentation for the audience to which it is directed.

C.4.2.1.3.2 Quality Assurance The Government shall evaluate the Contractor’s performance under this contract in accordance with the Quality Assurance and Control Plan (QACP). This plan is primarily focused on what the Government must do to ensure that the Contractor has performed in accordance with the performance standards. It

Page 16 of 6768 RFP: SECHQ1-16-R-0017-000002 defines how the performance standards will be applied, the frequency of surveillance, and the minimum acceptable defect rate(s). The following items should be identified in the plan:

1. The project processes subject to quality assurance.

2. The quality standards and stakeholder expectations for that process.

3. The quality assurance activity – e.g., quality audit or reviews– that will be executed to monitor that project processes are properly followed.

4. The name of the person responsible for carrying out and reporting on the quality assurance activity.

C.4.2.1.3.3 Quality Assurance and Control Plan The Contractor shall prepare the Quality Assurance and Control Plan (QACP) within 30 days of award.

(Deliverable 2 & 4).) After COR acceptance of the QACP, it will become the document of record. Three copies of a comprehensive written QACP shall be submitted to the COR within five (5) working days when changes are made thereafter. Any changes to the QACP following acceptance shall be reviewed and approved by the COR.

C.4.2.1.3.4 Quality Assurance and Control Plan Execution The Contractor shall perform each task in full compliance with the approved QACP. The Contractor shall participate in formal product reviews, peer reviews, walk-throughs, and inspections in accordance with the QACP. The Contractor shall collect and report all metrics defined in the QACP. (Deliverable 2 & 4).)

C.4.2.1.3.5 Quality Assurance and Control Plan Monitoring The Contractor shall monitor all tasks to ensure the quality assurance and control management processes are being followed throughout the life cycle of the project. Once approved by the COR, The Contractor shall immediately notify the COR if it becomes aware of any deviations from the QACP.

C.4.2.1.4 Detailed Comprehensive Functional Requirements Document (FRD) The detailed comprehensive Functional Requirements Document deliverable shall consist of three (3) components:

1. The FRD outline;

2. The functional and non-functional requirements of the new electronic disclosure environment;

and

3. The Requirements Traceability Matrix.

The Contractor shall use these components as the foundation of the entirety of the FRD deliverable.

At the point in which the Contractor feels most comfortable, but no later than twelve (12) months into the contract, the Contractor is to begin placing their findings into a final Functional Requirements Document.

The Contractor shall propose and demonstrate to the ERD PO how each component is incorporated into the FRD by submitting a detailed outline of the FRD (see Section C.4.2.1.4.1). After receiving approval of the FRD outline, The Contractor may begin incorporating the necessary detail further described in Section C.4.2.1.4.2.

While the FRD document is being the developed, the Contractor shall also review the capabilities/functions/processes inventory (Attachment 2) in parallel to ensure a complete mapping of the EDGAR inventory to the detailed comprehensive functional and non-functional requirements of the new electronic disclosure environment.

In creating the FRD, the Contractor is expected to leverage its expertise and knowledge to recommend additional opportunities for improvement wherever possible.

Page 17 of 6768 RFP: SECHQ1-16-R-0017-000002

C.4.2.1.4.1 Functional Requirements Document Outline Prior to creating the FRD, the Contractor shall first submit an outline which closely follows the three (3) foundational points mentioned in Section C.4.2.1.4. The Contractor will provide the COR with the outline for inspection. The outline shall include detailed narrative examples of the major thematic areas to be addressed therein. This outline should be constructed using the Contractors methodology to produce a FRD, be informed by the artifacts and other deliverables of this contract, and provides, as a separate section, the ability to reconcile the functional and non-functional requirements of the new electronic disclosure environment with the EDGAR capabilities/functions/processes.

Once the outline has been approved, any material changes to the outline shall then be included in the monthly status report and monthly Board Presentations moving forward, at the direction of the COR.

C.4.2.1.4.2 Functional Requirements of the New Electronic Disclosure Environment The primary objective of this contract is to define the detailed comprehensive functional and non-functional requirements necessary to build the new electronic disclosure solution. These requirements will be the cornerstone of the next phase of the ERD Program. To this end, the Contractor shall narratively articulate each requirement in enough detail to allow future Offerors to be able to recommend a solution approach, and from that approach, a design which can be implemented as a new electronic disclosure solution.

In developing the requirements, the Contractor shall use an architectural approach which does not eliminate the possibility of the new electronic disclosure environment being an externalized, distributed architecture. Further, the Contractor shall not assume that the ultimate implementation of the new electronic disclosure environment will physically be located within the SEC. As such, the Contractor shall write the requirements in a manner that does not exclude such architectural principles as infrastructure as a service, external hosting by contractors, internal hosting by contractors, etc. In addition, the functional and non-functional requirements shall address the following, at a minimum:

1) How form filings are created and submitted. This is not the internal company process for determining the inclusion of materials to be filed, but the technical process of turning that material into a form filing(s) (the organization and combination of the structured data elements and unstructured information material into the resulting form filing(s));

2) Key capabilities of the new electronic disclosure solution;

3) The ability to “incorporate” existing filings from EDGAR into the new electronic disclosure solution;

4) The definition and functional and non-functional requirements of the “core” of the environment and any applicable system level tools, capabilities, or utilities;

5) Specific functional and non-functional requirements for APIs, data file formats, and solutions to export data/information to analytic environments external to the core, but dependent on the core;

and,

6) The many processes associated with the new environment, including but not limited to:

a) Filer support processes;

b) SEC/Filer interaction processes;

c) New form filing creation processes;

d) System development processes;

e) Data load and taxonomy extension processes;

f) Capability additions, modifications, and evolution processes;

g) Validation;

h) Form Filing Processes, including:

i) Identification;

ii) Creation and Submission;

Page 18 of 6768 RFP: SECHQ1-16-R-0017-000002

iii) Acceptance and/or Suspension;

iv) [External] Access Management;

v) Tools/Controls/Permissions;

vi) Fee Management System;

vii) Filing Workflow; and

viii) Filer Landing Pages;

i) Internal Access Management including tools/controls/permissions;

j) Filing Review Platform and Work Management;

k) Inflight Analysis;

l) Data Capture and Dissemination ;

m) Customer Interaction and Communication; and

n) Printing, Routing, Uploading, Downloading, Querying, and Viewing.

Below, Figure C-2 provides a high-level map of some of the envisioned solution functionalities and capabilities as well as exemplary elements of specific functional and non-functional areas.