RMsis support for CMMI RD and REQM Process Areas

CMMI is the standard of choice for many mature Software Engineering Organizations across the world and it is used extensively to benchmark and improve the Software Engineering Practices. In this article, we present a summary of how RMsis can potentially support the goals and practices laid out by CMMI; for Requirement Development and Requirement Management.

This document corresponds to Version 1.5.0 of RMsis and applies equally to CMMI V.1.2 and CMMI-DEV V.1.3

Assumptions

It is assumed that the following Products are installed on a Server, which is accessible to the entire Project / Product Team, depending upon the role of an individual.

Essential
- RMsis
- Atlassian JIRA
Desirable
- Confluence Wiki from Atlassian (for Managing Documentation)
- Note : Confluence is not essential, but is highly recommended, since it supports collaboration and close integration with JIRA ecosystem will be used in future versions of RMsis.

Summary

Requirements Management (REQM)

Purpose : The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

Please note that the following documentation assumes that the Requirements Database is transparently shared with the customer.

SG / SP	Description	Notes and Recommendations for using RMsis	Document Reference
SG 1 Manage Requirements	Requirements are managed and inconsistencies with project plans and work products are identified.	Requirement Management is the central theme of RMsis. The entire set of requirements are managed in: Unplanned Requirements Table Planned Requirements Table Broadly the following functions are also provided Analysis of Requirements Version control and Baselining of Requirements Forward and reverse Traceability between requirements and with other Artifacts Mechanism for Requirements Validation Issue tracking (including task Tracking) is done through JIRA, which is tightly coupled with RMsis	RMsis User's Guide
SP 1.1 Understand Requirements	Develop an understanding with the requirements providers on the meaning of the requirements.	Requirement Providers are explicitly identified (as Customers / Analysts / Team Members) and the requirement ownership is tracked, throughout the lifecycle of the requirement. RMsis provides some default attributes to analyze the requirements in the Planned Requirements Table. If required, users can define custom attributes for further analysis. Either the comments column OR comments in JIRA issues can be used for capturing the discussion related to a Requirement. Acceptance criteria can be created as a set of Test Cases, mapped to the Requirement. The deviations / issues against a requirement can be managed through Issue Tracking System and tracked to closure.	Capturing, Analyzing and Managing Requirements
SP 1.2 Obtain Commitment to Requirements	Obtain commitment to the requirements from the project participants.	Agreements on requirements can be maintained through version control and baselining of requirements. Customer approvals can be recorded as JIRA issues associated with the requirement.	Requirement Versions, Baseline and History
SP 1.3 Manage Requirements Changes	Manage changes to the requirements as they evolve during the project.	System provides for version control of requirements and records change history. Customer approvals can be recorded as JIRA issues associated with the requirement.	Requirement Versions, Baseline and History
SP 1.4 Maintain Bidirectional Traceability of Requirements	Maintain bidirectional traceability among the requirements and work products.	System provides for Bidirectional Traceability Between Requirements Requirements, Test Cases and Issues (between all three) Releases and all other entities in the system.	Requirement Attributes Requirements Traceability
SP 1.5 Ensure Alignment Between Project Work and Requirements	Identify inconsistencies between the project plans and work products and the requirements.	All JIRA tasks (which implement requirements) are mapped to requirements and tracked in various views.	Requirements Traceability

Requirements Development (RD)

Purpose : The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

SG / SP	Description
SG 1 Develop Customer Requirements	Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
SP 1.1 Elicit Needs	Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
SP 1.2 Transform Stakeholder Needs into Customer Requirements	Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.
SG 2 Develop Product Requirements	Customer requirements are refined and elaborated to develop product and product component requirements.
SP 2.1 Establish Product and Product Component Requirements	Establish and maintain product and product component requirements, which are based on the customer requirements.
SP 2.2 Allocate Product Component Requirements	Allocate the requirements for each product component.
SP 2.3 Identify Interface Requirements	Identify interface requirements.
SG 3 Analyze and Validate Requirements	The requirements are analyzed and validated, and a definition of required functionality is developed.
SP 3.1 Establish Operational Concepts and Scenarios	Establish and maintain operational concepts and associated scenarios.
SP 3.2 Establish a Definition of Required Functionality and Quality Attributes	Establish and maintain a definition of required functionality.
SP 3.3 Analyze Requirements	Analyze requirements to ensure that they are necessary and sufficient.
SP 3.4 Analyze Requirements to Achieve Balance	Analyze requirements to balance stakeholder needs and constraints.
SP 3.5 Validate Requirements	Validate requirements to ensure the resulting product will perform as intended in the user's environment.

Notes and Recommendations for using RMsis

Requirements Development is largely a manual process, with minimal support required from the tool. The following recommendations can help in achieving the desired outcomes (across SG's / SP's of RD)

Use the Hierarchical Structuring Capability of RMsis to develop a Hierarchy of Needs. A typical structure would look like the following
- User Inputs
  - Goals
    - ...
    - ...
  - Needs
    - ...
    - ...
  - Expectations
    - ...
    - ...
  - Constraints
    - ...
    - ...
  - Interfaces
    - ...
    - ...
- Customer Requirements
  - User Function 1
    - ...
    - ...
  - User Function 2
    - ...
    - ...
  - User Function n
    - ...
- Product Requirements
  - Functional
    - Component-1
      - ...
      - ...
    - Component-2
      - ...
      - ...
    - Component-n
      - ...
      - ...
  - Non Functional
    - ...
    - ...
  - Interface
    - ...
    - ...
Identify the dependencies between various levels of Requirement Hierarchy. This will help in ensuring that the higher level goals / needs are met.
RMsis provides some default attributes to analyze the requirements in the Planned Requirements Table. If required, users can define custom attributes for further analysis.
Requirement Categories can be created and used for ease of filtering.
Use Confluence for creating documenting and maintain links of the same with requirements.
Use Case documentation should be included, preferably at Customer Requirements level.
Develop a set of test cases and map them to Requirements to ensure completeness of validation.

RMsis Application Notes