CWDS Requirements Management Plan
This page is currently under development
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.
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.
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.
This version of the CWS-NS RMP focuses on the following processes:
- Requirements Identification
- Requirements Evaluation
- Requirements Validation
- Requirements Baseline
- Requirements Control
- Requirements Identification
- Requirements Evaluation
- Requirements Validation
- Requirements Baseline
- Requirements Control throughout life of the project
- Requirements Traceability
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
Executive Leadership Team (ELT)
· A Sponsor designee will be involved in early reviews of draft requirements and participate in JADs.
· May be called upon if an issue is escalated to the ELT.
· Reviews and approves baselined requirements.
· Accountable for ensuring the project remains within scope, 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.
· Set priorities, develop user stories and make/document decisions about features and technical implementation details based on user, policy, technical and business requirements.
· Translates user research into user stories.
· Defines the product vision and delivers the vision statement.
· Develops and prioritizes and delivers the Product Backlog and refines the backlog as needed.
· Deliver projects and products using the appropriate agile project management methodology.
· Work with service manager to define the roadmap and deliver the Product Roadmap.
· Monitors team scrum analytics and reports on progress.
· Coaches the team, protects the team and protects the scrum process.
· Log action items that are specific to the service team or that are enterprise/global or dependent on other service teams.
· Removes impediments and acts as liaison with other departments.
· Own the Pivotal tool setup/changes and work with the Schedule Manager to set up the backlog in the tool.
· Partner with Product Owner for backlog development, refinement, release planning and roadmap development.
· Work with the Project Scheduler to ensure work being tracked in the Agile Platform is represented and updated at the milestone level in MS Project.
· Facilitates the daily scrum meetings, sprint review meetings, and the sprint retrospective meetings.
Requirements Manager (RM)
· Participates in internal meetings to help define requirements; identify and communicate outstanding issues and initiates resolution activities
· Writes draft requirements document; plans, schedules and prepares for internal walkthroughs and Joint Application Development (JAD) sessions
· Incorporates feedback and comments into draft requirements; and sends revised document to stakeholders for review and approval.
· Works closely with the Service Delivery 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
· Assists 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.
· Responsible for execution of all activities defined in the IV&V contract and SOW
· Validating and verifying that project and contractor products adhere to industry standards, and that all delivered products meet defined requirements, specifications, and/or user stories.
· Document formal requirements traceability.
· Responsible for providing oversight of the contractor performing IV&V in accordance with the SOW and IV&V contract.
· Contract management and acceptance of IV&V deliverables.
· Facilitation of oversight meetings with the CWS-NS Project, participation in project artifact reviews, change management meetings, risk and issue management sessions, and activities that result in decisions on project policy and/or process.
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 InitiationDuring 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 & ProcurementDuring 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 DevelopmentDuring 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 TraceabilityRequirements 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/ValidationDuring 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
- a) All relevant State and Federal legislation and regulations
- b) All relevant Federal and State Implementation Letters
- c) Expectations of key stakeholders
- d) State and Federal security requirements
- 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.
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.