Version Management of Requirements

This document explains the version management of Requirements in RMsis and it would be available from RMsis V.1.2.0 onwards.

The following presentation demonstrates a complex case of managing multiple versions of a requirement within a release as well as across releases.

RMsis Versions and Baseline - 1-4-1.pptx

Overview of Implementation

RMsis implements the requirements versions as follows:

General
1. An entity, with at least one committed version will be declared as a committed requirement and will continue in the same state for ever.
2. An entity, with no committed version can be treated as a container OR a requirement.
  1. However, it will be treated as a container, when child requirements are assigned to it.
3. All versions of a requirement will be bundled together.
  1. This implies that at any point of time, a requirement set will have only one unique hierarchy.
  2. Certain operations, which are likely to create confusion (like Indent / Outdent / Move) will be disabled in "All Versions View".
4. Effort computation at the parent level is suppressed for now.
States
1. A requirement version can have the following states
  1. Editable
  2. Non-Editable / Committed
  3. Archived - Remove from the main table view (this function is not available from RMsis 1.2.0 till this release)
  4. Multiple versions can be in editable state (say versions of a requirement allocated to Alpha / Beta release)
2. State of a Requirement comprises of
  1. the values of it's attributes
    1. Summary
    2. Description
  2. links to the associated documents
  3. use cases defined for the requirement (this function is not available in RMsis 1.2.0 till this release)
  4. links to Requirements, most notably
    1. linked requirements (on which this requirement depends on)
    2. preceding version
3. User analysis (perceived) data is excluded. This includes
  1. Feasibility
  2. Effort
  3. Priority
  4. Criticality
  5. Comments
  6. Release
  7. State
4. The following links are external and do not affect the state of a requirement
  1. Other associated artifacts like bugs, feature requests, change requests.
  2. User comments
  3. Release
  4. Categories
  5. Baseline
  6. History associated with the requirement. The history will be maintained for the lifetime of a specific version of a requirement.
5. When a requirement is committed, it's links are frozen.
  1. However, if the document is maintained at an external location, the user has to make sure that the document version is preserved.
6. All parents will be stateless. Which means that their versions will not change and they will always be in editable mode. In a way, they can be considered as containers.
  1. the latest hierarchical structure will prevail for all views.
  2. Underlying requirements and their versions can change.
  3. documents attached to parent requirements will always be editable.
7. All state changes require explicit user action.
  1. We should notify the user about any side effects it has. For example, while copying requirements, a copy of all linked and frozen requirements is automatically created.
The system allows creation of multiple versions.
1. At the requirement level, the user will have an option to
  1. Create another version on the existing branch.
  2. Create another version of a committed (non-editable) version of the requirement.
    1. This will effectively fork a new branch but branch-id's are not being displayed for maintaining simplified versioning scheme.
  3. The evolution of requirement can be viewed in the detailed view of a requirement.
2. Branches of a requirement can be created across projects. (However this feature is not available in RMsis V.1.2.0).
3. Requirement ID will remain same across all the projects.
Version Numbering
1. The versions will be auto numbered and sequential.
2. The source information for a version will be stored in database.
3. Creating version from the latest version of a requirement will create a copy in the same branch. For example
  1. "Create Version" from R2-V3 will create R2-V4
4. Creating version from an old version will fork a new branch.
  1. "Create Version" from R2-V3 again will create a new branch for R2-V5 with R2-V3 as the source.
5. Manage versions & baseline only at the requirement level
  1. Requirements will exist at the leaf level and cannot be converted to a parent / container.
6. The detailed view of the requirement will show evolution tree for the requirement.
7. All cross referencing will be with respect to versions (where applicable).
User Actions and State Transitions
1. Multiselect feature will work for all the versioning related operations.
2. Create another Version
  1. This ensures that the current version should be in committed state.
  2. Carries over all attributes and links to the newly created version.
  3. Version can be created only for a requirement at the leaf level and not for a parent / container.
  4. The state of a newly created version is set to Open.
3. Commit Requirement
  1. Change the state to Non-Editable. This Requirement state will be preserved.
4. Linking another requirement to a Committed Requirement
  1. A link is created and it is not necessary to create another version of the committed requirement.
  2. An instance of a requirement can be deleted only if itself and the tree beneath does not include a committed / non-editable requirement
5. Move | Cut - Paste
  1. All versions of a requirement are bunched together. Hence a move will move all the versions of a requirement.
  2. Parent / container can be moved, irrespective of the state of underlying requirements.
6. Indent / Outdent in the context of versioning
  1. A requirement cannot become a parent, if any of it's versions are committed.
  2. If the current version is in Editable mode, no new copies are created and the links to parents are rearranged.
  3. Indent / Outdent will be contextual... will work, based on the current view of the user.
7. Baseline
  1. If the selected version is in Editable mode, then the version is committed.
  2. If the selected requirement is in Non-Editable / committed mode, then it's state remains unchanged.
  3. If a parent is selected, all descendants at leaf level are Baselined.
  4. There is no impact on the other children of ascendants.
  5. If multiple versions of a requirement are included in a baseline, system should generate a warning to the user.
Links will have types and can have attributes unique to the type.
Parent Child relationship
1. A child inherits the description associated with the parent. This includes attached documents.
2. Other links to test cases, code, design etc have to be explicitly specified by the user.
3. Certain properties for parent cannot be specified by the user.
Inter project dependencies can be specified.
Assigning multiple versions of the same requirement to different releases
1. The user can specify this.

Overview of User Interface

Latest View
1. Latest version of a requirement, which is at the leaf level, will be displayed.
View of Multiple versions in a single table
1. There will be an option to view all versions of requirements.
2. All versions of a requirement (which are not archived) will be displayed.
3. The display will be sorted by version number, irrespective of the time of creation.
The requirement Id column will include the version information.
UI elements
1. User Options
  1. Create a Version
  2. Commit Version
2. Provide these options in
  1. Context Menu
  2. Version & Baseline (Dropdown Options)

Scope

Baseline scope is restricted to Requirements only.
It includes Use Cases (not available from 1.2.0 till this release).
Versions of other artifacts like issues, feature requests will not be managed in the current version of RMsis.
Versioning of test cases are available from v.1.3.1 onwards, and it is user's responsibility to maintain those.