ATTM 015.pdf

Document number: PGM.PLAN.0002 Version: 4.0

Delivery of Automated Systems for Healthcare (DASH) Program

Requirements Management Plan

ATTM 015

PGM.PLAN.0002 – Requirements Management Plan Ver.4.0

Table of Contents

1.0 INTRODUCTION

1.1 PURPOSE

1.2 SCOPE

1.3 GOALS

1.4 ASSUMPTIONS

1.5 CONSTRAINTS

1.6 STAKEHOLDERS

1.7 GLOSSARY

1.8 REFERENCES

2.0 REQUIREMENTS PROCESS OVERVIEW

2.1 REQUIREMENT LIFECYCLE

2.2 REQUIREMENT SOURCES

2.3 REQUIREMENT TYPES

Functional Requirements Non-Functional Requirements

2.4 REQUIREMENT STATUS DEFINITIONS

2.5 REQUIREMENTS CONFIGURATION MANAGEMENT

Requirements Repository Capabilities Requirement Artifacts Repository Requirements Tool Usage and Configuration Key Requirement Attributes

3.0 REQUIREMENT ACTIVITIES

3.1 REQUIREMENT VALIDATION

3.2 REQUIREMENT ELABORATION

Writing Requirements Requirement Context Recommended Preparation for Writing Requirements DASH Requirement Writing Guidelines Words to Avoid Words to Use Desirable/Undesirable Requirement Example DASH Requirement Quality Criteria

3.3 REQUIREMENT APPROVAL – JRC PROCESS

Emergency JRC Meetings Virtual JRC Meetings

3.4 REQUIREMENT PRIORITIZATION

3.5 REQUIREMENT BASELINES

3.6 REQUIREMENT TRACEABILITY

4.0 REQUIREMENT ROLES AND RESPONSIBILITIES

5.0 REQUIREMENTS REPORTING AND METRICS

6.0 REQUIREMENT DELIVERABLES

7.0 GOVERNANCE AND PLAN MAINTENANCE

8.0 APPENDICES

APPENDIX A - DEVOPS REQUIREMENT ATTRIBUTES

APPENDIX B - REQUIREMENT TRACEABILITY MATRIX (RTM)

APPENDIX C - COMPONENT LIST

APPENDIX D – REQUIREMENT SPECIFICATION DOCUMENT (RSD) TEMPLATES

APPENDIX E – REQUIREMENT REPOSITORY SECURITY

APPENDIX F – SAMPLE JRC LOG

1.0 Introduction

1.1 Purpose

The DASH Program includes multiple Vendors and applications deployed in a modular fashion to support enterprise-wide initiatives. This plan defines the overall requirements process and common framework required to govern requirements for the DASH Program at the enterprise and sub-project levels. SCDHHS will work with each DASH vendor to meet the objectives to document, validate, approve, trace, and manage requirements in a consistent manner that supports their sub-project and any touchpoints across the DASH Program.

1.2 Scope

This plan governs requirement management and traceability at the DASH enterprise and sub-project levels. Requirements are captured and managed for each sub-project per the corresponding RFP/Contract and Federal Certification requirements that prescribe business, technical, and Certification outcomes.

SCDHHS will work with each Vendor to review and manage requirements as they are traced and implemented through downstream System Development Lifecycle (SDLC) phases. This plan defines the bi-directional traceability required for requirements to specific artifacts to support Design, Development, Testing, Training, Organizational Change Management (OCM), and Certification activities.

This plan governs the process to validate each requirement via joint review with SCDHHS and each Vendor to confirm mutual understanding by each party and adherence to requirement quality criteria. Successfully validated requirements are subject to formal review and configuration management processes.

Validated and baselined requirements serve to define project scope and form the basis for downstream SDLC activities. Supporting artifacts must be traced to applicable requirements to provide context, details, and configuration management to ensure that requirements are well-defined and testable.

New or changed requirements that exceed the schedule, scope, cost/budget of the RFP/Contract or Federal Certification requirements will be addressed via the Change Request for the sub-project.

1.3 Goals

This plan is intended to support achievement of the following goals related to requirements definition and management:

• Define the process for documenting, reviewing, and approving requirements

• Define roles and responsibilities related to requirements development and management

• Define the process for requirements management and requirement change control

• Define the requirements baseline process

• Describe the process to implement bi-directional requirement traceability

• Describe the capability and mechanism for reporting requirement information

• Describe the requirements–related interaction between SCDHHS/Vendor requirement repositories

• Support Testing and Certification for DASH sub-projects

• Support ongoing impact analysis and Regression Test for DASH and any sub-projects

1.4 Assumptions

Precise and accurate text for all RFP/Contract/Federal Certification requirements will be used as the starting point for requirements gathering; Review and validation by SCDHHS is required for any DASH sub-project that imports requirements to a Vendor-managed requirements management tool/repository

RFP/Contract/Federal Certification requirements may be elaborated per SCDHHS approval to provide context or subdivided (such as parsing bullets or individual clauses/sentences to separate requirements) to promote clarity of traceability

SCDHHS and Vendor Subject Matter Experts (SMEs) will be identified and available to participate in JADs as agreed to in the approved project schedule

SCDHHS and the Vendor will define a mutually agreed upon timeframe for advance notice of requirement meetings, agendas, and questions by the Vendor and any expectations for acknowledgment/response by SCDHHS

SCDHHS will work with the Vendor to provide relevant requirement-related artifacts such as As Is/To Be Flows, policy documents, SCDHHS process documents, workflows, organization charts, etc. within a mutually agreed timeframe as needed for requirement review purposes

Vendors will provide visual aids where feasible to illustrate functional overviews, application workflows, business processes for JADs or demonstrate COTS capabilities or specific functionality for Design discussions

Vendors will provide a business user-oriented listing of application components (screens, reports, batch process, etc.) to aid SCDHHS in developing an understanding of how requirements will be satisfied during Design discussions; Refer to Appendix C – Component List for additional details

Design discussions will address and capture the means to satisfy each requirement in terms of existing features and those that require customization or new functionality during the Design Phase

1.5 Constraints

SCDHHS will work with each vendor to define the level of access and number of users that require access to the DASH requirements repository, Microsoft Azure DevOps

(DevOps), and any Vendor-managed requirements management tools/requirement repositories

1.6 Stakeholders

This document is intended to provide information and guidance to the following SCDHHS/Vendor groups or individuals:

Subject Matter Experts (SMEs)

Business Analysts (BAs)

Systems Analysts (SAs)

DASH stakeholders that review, approve, or access DASH-related requirements

1.7 Glossary

Term Definition Baseline A snapshot of approved requirements and associated attributes corresponding to a mutually agreed upon schedule milestone or activity; Baselined requirements are deemed stable, and metrics will be calculated to assess baselined requirement volatility

Bi-directional Traceability

The ability to trace forward to another SDLC phase such as a requirement to component or backward from a component to a requirement. Bi-directional traceability establishes a two-way relationship between two artifacts; See the DASH Traceability Model

Business Requirement

Describes specific business need; Captures “what” the system must do; Also referred to as a Functional requirement

Change Request Requirement

Requirement as documented within a Change Request that has been approved by SCDHHS

Component Term used to identify a software module within a Vendor application such as a web page/screen, form, report, batch program, or interface;

Used to support functional traceability from a requirement to the component that satisfies it to support downstream DASH stakeholders in their SDLC activities

Consolidated Deliverables Management List

(CDML)

Listing of project deliverables as defined by Request for Proposal

(RFP)

COTS Custom Off the Shelf software application provided by a Vendor and modified/customized per approved project requirements

Design SDLC activity that follows Requirements Phase to determine “how” requirements will be met during Development.

Term Definition Federal Certification Requirements

Federal Certification Requirements as identified per CMS guidance

Functional Requirements

Requirements that describe a business need such as creating a claim, generating a form or report, or automatically tracking a timeframe

Joint Application Design (JAD)

Session conducted with Vendor and SCDHHS to validate requirements

Joint Review Committee (JRC)

Group comprised of SCDHHS staff that monitor the queue of proposed requirement changes and collaborate with Vendor staff to formally approve or reject proposed changes

Microsoft Azure DevOps (DevOps)

DASH repository used to support SDLC management of Requirements, Testing, Defect Management, and traceability

Non-Functional Requirements

Requirements that are associated with some technical aspect of an application or supporting the DASH Program; This category of requirements includes requirements with a Requirement Type of Performance, Operational, Technical, Security, Usability, and Conversion

Organizational Change Management

(OCM)

DASH team tasked with managing the impact of proposed business changes associated with the To Be organization

Operational Requirement

Operational requirements are often met by a plan or process that occurs outside the Vendor application

Performance Requirements

Requirement that defines a system standard to accomplish a given function under specific conditions such as response time or throughput

Requirements Traceability Matrix (RTM)

Document that traces approved requirements through the SDLC and includes links to approved designs, components, and test cases at a minimum; Each approved requirement should be associated with a system artifact of some type such as a plan, document, software component, test case, etc.

SCDHHS

Requirement States

Approved – Validated during JAD and approved by JRC Deferred – To be addressed in a later phase Draft – Default value for newly imported requirement Duplicate – Overlaps or duplicates another requirement Analyzed – Reviewed by Vendor and ready for JAD discussion Rejected – Unnecessary, incorrect, or lacking sufficient detail Research – Requires follow-up or review

RFP Requirements Requirements identified in the Request for Proposal (RFP)/Contract for a specific sub-project/Vendor; Usually cited in the RFP/Contract Scope of Work/Specifications section

Term Definition Requirements Traceability Matrix (RTM)

Document generated or compiled from the Requirement Repository tool to show the traceability of a requirement to downstream artifacts; See Appendix B - Requirements Traceability (RTM) for additional details

RQ Abbreviation for Requirement used in this plan in diagrams or tables with limited space

Requirement Specification Document (RSD)

A document with a defined format as approved by SCDHHS that is used to define one or more requirements that must be supported by significant detail, scenarios, permutations, or acceptable values; An RSD will be accompanied by a requirement that describes the supporting business need and indicates the RSD exists; See Appendix D - Requirements Specification Document (RSD) Templates for additional details

Service Level Agreement (SLA)

Agreed upon performance standards or benchmarks

Source Requirement

Term used to collectively refer to RFP and Federal Certification requirements; Requirement text, structure, and requirement ID attributes must be preserved for Source requirements and remain unaltered; Requirements elaborated from a Source requirement must include a reference to the original Source requirement ID

Streamlined Modular Certification

(SMC)

CMS-defined certification approach that defines certification activities for modular MMIS implementations

System Artifact A controlled document used to illustrate or define “how” a requirement will be met; May be provided in the context of a specific application component (such as a web page) or business function in the form of a design or technical document

System Development Lifecycle (SDLC)

A framework describing all the activities for planning, creating, testing, and deploying an information system; The stages in the framework may include Requirement Analysis, Design, Development, Testing, Training, Implementation, etc.

Subject Matter Expert (SME)

Personnel identified as a participant or decision maker for the purposes of reviewing and managing DASH and DASH sub-project requirements

User Acceptance Test (UAT)

A test phase planned and executed by SCDHHS staff using realistic/converted data and user-driven scenarios to confirm the system performs according to the approved Requirements and Design

User Story Common element of Agile methodology used to define a short, simple feature description from a user’s point of view; A self-contained unit of development work

Term Definition Validated Requirement

Any RFP, Federal Certification, Business, or Change Request requirement that has been included in JAD and confirmed by an SCDHHS SME; Confirmation by an SCDHHS SME enables a requirement to be referred to JRC for formal approval

Vendor DASH Solution Provider Vendor Application

Software application to be provided by a Vendor for customization/use

1.8 References

[1] PGM.PROC.0002 – Documentation Management Process

[2] PGM.PROC.0003 - Project Management Procedures

[3] PGM.PLAN.0005 – Issue Management Plan

[4] PGM.PLAN.0006 - Change Management Plan

2.0 Requirements Process Overview

2.1 Requirement Lifecycle

The DASH requirement lifecycle includes activities that span the System Development Lifecycle (SDLC). The requirement lifecycle includes management of Source and Validated requirements. Source requirements originate from the RFP, Change Requests, or Federal Certification requirements for DASH sub-projects and are captured exactly as documented.

Validated requirements are derived as necessary from Source requirements via Requirements Review Session by DASH team members to address business/system functionality and user needs.

The major activities of the requirement lifecycle are illustrated in Figure 1 – DASH Requirement Lifecycle.

Figure 1 - DASH Requirement Lifecycle

Requirement Import and Initial Baseline

SCDHHS will collaborate with the Vendor to compile a listing of RFP and Federal Certification Source requirements for import to the Requirement Repository. This import will include capture of Source requirement text as written and preserve the numbering structure and identification numbers/titles. Source requirements may be parsed as needed to avoid complex requirements such as multiple bullets or sentences. During import of Source requirements to the repository, the requirement status should default to Draft.

An initial requirement baseline for all Source requirements will be generated from the Requirement Repository for joint review by SCDHHS and the Vendor. This report will list each requirement and all associated attributes. Any requirements originating from approved Change Requests will be subsequently added to the Requirement Repository using the same process. Refer to PGM.PLAN.0006 - Change Management Plan for additional details.

Vendor Requirement Review

Draft requirements are subject to review and analysis by the Vendor. This review must be completed prior to conducting a JAD session with SCDHHS. Source requirements may be elaborated during JAD based on SME input to generate Validated requirements. Validated requirements may be associated with System Artifacts as approved by SCDHHS. These artifacts may be developed before, during, or after JADs as approved by SCDHHS. Any existing SCDHHS/Vendor artifacts for requirements should be identified and communicated in advance, as feasible, in preparation for the JAD.

Upon completion of their review, the Vendor must update requirements with a status of Draft to Analyzed. Additionally, required planning attributes including JAD Date, Phase, Priority, etc. This planning information should support the process for the Vendor to develop detailed agendas listing the requirements planned for discussion in each JAD.

JAD

Requirements with a status of Analyzed will be discussed during JAD with SCDHHS and Vendor staff. SCDHHS will work with each Vendor to identify the SME participants/decision makers in advance of each session. SCDHHS and the Vendor are expected to bring any applicable artifacts and reference materials to support the discussion.

The Vendor must review each requirement and collaborate with SCDHHS to confirm the requirement conveys the business need accurately. Requirements that are complex or detailed in nature may be captured in a Requirement Specification Document (RSD). These requirements include items such as fee tables, complex calculations, or code/value lists.

Each RSD should be associated with a Validated requirement that introduces it. The RSD will be subject to configuration management and linked to the Validated requirement. SCDHHS will provide RSD templates.

JAD follow-up items may be tracked as Action Items with mutually agreed upon due dates.

Refer to PGM.PROC.0003 - Project Management Procedures for additional details on the Action Item process. The Vendor should capture a Proposed JRC Status for each requirement discussed based on SME guidance. The requirement status will remain Analyzed until the proposed status is confirmed by the Joint Review Committee (JRC).

SME Validation

State SMEs will provide requirement feedback during JADs and help identify the proper status for each requirement. When the SME and Vendor agree the requirement is accurate and satisfies requirement quality criteria, the requirement may be proposed for approval by the JRC. Approved requirements enter the downstream SDLC activities.

When a SME from SCDHHS or the Vendor is unable to validate the requirement for business or technical reasons, an Action Item should be created with a mutually agreed upon due date and requirement Follow-up Date. The Action Item ID may be recorded in the Action Item XREF for the applicable requirement(s). The requirement status of Research may be requested from the JRC. If the Action Item is resolved prior to the JRC meeting date, the requested status may be adjusted based on the Action Item resolution.

A requirement status of Deferred may be requested for requirements that need to be addressed in a later phase of work. These requirements may or may not require an Action Item depending on the circumstances. At a minimum, a requirement comment should be added to clarify the reason for deferring the requirement and an appropriate Follow-up Date should be provided.

Requirements mutually agreed to be inaccurate or no longer necessary should be requested as Rejected by the JRC. A concise explanation should be provided to justify the rejection of the requirement. Rejected is an inactive status meaning no further work will occur. Any traceability that may exist should be removed to prevent confusion.

In the event a requirement is identified as duplicating or overlapping another, the requirement should be requested as a Duplicate. The duplicated requirement must be cross-referenced to the original requirement ID so that the duplication can be confirmed during the JRC. A concise explanation should be provided explaining the similarity. Each Duplicate requirement should include a reference to at least one original requirement ID or more if applicable. Requirement wording changes may also be proposed as necessary to avoid overlap. Duplicate is an inactive status, so no further work will occur, and traceability should be removed.

JRC Process

The JRC Process is administered by a small committee of SCDHHS staff to monitor the queue of requested requirement updates. Vendor and SCDHHS may submit requirements to the queue. The JRC calendar will be published in advance and special meetings may be convened to address emergency items or bulk changes.

The primary intent of the JRC process is to promote communication and manage requirement changes in a formal and rigorous manner. A defined subset of requirement attributes is subject to JRC control including requirement text and status. Specific requirement attributes are used to identify the requested requirement status and explain the change requested. Refer to Appendix A – DevOps Requirement Attributes for additional details. The JRC queue is monitored closely and reported on a minimum weekly basis.

Proposed JRC changes are communicated via email to the JRC distribution list that spans DASH stakeholders in advance of the meeting to allow preparation and review. During JRC, changes are reviewed, and requirement updates are approved, denied, or allowed further time for research as needed. After each JRC meeting, a listing of all changes is published and maintained in SharePoint for audit purposes. This listing is also emailed to the full JRC distribution list to promote communication within and across DASH sub-projects. The process to administer JRC changes includes monitoring of requirement volatility.

Requirement Changes

Once a requirement status has been updated from Draft to Analyzed by the Vendor, subsequent status updates must be approved by the JRC. Changes related to specific attributes for RFP, Change Request, and Federal Certification must be submitted to the JRC queue. SCDHHS will work with each Vendor to assess the impact of requirement changes to traced work products and artifacts.

Requirement Baselines

Requirements will be baselined at major milestones (such as Phases) in accordance with the Project Schedule as agreed upon with SCDHHS and the Vendor. Baselined requirements are deemed to be stable individually and as a group. Baselining approved requirements helps support impact analysis and downstream SDLC activities including Regression Test and any automated testing. SCDHHS will work with the Vendor to define the mechanism to create and manage requirement baselines in accordance with the Requirement Repository capabilities. Baselines are requested and approved via the JRC process.

Requirement Traceability

Accurate requirement traceability is critical to support downstream SDLC activities associated with Design, Development, Testing, Training, OCM, and Certification. Approved requirements must be linked per the DASH Traceability Model. Non-approved requirements should remain unlinked to minimize confusion and to support accurate generation of a Requirements Traceability Matrix (RTM).

2.2 Requirement Sources

Requirements may originate from the following sources:

RFP/Contract requirements (including Record of Negotiations (RON))

Approved Project Change Requests

Federal Certification requirements

JAD/Requirement review (RQ Review) o Validated requirements elaborated from RFP and Federal Certification requirements as needed

2.3 Requirement Types

Requirement type describes the nature (versus the source or point of origin) of the requirement. The requirement type may determine the means of validation and type of artifact or work product used to satisfy the requirement. Different participants or groups may be involved in the requirement review process depending on whether the requirement is business or technically oriented. The JAD will be tailored as follows for Functional and Non-Functional requirements.

Functional Requirements Functional requirements are business-oriented and describe DASH -related tasks to be performed in terms of business processes, calculations, user interactions, etc. JADs for Functional requirements include review of SCDHHS business/policy documentation, transactional legacy data, process flows, SME functional knowledge, etc. in the context of RFP and Federal Certification requirements that specify “what” is needed.

Vendor staff may subsequently illustrate “how” the requirement is expected to be met using business flows, application/component demonstrations, application functional documentation, job aids, staff industry knowledge, and best practices from other States during Design sessions.

Demonstration of Vendor components should assist SCDHHS in vetting/elaborating RFP requirements, ensuring compliance with Federal Certification requirements, and planning User Acceptance Test (UAT). Demonstrations are expected to occur during Design or as agreed upon by SCDHHS and each Vendor.

JADs will include review of RFP, Change Request, and Federal Certification requirements to elaborate Validated requirements at an agreed upon level of detail. Each discussed requirement will be assigned a proposed status during the session with the goal of obtaining SME validation and subsequent JRC approval as quickly as possible.

Requirements requiring follow-up or research will be managed via the appropriate requirement status and the Action Item process.

Non-Functional Requirements Non-Functional requirements address system quality and standards and tend to be more technical or operational in nature than Functional requirements. Examples of Non- Functional requirements include those that address performance/SLA, capacity, availability, reliability, data integrity, etc. Non-Functional requirements are often sub-divided to specific sub-types to heighten focus on what is usually a relatively smaller, but critical, volume of requirements.

JADs for Non-Functional requirements may be attended by SMEs/specialized groups with functional and/or technical skillsets. These requirements may be traced to or satisfied by policy documents, Project Plans, application components, and technical tests to address items such as network/architecture security requirements, conversion requirements, or screen response time. Non-Functional Federal Certification requirements may be associated with Internal Revenue Service (IRS) safeguard requirements, Health Insurance Portability and Accountability Act (HIPAA), and Section 508 compliance and Americans with Disabilities Act (ADA) legislation.

Non-Functional JADs may be limited to relatively smaller groups of specialized SMEs that may require subsequent system demonstrations during the Design Phase. JADs may focus on technical or operational capabilities with technical or plan-based supporting artifacts. The SME validation and JRC confirmation process will be used to gain approval for Non-Functional requirements in the same manner as Functional requirements.

Approved Non-Functional requirements will be traced as appropriate to System Plans, Components, and Tests and included in the RTM. There are no defined constraints related to the validation or testing of Non-Functional requirements. Validation should be assessed on a case-by-case basis and may include Plan review, inspection of technical data/configuration, technical testing, functional testing, or a combination of these.

During the process to elicit detailed Validated requirements, it is necessary to identify the nature of each requirement as Functional or Non-Functional irrespective of the Source (or parent) requirement type. Non-Functional requirements may be further classified as Performance, Operational, or Usability, etc.

Performance requirements should be captured in a manner that clearly defines the business need (what needs to be done) as well as the means to measure or calculate the outcome (such as a report or dashboard). The requirement that captures the business need should be classified as Functional or Non-Functional as agreed upon during JAD.

The requirement that documents the means to measure or communicate the outcome should be classified as Performance.

2.4 Requirement Status Definitions

Requirements are managed according to defined status values within the requirement lifecycle. Draft is the defined default values for newly entered requirements. Prior to JAD, each requirement must be set to Analyzed by the Vendor. All subsequent requirement status value updates must be formally confirmed through the JRC process prior to update.

DevOps State

Definition Li nk ed

Ac tiv e?

Re qu ire s J

RC

Ap pr ov al

Approved Requirement has been validated during JAD and subsequently approved during JRC; Approved requirements may proceed through the SDLC for downstream activities with required traceability developed and maintained

Yes Yes Yes

Deferred Requirement will be addressed in a later phase as approved based on joint review between SCDHHS and the Vendor

No Yes Yes

Draft Requirement has been newly imported and assigned this default value

No Yes No

Duplicate Requirement overlaps or duplicates a previously documented requirement; Must be cross-referenced to the original requirement via by DUP XREF

No No Yes

DevOps State

Definition

Li nk ed

Ac tiv e?

Re qu ire s J

RC

Ap pr ov al

Analyzed Requirement has been internally reviewed by the Vendor and is ready for discussion in a JAD

No Yes No

Rejected Requirement has been deemed unnecessary, incorrect, or lacking sufficient detail

No No Yes

Research Requirement needs follow-up or review; A Follow-up Date must be provided

No Yes Yes

2.5 Requirements Configuration Management

Requirements Repository Capabilities SCDHHS uses DevOps as the Source of Truth for DASH requirements. Vendors using an alternate tool for requirements management should work with SCDHHS to obtain approval and ensure that that following key capabilities are supported:

• Bi-directional traceability

• Data entry

• Import/Export

• Customizable attributes

• Baseline generation

• Scalable to support multiple users

• Security

• Reporting

• Audit Trail

• Backup/Restore SCDHHS will work with each Vendor to document the approach to backup and restore requirements data to support recovery in the event of a data loss or tool issue. Vendor requirement text and status must remain synchronized with SCDHHS DevOps requirement text and status.

Requirement Artifacts Repository Artifacts and work products created to support the SDLC phases for Requirements, Design, or Development are subject to configuration management that supports versioning such as a SharePoint document library. These artifacts must be traceable from requirements and/or components using requirement attributes or a naming convention that supports review based on the requirement ID, component name, or JAD

Date. It is recommended that a folder structure or index be utilized to group documents according to agreed-upon characteristics such as Functional Area, component, etc.

SCDHHS will work with each Vendor to confirm adequate configuration management is in place prior to conducting JADs. It must be possible to identify the version of an artifact associated with a requirement at the time of approval.

Requirements Tool Usage and Configuration The Vendor will collaborate with SCDHHS using DevOps for requirements management or utilize a Requirement Repository as approved by SCDHHS for requirements storage, linking, versioning, and management. The Vendor will link requirements artifacts to other artifacts created downstream of the requirements process and manage the versioning of these other artifacts within the Requirements Repository or other appropriate location such as SharePoint.

The Vendor must work with SCDHHS to establish user access to any alternate Requirement Repository including appropriate group and individual access and permissions based on the tool capabilities. An audit trail must be provided for requirement update including date, time, user, change type, change content, etc.

Key Requirement Attributes An appropriately robust set of requirement attributes is necessary to support numerous aspects of requirements management to support the overall workflow, status reporting, and traceability. The following table reflects key requirement attributes that support the overall approach to requirements management defined in this Plan.

SCDHHS will work with each vendor to review the significance of each attribute to identify equivalent Vendor attributes/values as necessary.

This list is intended to serve as a guide for a complete list of requirement attributes.

Refer to Appendix A - DevOps Requirement Attributes for a complete listing.

Recommended Attribute

Definition Values JRC Approval?

ID Requirement ID No Title Introductory requirement text No

Functional Area High-level business or functional area that provides high-level requirement context as defined by SCDHHS

As defined in the Source document or JAD

Yes

Business Process

Business process or mid-level of detail that provides requirement context; May map to a process flow

No

Recommended Attribute

Definition Values JRC Approval?

Business Task Specific task or step within a business process that provides lowest level of detail for requirement context

Description Requirement text as written in the Source requirement or authored in the JAD

Yes

RQ Comments Useful and necessary comments added during requirement validation by SCDHHS or Vendor;

Comments should not alter the requirement or include lengthy information

Source

Origin of the requirement

RFP No

RON

Federal Certification Change Order RQ Review

Type Nature of the requirement;

Non-Functional may be further refined to Conversion, Performance, Operational, Technical, or Usability, etc.

Functional Yes Non-Functional Performance Operational Technical Security Usability Conversion

Coverage Status Describes the extent to which the requirement is addressed by the donor system functionality

<blank> No Question Addressed Accept Donor Gap

State Requirement lifecycle value

*JRC approval not required to set Draft or Analyzed

Analyzed *Yes Approved Deferred Draft Duplicate Rejected

Recommended Attribute

Definition Values JRC Approval?

Research Follow-up Date Future date to revisit the requirement No

Owner Entity that will implement requirement

As agreed upon with SCDHHS and Vendor

Yes

Phase Phase of the project where the requirement will be addressed

As defined by SCDHHS project PM

Yes

Proposed JRC Change

Used to capture non- State attribute change values including Description, Type, Phase, etc.; These values will be updated during JRC, and this field will be cleared and reset to blank after JRC

No

Proposed JRC Status

Used to identify a suggested change to current requirement status; Will be reset to blank after JRC change

<blank> No Analyzed Approved Deferred Duplicate Rejected Research

Priority Rank of relative requirement importance with 1 being highest

1 No

Baseline Date Date the requirement was baselined

Yes

3.0 Requirement Activities

Requirements are subject to multiple reviews and maintenance activities throughout the requirement lifecycle to confirm business needs are accurately captured, implemented, and traced. These reviews and activities include the following:

• Requirement Validation (via JADs)

• Requirement Elaboration according to DASH Writing Standards and Conventions

• Formal Requirement Approval via JRC

• Ongoing Requirement Management

• Establishment of SDLC Requirement Traceability

3.1 Requirement Validation

Requirements are reviewed during Vendor-led JAD sessions. The table below identifies the key activities required to plan, conduct, and document each JAD.

RQ Activity Owner Task Comments

Plan JAD Session Vendor Review Draft RQs; Set to Analyzed

Schedule session

Provide agenda/requirements listing/supporting documentation

Share questions in advance Timeframe as agreed upon

Develop Component Inventory or defer this activity to the Design Phase as agreed upon with SCDHHS

Prepare to Attend JAD Session

SCDHHS Share business documentation in advance

As Is/To Be/Process Flows, Business and Policy Docs, Legacy Transactions/Data, Business Rules, etc.

Review Agenda and Requirements; Confirm correct SMEs invited

Provide feedback as necessary

Conduct JAD Vendor Validate each requirement RFP/RON, Change Request, and Federal Certification

Elaborate requirements as needed and capture required attributes

Functional Area, Business Process, Business Task, Description, Priority, etc.

Capture RQ Status recommendations by SMEs;

Capture comments/Action

Update RQ attributes during session

RQ Activity Owner Task Comments Items for non-Approved requirements

Attend JAD SCDHHS SMEs validate each requirement; Recommend RQ status

Approved, Research, Rejected, etc.

Identify topics requiring escalation; Collaborate on Action Item Due Dates

Post JAD Vendor Confirm Proposed Status values set for each requirement

Submit Action Items, Minutes as agreed upon

Ensure tool updates are completed

Attend JRC

Requirement Approval

SCDHHS

JRC

Establish meeting calendar;

Invite DASH Stakeholders

Discuss Proposed Updates

Publish Proposed/Approved RQ Updates

Requirements Traceability

Vendor Link Approved Requirements Trace as needed to support DASH Traceability Model

Confirm accurate versioning and traceability for RQ Artifacts

Generate RTM

Validate Traceability SCDHHS Support RTM generation

Review RTM

Review RQ reports/metrics

3.2 Requirement Elaboration

The Vendor SMEs are responsible for the development and ongoing management of Validated requirements utilizing the approach and process defined within this document to create requirements.

Writing Requirements Validated requirements are captured during JAD discussions by the designated Vendor team member. Additional Validated requirements may be identified after the JAD has concluded or downstream SDLC activities are underway if required for clarity. All requirements are subject to SCDHHS SME validation and JRC review and approval.

The DASH approach to writing validated requirements is intended to yield concise, consistent, and modular requirements that are capable of being maintained and used throughout the SDLC. The objective is to document desired system capabilities using business terminology commonly understood by system users. These capabilities are documented as requirements that specify “what” the system must do to meet user needs.

These requirements serve as input to the Design process that determines “how” each requirement will be met. The following requirement guidelines and evaluation criteria are provided to facilitate the process of writing and reviewing requirements.

Requirement Context Requirements are documented prior to and/or during facilitated JADs focused within a particular Functional Area/Business Process. Session participants walk through business flows or other applicable artifacts and discuss each RFP, Change Order, or Federal Certification requirement to confirm the business need is clearly stated or elaborate for clarity as needed.

Each requirement is captured and assigned a context consisting of Functional Area, Business Process, and Business Task intended to generate concise requirement statements. A context example and sample requirement are provided below:

Attribute Definition Sample Business Requirement Functional Area High-level business area Provider Business Process Specific business process Enrollment Business Task Detailed business task Enrollment Workbench Search

Functionality Requirement Text Statement of business need Allow user to view submitted enrollment applications

Defining the requirement context allows grouping of requirement subsets and enables most requirements to be relatively short statements consisting of five to ten words. This helps clarify relationships to other requirements and supports traceability to subsequent work products from a high, medium, or low level of detail.

Recommended Preparation for Writing Requirements It is recommended the Vendor prepare for writing requirements with the following items in mind:

1. Collaborate with SCDHHS SMEs as needed to research the topic:

• Have a working understanding of the Source requirements and business flow

• Understand the appropriate level of detail for capturing requirements for business process/tasks

2. Understand and document assumptions:

Be aware when an assumption is required or being made and discuss the SDLC impact Example: Business requirement related to up or downstream interface solution provider such as MES, SCEIS, or BIS

3. Interpret and generalize:

• Discuss the specific scenario until the underlying business requirement is understood rather than capturing a specific comment or discussion point; It is sometimes necessary to discuss one or more requirements in detail in order to understand how to generalize a requirement to a specific capability Example: Numerous types of activities may share common parameters such as type, status, location, etc. and these parameters may be documented as individual requirements or by defining the business outcome as needed

4. Avoid Design-level requirements identified post JAD:

• Refrain from adding new requirements identified during Design activities such as sorting or display formats unless they were discussed as meeting a business need during requirement validation Example: Sort parameters or display format (MM/CCYY)

DASH Requirement Writing Guidelines

1. Follow preparation steps.

2. Begin with a verb.

3. Provide context. (Functional Area + Business Process + Business Task + Requirement

Text)

4. Describe the “what” not the “how.”

5. Eliminate unnecessary words.

6. Write singular requirements. Avoid compound statements/conjunctions (and, or, etc.)

7. Use independent, non-overlapping statements.

8. Avoid Design references.

9. Review list of words to use and to avoid.

10. Include detailed information as an RSD/supporting document when a requirement has multiple permutations or scenarios.

Words to Avoid The following table provides a list of words that should not be used when elaborating requirements with an explanation for the project-defined convention or standard.

Avoid Reason Additional Write single requirements and avoid general terms All Avoid absolutes and define boundaries

Avoid Reason Always Avoid absolutes and define boundaries And Avoid conjunctions by writing single requirements Approximately Avoid general terms As Well As Write single requirements and avoid general terms Consider Avoid general terms Etc., So on, So forth Avoid general terms Except Avoid escape clauses Expect Avoid general terms; Relates to an assumption Generally Avoid general terms If Avoid building in exceptions or escape clauses Necessary Avoid general terms and be specific Never Avoid absolutes; Use “Do not” Normally Avoid general terms Or Avoid branching to different outcomes within one requirement Parenthetical Statements

Avoid use of parentheses except to define common acronyms; Supplemental information can be listed in the requirement comments in the rare instances where this is necessary

Recognize Avoid general terms References to Vendor name

Avoid use of Vendor name associated with past and future applications and capabilities; If needed use terms such as “legacy” to identify existing functionality

Should Be Avoid general terms; Relates to an assumption The system must Project convention to begin requirements with verb and be concise The system shall Project convention to begin requirements with verb and be concise Whenever Avoid general terms

Words to Use The following table provides a list of words recommended for use when creating DASH requirements to promote consistency and clarity. It is intended for use as a guide to support elaboration of requirements and preparation for JADs.

Word Intended Meaning Example Accept Allow receipt of data Accept paper claim submission.

Add Allow entry of an additional record or information

Add an incoming worker update as pending when the source does not match an existing Provider.

Alert Notify user Alert the Provider when a worker is late for a visit.

Allow Accept or support a condition Allow a future date for a scheduled visit.

Word Intended Meaning Example Allow only one active Mailing Address for each member.

Allow multiple employees for the same employer.

Allow the user to identify a payment to a member ID.

Archive Move active data to storage Archive reports after 30 business days.

Assign Set value Assign a unique Member ID.

Automatically accept

Recommended to emphasize automated system functionality

Automatically accept an unsolicited proactive data match from interface partner.

Calculate Perform mathematical operation Calculate claim amount based on authorized units.

Capture Accept as in data entry Capture Reviewer Comments.

Default Initially assigned value Default a dependent member's emancipation date to date of birth plus 18 years.

Define Set a system value or business condition

Define a pending Address as not verified.

Display Allow user to view Display list of submitted claims.

Do not allow Prohibit an action Do not allow a case to be closed with active Wage Withholding.

Do not require Allow an action or override a restriction

Do not require authorization for administrator.

Generate Produce an output Generate letter to provider when re-validation has been denied.

Indicate Visually identify Indicate that a member address received from an external source has been verified.

Maintain Allow user to log, add, or update Maintain mailing address.

Require Enforce as mandatory Require an Effective Date when posting a receipt.

Update Accept a new value Update blank Member date of birth with incoming date of birth.

Upload Allow import Upload Re-validation denial letter to Provider Portal.

Validate Use this verb instead of Edit. Use this verb when we are validating/editing something.

Validate Provider FEIN.

When Time-based or situational condition When an error occurs within a database transaction, the entire transaction should be rolled back.

Desirable/Undesirable Requirement Example Assuming that context is properly defined by Functional Area, Business Process, and Business Task, the following sample RFP requirement illustrates a desirable and undesirable requirement in terms of detail and ambiguity. Note that this example illustrates multiple common source requirement issues.

Undesirable Requirement Comments Desirable Requirement

RFP 3.4.3

Contractor will not directly interface with SCDHHS’ accounting and finance system.

Contractor will provide an extract of Claims that are awaiting payment. This extract of Claims awaiting payment will be an interface in X12 837 format or a mutually agreed upon format.

Frequency of these submissions is daily.

This is a compound requirement and requires SME clarification.

The first sentence is written as a negative statement and may be informational.

The third sentence is ambiguous due to the “or” clause.

It is unclear whether the fourth sentence is informational or should be reflected as part of the requirement or a separate requirement.

Assume SME confirms

- Sentence 1 is informational

- Sentence 4 is not informational

Vendor confirms requested format

Recommended text Provide a daily extract of Claims awaiting payment in X12 837 Format.

Also recommend capturing RQ comment “Contractor will not directly interface with SCDHHS’ accounting and finance system.”

DASH Requirement Quality Criteria The following criteria are used to assess requirement quality. These criteria should be applied to an individual requirement by the author and subsequent reviewers prior to submission to JRC for approval. JRC review may include identification of requirement issues based on this listing.

Item Basis DASH Individual RQ Criteria 1 Complete Requirement fully defines desired capability within defined context of:

A. Functional Area B. Business Process C. Business Task D. Requirement Text

2 Correct Requirement accurately describes system functionality desired without conflict with other requirements

3 Concise Requirement expressed in simple terms with unnecessary words omitted

4 Business-Oriented Requirement uses business terminology and avoids Design references

5 Consistent Level of Detail

Requirement is documented at consistent level of detail

6 Consistent Terminology

Requirement uses consistent, defined terminology

7 Feasible Requirement can be feasibly implemented within budget, schedule, scope, and technical limitations

8 Scope Requirement is within defined DASH sub-project scope

9 Unique Requirement does not duplicate or derive from another requirement

10 Unambiguous Requirement is understood by SCDHHS SME contact/owner

11 Testable Requirement can be tested with pass/fail scenario

12 Traceable Requirement is written in singular (non-compound) form traceable to source and specific System Artifact, Design, Component, or Test

The following list of criteria is intended for use by requirement authors and reviewers when evaluating sets of requirements such as a baselined group of requirements.

Item Basis DASH Criteria for a RQ Group 1 Group is Complete Requirements fully define desired capability within defined context of A. Functional Area B. Business Process C. Business Task D. Requirement Text

2 Group is Correct Requirements accurately describe system functionality desired without conflict/overlap with other requirements

3 Group has Consistent Level of Detail

Requirement set is documented at consistent level of detail

3.3 Requirement Approval – JRC Process

The JRC process governs requirement updates to support consistency, communication, and configuration management. Funneling all requirement updates through a broad audience and a small set of approvers promotes visibility for project stakeholders. The small set of approvers help drive consistency by reviewing and discussing all proposed updates. SCDHHS will work with each Vendor to ensure the JRC process is streamlined and efficient. The JRC Queue is subject to continuous monitoring to avoid bottlenecks. While in the JRC Queue, a proposed requirement update can be modified or removed from the Queue.

Once the Vendor has set a requirement to Analyzed, all subsequent updates must be validated with a SME and approved by the JRC. Figure 2 - JRC Process provides an overview of the JRC Process.

Figure 2 - JRC Process

This process is managed using three requirement attributes to define the JRC Queue as defined in the table below and is conceptually the same regardless of the status value or update requested. If the JRC denies a request, the request is withdrawn, and the original values remain. If necessary, a clarified request may be submitted for further JRC consideration.