Child pages
  • RMsis support for CMMI RD and REQM Process Areas
Skip to end of metadata
Go to start of metadata

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


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.


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 / SPDescriptionNotes and Recommendations for using RMsisDocument Reference
SG 1 Manage RequirementsRequirements 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 RequirementsDevelop 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 RequirementsObtain 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 ChangesManage 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 RequirementsIdentify 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 / SPDescription
SG 1 Develop Customer RequirementsStakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
SP 1.1 Elicit NeedsElicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
SP 1.2 Transform Stakeholder Needs into Customer RequirementsTransform stakeholder needs, expectations, constraints, and interfaces into customer requirements.
SG 2 Develop Product RequirementsCustomer requirements are refined and elaborated to develop product and product component requirements.
SP 2.1 Establish Product and Product Component RequirementsEstablish and maintain product and product component requirements, which are based on the customer requirements.
SP 2.2 Allocate Product Component RequirementsAllocate the requirements for each product component.
SP 2.3 Identify Interface Requirements

Identify interface requirements.

SG 3 Analyze and Validate RequirementsThe requirements are analyzed and validated, and a definition of required functionality is developed.
SP 3.1 Establish Operational Concepts and ScenariosEstablish and maintain operational concepts and associated scenarios.
SP 3.2 Establish a Definition of Required Functionality and Quality AttributesEstablish and maintain a definition of required functionality.
SP 3.3 Analyze RequirementsAnalyze requirements to ensure that they are necessary and sufficient.
SP 3.4 Analyze Requirements to Achieve BalanceAnalyze requirements to balance stakeholder needs and constraints.
SP 3.5 Validate RequirementsValidate 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.




  • No labels