CWDS

Requirements Management Plan

Executive Summary

“Requirements Management” is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. In Agile, the goal is to create a process by which requirements can be thoroughly vetted, organized, and communicated in a manner that is iterative, timely, and quality-focused.

The aim of any Agile development project is to deliver working software as fast as possible, where “working” actually means a product that is able to successfully resolve the customer’s problems. In order to be able to deliver a solution, one must first understand what the problem is. Requirements management is at the heart of the CWS-NS project.

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 Child Welfare Services New System (CWS-NS) Project and will serve as the Product Backlog of the work to be completed once the development teams 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.

The CWS-NS 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.
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 primary activities: 

Introduction

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.

“Requirements Management” is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. In Agile, the goal is to create a process by which requirements can be thoroughly vetted, organized, and communicated in a manner that is iterative, timely, and quality-focused.

The term “requirements traceability” refers to the ability to map requirements back to business goals and objectives, including mapping requirements forward to test cases, business processes, software, training materials, and more. Conducting a traceability provides a way to tie everything together from start to finish, and make sure that the system aligns with originating goals and objectives.

Agile Scrum allows development teams to build software incrementally over two-week events, or sprints. Requirements are fed into a product backlog prior to sprint inception; they are decomposed into sprint backlog items through sprint planning. The development team starts by discussing what needs developed in a given sprint based on organizational needs and strategy. The work items are pulled from the product backlog and directed by the product owner, with the process controlled and managed by the Scrum Master. The goal for the business is to make sure they feed the product backlog and can support and describe what needs built by the development team prior to the start of the sprint.

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 Child Welfare Services New System (CWS-NS) Project and will serve as the Product Backlog of the work to be completed once the development teams 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.
 

Purpose
The CWS-NS 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.

Policy

The Project used Microsoft Excel to document and manage the business functional and technical system requirements elicited prior to adopting the Agile approach.

With the pivot to Agile in November 2015, 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.

Scope

In-Scope

The following processes are in scope for the CWS-NS RMP:

Out-of-Scope

The following processes are not in scope for the CWS-NS RMP:

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.

Roles and Responsibilities

Role

Responsibility

Executive Leadership Team (ELT)
  • A Sponsor designee will be involved in early reviews of draft requirements and participate in JADs.
  • Resolves escalated issues from digital service teams.
  • Reviews and approves baselined requirements.

Project Director
  • Accountable for ensuring the project remains within scope, on budget and in compliance with Best Practices and policies.
  • Monitors the progress of the project, provides regular status and makes approval recommendations to the ELT.

Project Management Office (PMO)
  • Accountable for ensuring requirements plans and supporting methodologies (e.g. processes, procedures, standards, and templates) are in compliance with Best Practices and policies.
  • Monitors the progress of the requirements, provides regular status and makes approval recommendations to the Project Director.

Service Managers and Product Owners
  • Set priorities, develop user stories and make/document decisions about features and technical implementation details based on user, policy, technical and business requirements.
  • Translate user research into user stories.
  • Define the product vision and delivers the vision statement.
  • Develop, prioritize and deliver the Product Backlog.
  • Refine the backlog as needed.

Scrum Masters
  • Deliver projects and products using the appropriate agile project management methodology.
  • Work with service manager to define the roadmap and deliver the Product Roadmap.
  • Monitor team scrum analytics and reports on progress.
  • Coach the team, protect the team and protect the scrum process.
  • Log action items that are specific to the service team or that are enterprise/global or dependent on other service teams.
  • Remove impediments and acts as liaison with other departments.
  • Own the Pivotal tool setup/changes.
  • Partner with Product Owner for backlog development, refinement, release planning and roadmap development.
  • Facilitates the daily scrum meetings, sprint review meetings, and the sprint retrospective meetings.

Requirements Manager (RM)
  • Participate in internal meetings to help define requirements; identify and communicate outstanding issues and initiates resolution activities
  • Write draft requirements document; plans, schedules and prepares for internal walkthroughs and Joint Application Development (JAD) sessions
  • Incorporate feedback and comments into draft requirements; and send revised document to stakeholders for review and approval.
  • Work closely with the Digital Service Teams and Independent Verification & Validation (IV&V) to ensure requirements traceability.

Technical Solution Manager

  • Accountable for ensuring that the system is technically sound, that the technical requirements are clear, fair and enables the system functions as proposed/designed.

System Engineer/Lead System Developer
  • Support the Technical Solution Manager primarily in providing technical leadership towards the development and tracking of the system business requirements and interfaces
  • Assist with technical analyses, and ensuring the final system meets all stated requirements.

Subject Matter Experts (SME)
  • Accountable for review of functional and technical components of the requirements and assume part ownership of those sections pertaining to their area of system expertise.

Program/Policy Subject Matter Expert
  • Accountable for review of the draft requirements as an expert in the program and policies of the subject area.
  • Verify the accurate interpretation of implementation letters and/or legal mandates.

IV&V Consultants
  • Responsible for execution of all activities defined in the IV&V contract and SOW
  • Validate and verify that project and contractor products adhere to industry standards, and that all delivered products meet defined requirements, specifications, and/or user stories.
  • Validate formal requirements traceability.

Requirements Management Process

The requirements management process is triggered by a request for a new program, system or service or a change to the same requirement. Agile requirements depend on a shared understanding of the customer that is shared between the product owner, designers, and the development team.

Requirements Management Process is an iterative process controlled via the project’s Change Management process and interacting with other project management processes. Scrum allows development teams to build software incrementally over two- week sprints. Requirements are fed into a product backlog prior to sprint inception and they are decomposed into sprint backlogs items through sprint planning. development team starts by discussing what needs developed in a given sprint based on organizational needs and strategy. The Product Owner prioritizes and pulls work items from the product backlog, with the process controlled and managed by the Scrum Master. The goal for the business is to make sure they feed the product backlog and can support and describe what needs built by the development team prior to the start of the sprint.

Requirements deliverables and artifacts include the following possibilities:

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 primary activities:

Initiation

During the Initiation phase of the project, a Feasibility Study Report provides a proposed technical solution that will support the current and future needs of Child Welfare Services. Business requirements are defined, and a proposed technical solution is 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.

During the initiation phase, an initial requirements envisioning phase is fundamental. At this stage, the objective is not to drill down to the details of how your end product will work. Instead, you aim to identify your project’s scope, which will help you to understand and estimate the cost and time needs of the project. The main objective is to develop a high-level understanding of CWS-NS business goals and an outline of what’s needed.

Once the project’s high-level goals, schedule and costs have been agreed on, it’s time to really get the Agile requirements management lifecycle rolling.

Planning and Procurement

During the Planning & Procurement Phase of the project, the Feasibility Study Report and Project Charter are 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 Digital Service 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. User stories are short, informal descriptions of an everyday use case – basically, one or a few sentences in plain, every day or business language describing how the user expects the software to work in a certain scenario. The general template for user stories use is the following: “As a <role>, I want <goal/desire> so that <benefit>”. The requirements backlog could include visual models or UML diagrams, functional requirements, user stories, etc.

Requirements/User Stories are then fed into a product backlog within Pivotal Tracker. They are decomposed into sprint backlogs items/user stories through sprint planning and these user stories are then confirmed against the existing business requirements developed during initiation and Planning. If needed, a gap analysis is performed.

The next step of the planning process aims to evaluate requirements based on business strategy and objectives, and to define what needs to be built. Requirements (user stories, functional requirements, etc) are prioritized based on their importance, effort needs, etc.

The resulting set of general requirements will go through decomposition and some “grooming” before making their way to the product backlog. Essentially, this stage of the process helps you refine requirements and “translate” them into actual features (directions that your developers will understand). Including your development team in the process helps make sure that all the requirements are clear and easily understood by the team that will implement them. It’s important that user stories are linked to epics and features and tasks, so that developers don’t only understand what their task is, but why they are doing what they’re doing.

Development

Once a system development contract is awarded for a Digital Service team, user stories will be further refined to provide the contractor with detailed business, functional and technical specifications for Design, Development and Implementation (DD&I).

In Scrum, the product to be developed is described by the backlog, a set of items — generally user stories, but not necessarily; backlog items are selected according to priorities for implementation in successive iterations — which Scrum calls sprints.

Requirements Data

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

Requirements Documentation

Requirements documentation may include the following:

Requirements Development Process
 

 During the Development phase of the project, the user stories are further refined based on the business and technical needs. Transition requirements and quality requirements are developed and an Excel spreadsheet tracks the system requirements for any changes/modifications made during the solicitation process.
 

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

The overall objective in the development phase is to make sure that the business (specifically, the product owner) can clearly articulate what needs built and define what is of high quality. To accomplish this, the requirements cycle follows a Scrum-like process that mirrors the development cycle but stays two to three steps ahead. The goal is to create a process by which requirements can be thoroughly vetted, organized, and communicated in a manner that is iterative, timely, and quality-focused.

In order to foster a shared understanding between the customer, the developers and the design team, the following guidance is observed:

Traceability

Requirements traceability ensures that the business need is tied to a defined epic or feature along with the user stories contained within them.

Should business needs change, the Agile methodology embraces the change process and provides traceability through the use of Pivotal Tracker along with the requirements gap analysis performed throughout user story development/refinement. The user stories are 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) (Note: This link is temporarily for OSI internal use only) is currently maintained in an Excel workbook by the Requirements Manager and stored with version control in SharePoint. Requirements traceability will occur between the following: system requirements and epics, and system requirements and the BPPs.

Prior to accepting the system, requirements traceability is validated to ensure all requirements have been addressed in the design and testing phases. Any gaps in requirements coverage or testing coverage must be documented and approved. IV&V 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.

Verification/Validation

The purpose of requirements verification is to ensure that work products meet requirements. Verification demonstrates things are well done. Validation demonstrates things are done correctly.

The main goal of verification and validation is to ensure that final product will be delivered as it was understood by the team. It includes software testing such as unit testing, integration testing, and so on. Thus, when a product-backlog item (e.g. a user story) is derived from a portfolio element, the product-backlog item should also be verified.

In a review of requirements, customers may discover ambiguous requirements (verification) or unneeded ones (validation). If development teams are meeting with the customer on a regular basis, validation happens early and it happens often. Requirements validation is an ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements.

Some recommended methods to approach requirements validation:

Requirements validation is a critical activity. While sign-off is often thought of as the tried-and-true way to validate requirements, the reality is that every question you ask to ensure the completeness of your requirements and their link back to the business need is part of requirements validation.

Requirements Management Workflow

The workflow for requirements management is provided below: