Requirements are the foundation of a project’s scope, quality planning, and procurement activities. Requirements management is a continuous process throughout the life of the project. Maintaining the integrity of these requirements throughout the life of the project is vital to the success of the quality of the system that is implemented.

In the new world of Agile, requirements are documented through the creation of user stories that live within a specific feature called an epic. These user stories will document the business and functional needs of the Project and will serve as the Product Backlog of the work to be completed once the vendors are selected. Requirements traceability will still need to be conducted in this Agile environment. Previously, using the Waterfall approach, baselined business and technical requirements were traced to the Feasibility Study Report and Special Project Reports. Now, using the Agile approach, the epics are traced to the previously baselined requirements.

1.1 Purpose

The Requirements Management Plan (RMP) identifies the processes used to plan, develop, monitor and control requirements in all stages of a project’s lifecycle. This document is the foundation for all project requirement management policies for the CWS-NS Project.

1.2 Policy

The Project used Microsoft Excel to document and manage the business functional and technical system requirements elicited prior to adopting the Agile approach. The Project is using Pivotal Tracker to document and manage user stories (requirements). The Project will be using Microsoft Excel to document and manage the traceability matrix.

1.3 Scope

This version of the CWS-NS RMP focuses on the following processes:

• Requirements Identification
• Requirements Evaluation
• Requirements Validation
• Requirements Baseline
• Requirements Control

1.3.1 In-Scope

• Requirements Identification
• Requirements Evaluation
• Requirements Validation
• Requirements Baseline
• Requirements Control throughout life of the project
• Requirements Traceability

1.3.2 Out-of-Scope

The process used to manage requirement changes are documented in the CWS-NS Change Management Plan.

1.4 Document Maintenance

This document will be reviewed and updated on an as needed basis.

This document contains a revision history log. When changes occur, the version number will be updated to the next increment and the date, owner making the change, and change description will be recorded in the revision history log of the document.

There will be a need for the refinement of existing user stories and the subsequent delivery of detailed system requirements specifications. As such, this RMP will be updated to reflect any changes made to the processes used to monitor and control requirements based on a collaborative plan established with the selected vendors.

Figure 1 – Roles and Responsibilities

Successful implementation of the RMP requires coordination of all the organizations working on the CWS-NS Project. The Requirements Management Process, in conjunction with the Agile/scrum methodology, consists of the following: Initiation, Planning & Procurement, Development, Traceability, and Verification/Validation. The process is triggered by a request for a new program, system or service or a change to the same requirement.

The Requirements Management Process is an iterative process controlled via the project’s Change Management process and interacting with other project management processes.

3.1 Initiation

During the Initiation phase of the project, a Feasibility Study Report was written to provide a proposed technical solution that will support the current and future needs of Child Welfare Services. Business requirements were defined, and a proposed technical solution was documented to address the business requirements.

The CWS-NS Project Charter was created as a preliminary scope statement outlining the high level scope and its meaning regarding the characteristics, parameters, and functionality of the project or new system. Requirements were developed using Business Practice Packages (BPPs), and Joint Application Development sessions (JADs) with Subject Matter Experts (SMEs) to verify and validate the as-is business processes and requirements. The "as is" business requirements were used as reference material during the development of the CWS-NS system requirements. The business requirements are maintained in a Microsoft Word table that is managed by the Requirements Manager.

During the Waterfall approach, the system requirements for both business and technical areas were developed using the Agile scrum process. Although the RFP was never released to the public, and the requirements were never formally baselined, the project is considering these approved requirements (version 7.5) baselined for the purpose of establishing a benchmark to assess future requirements analysis against.

3.2 Planning & Procurement

During the Planning & Procurement Phase of the project, the Feasibility Study Report and Project Charter were used to define the Project’s Work Breakdown Structure (WBS), management of project cost, schedule, requirements, quality planning, and a process to manage changes to approved requirements. The Agile methodology, using the scrum process, was reintroduced to the Project, along with the Pivotal Tracker tool.

The Service Delivery Teams develop user stories based on the business and technology needs, utilizing the business, functional, and technical requirements identified in the Initiation and Planning & Procurement phases. Requirements are fed into a Service Team’s product backlog within Pivotal Tracker; they're decomposed into sprint backlogs items/user stories through sprint planning; these user stories are then confirmed against the existing business requirements developed during initiation and Planning and a gap analysis is performed.

3.3 Development

During the Development phase of the project, the user stories developed, based on the business and technical requirements, will be further defined. Transition requirements and quality requirements will be developed. The system requirements will be maintained in the Excel Spreadsheet to track any changes/modifications made during the solicitation process.

The Service Manager’s role is to define the high-level scope in terms of epics or features, then the Scrum Master, working with the vendor and core team, decomposes those epics and features into user stories. The work items/user stories are pulled from the product backlog and directed by the Service Manager, with the process controlled and managed by the scrum master. The goal for the Service Teams is to make sure they feed the product backlog and can support and describe what needs to be built by the development team prior to the start of the sprint.

3.4 Traceability

Requirements traceability using the Agile methodology, ensures that the business need is tied to epics/features, along with the user stories contained within them, that have been developed based on the previously baselined v7.5 requirements and approved BPPs. Should business needs change, the Agile methodology embraces this and provides traceability through the use of Pivotal Tracker along with the requirements gap analysis being performed throughout user story development/refinement. The user stories will be tied to artifacts such as test cases, providing further traceability. The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective. In other words, traceability ensures that every requirement has a business purpose, and that no requirement is superfluous.

Traceability occurs throughout the life of the project. The Requirements Traceability Matrix (RTM) is currently maintained in an Excel workbook by the Requirements Manager. Requirements traceability will occur between the following: system requirements and epics, and system requirements and the BPPs.

Prior to accepting the system, requirements traceability shall be verified to ensure all requirements have been addressed in the design and testing phases. IV& is contracted to provide an independent review of the traceability in addition to the Quality Assurance contractor who has a role in validating the requirements. The ELT shall be included in the decision to accept the system and in the final signoff process.

During system development, Quality Control review of the RTM is a key Deliverable of the Requirements phase and should also be reviewed and approved.

3.5 Verification/Validation

During the Design, Development and Implementation (DD&I) phase of the project, the user stories will serve as the business, functional, and technical requirements and will be maintained by each Service Delivery Team using the Pivotal Tracker tool.

Figure 2 – Requirements Management & Traceability

Requirements Deliverables and Artifacts include, but are not limited to:

• a) The baselined requirements (v7.5)
• b) User Stories
• c) Requirements presentations
• d) Meeting Minutes recording decisions made in design sessions and/or JADs
• e) Design, Development, and Implementation Work Plan (note: the Work Plan should be baselined when the requirements are finalized)
• f) Requirement Quality Assurance Checklist
• g) Populated Requirement Traceability Matrix (RTM)
• h) Policy Letters, Regulations, and other legally mandated documents
• i) Written Policy Clarifications (if applicable)

4.1 Requirements Development

Once the contract has been awarded to the vendor, user stories will be further refined to provide the contractor with detailed business, functional and technical specifications for Design, Development and Implementation (DD&I).

Requirements data may be collected utilizing a variety of tools and techniques including, but not limited to:

• a) User stories
• b) Project Charter
• c) All relevant State and Federal legislation and regulations
• d) All relevant Federal and State Implementation Letters
• e) Written Policy Clarifications
• f) Information gathered from Subject Matter Experts (SMEs)
• g) Expectations of key stakeholders
• h) Joint Requirements Planning (JRP) Sessions
• i) Technical Assessment/Review
• j) Enterprise Architecture Review
• k) State and Federal security requirements
• l) Interviews
• m) Mind mapping
• n) Fishbone Diagramming
• o) Surveys
• p) Observations
• q) Prototyping

4.1.1 Requirement Constraints
System requirements can be influenced by many factors. These factors include, but are not limited to:

1. a) All relevant State and Federal legislation and regulations
2. b) All relevant Federal and State Implementation Letters
3. c) Expectations of key stakeholders
4. d) State and Federal security requirements

4.1.2 Requirements Documentation

• Business Requirements – The business requirements are described in the Feasibility Study Report and the Project Charter and are also further refined in the Request for Proposal, which forms the basis for the baseline of the requirements.
• Technical/System Requirements – A proposed technical solution is described in the Feasibility Study Report and the Project Charter and are also further refined in the Request for Proposal, which forms the basis for the baseline of the requirements.
• Project Requirements – Project requirements are described in the Feasibility Study Report, the Project Charter, the CWS-NS Project Management Plan, and the subsidiary project management plans.
• Quality Requirements – Validation of successful completion of a project deliverables or fulfilment of other project requirements are described in the Statement of Work, the System Integrator contract, support contracts, CWS-NS Quality Management Plan, the CWS-NS Deliverable Management Plan, and the CWS-NS Contract Management Plan.

4.1.3 Requirements Review and Approval

After composing an initial draft, the requirements document shall go through a series of reviews and iterations to refine the product prior to approval and finalization.

4.1.4 Requirements Change Management

After each level of requirements are accepted and baselined, any change to those requirements and related work products will be restricted and will only be made through the process defined in the project’s Change Management Plan.