Child pages
  • The purpose and context for Unplanned Requirements in RMsis
Skip to end of metadata
Go to start of metadata

Why should RMsis have Planned and Unplanned tables for managing requirements ? This article attempts to provide an answer to this question and tries to clarify the context and need for the Unplanned Requirements Table.

However vision for the "Planned Requirements Table" is presented first, which sets the context for rest of the article.

What should be the User Expectations from Planned Requirements Table ?

In the new Agile world, Planned Requirements Table is the center of activity in RMsis and is used for the following key activities:

  • Structuring the requirements hierarchy from Goals to Product features.
  • Maintaining Product Backlog
  • Analyzing Requirements
  • Allocating Requirements to Releases
  • Tracking Requirements Development
  • Controlling the development of requirements through versions and baselines

Given the spectrum of these activities, the following default permissions are configured:

  • Edit / Delete permissions for All Requirements to Managers
  • Edit permissions for Allocated Requirements to Analysts, who are responsible for Requirement Development
  • View permissions to the entire Development / Testing teams for All Requirements.

What are the issues with Planned Requirements Table ?

Given the fact that Planned Requirements Table is central to the entire Product Planning Process, the following issues emerge:

  1. All developers cannot be given editing /creation rights in the Planned Requirements Table, since it may lead a constant and unwanted churn in this table. This is especially true for immature organizations.
  2. The Planned Requirements Table cannot be exposed to customers, since it may contain confidential information from Organizational Viewpoint.

The need for Unplanned Requirements Table

We foresee at least two compelling reasons for Unplanned Requirements Table to exist

  1. It can be a great mechanism to collect constant input from Customers and Development / Testing Team Members, who are not allowed to enter their ideas directly in the Planned Requirements Table.
  2. An Analyst can conduct a preliminary analysis of the submitted requirement and accordingly change the status.

Eventually the valid / useful requirements can be moved into the Planned Requirements Table and allocated to releases after analysis and prioritization.

Typical Workflow in Unplanned Requirements Table

  1. RMsis Administrator assigns Edit / Delete permissions to Customers and Development / Testing Team members.
  2. Each one of these users can View / Create / Edit / Delete the requirements, for which they are the owners.
  3. Periodically an Analyst will scan the submitted requirements and identify the relevant ones as "Valid".
  4. The valid requirements are moved to the Planned Requirements Table where they eventually go through a elaborate analysis, development and implementation phase.

So, which functions are not relevant for Unplanned Requirements Table ?

Given the above context and the fact that Unplanned Table is only a temporary placeholder for requirements, we think that the following functions are not relevant in the Unplanned Requirements Table:

  1. For Customers (since they would not have a view of the Planned Requirements or JIRA Issues)
    1. Structuring of requirements
    2. Dependencies between requirements
    3. Links to JIRA Issues 
  2. For Development / Testing Team members
    1. Structuring of requirements


In case you have any feedback on the views presented here, please send a mail to


  • No labels