Page Comparison

This document explains the version management of Requirements in RMsis.

...

• Please note that the Baseline functionality has been improved and some new options/ features have been added related to baseline functionality in RMsis. 
• The below presentation is applicable to RMsis 1.8.7.1-r300 and previous versions. 
• An updated presentation corresponding to RMsis 1.8.8-r301 and later versions will be uploaded soon.

...

1. 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.
2. 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. 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. Links to other Requirements.
      2. Other associated artifacts like bugs, feature requests, change requests.
      3. User comments
      4. Release
      5. Categories
      6. Baseline
      7. 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. However,
      
      1. if the document is maintained at an external location, the user has to make sure that the document version is preserved.
      2. the dependencies between Requirements can still be edited.
   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.
3. The system allows creation of multiple versions.
   1. While creating versions of a requirement, two possibilities exist :
      1. Create multiple versions of a requirement on multiple branches.
         1. Here, the base version (say version 1) of the requirement is committed and multiple versions of requirement are created from this base version.
         2. This creates multiple branches.
      2. Create multiple versions of a requirement on a single branch.
         1. Here, versioning of requirement is done sequentially.
         2. Which means that you have a base version (say version 1) which is committed and then a new version (version 2) of requirement is created from this base version.
         3. Now version 2 of the requirement is committed and a new version (version 3) of the requirement is created from version 2.
         4. So, in this case, a single branch exists. 
   2. At the requirement level, the user will have an option to
      1. Create another version on the existing branch.
         1. This is an example of creating multiple versions of a requirement on single branch
            1. Suppose a requirement (say FIR-R17 {1}) exists and this requirement is committed.
            2. A new version of this requirement is created. The new version of requirement will be FIR-R17 {2}. 
               1. The above operation creates FIR-R17 {2} on branch 1.
            3. Now FIR-R17 {2} is committed.
            4. And then a new version of FIR-R17 {2} is created. The new version of requirement will be FIR-R17 {3}. 
               1. The above operation creates FIR-R17 {3} on existing branch 1.
            5. So by using the above feature, multiple versions of a requirement can be created on same branch.
               Image Added
      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.
         2. This is an example of creating multiple versions of a requirement on multiple branches.
            1. Suppose a requirement (say FIR-R18 {1}) exists and this requirement is committed.
            2. A new version of this requirement is created. The new version of requirement will be FIR-R18 {2}. 
               1. The above operation creates FIR-R18 {2} on branch 1.
            3. Now, a new version of requirement FIR-R18 {1} is again created. The new version of requirement will be FIR-R18 {3}.
               1. FIR-R18 {3} will be created on branch 2.
            4. So by using the above feature, multiple versions of a requirement can be created on multiple branches.
               Image Added
      3. The evolution of requirement can be viewed in the detailed view of a requirement.
   3. Branches of a requirement can be created across projects. (However this feature is not available in RMsis V.1.2.0).
   4. Requirement ID will remain same across all the projects.
4. 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).
5. 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 to the newly created version. Regarding the links / relationships, system will provide an option to select the ones desired to be carried over to the new 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 only a parent is selected, an error message will be returned to the user.
      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.
6. Links will have types and can have attributes unique to the type.
7. 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.
8. Inter project dependencies can be specified.
9. Assigning multiple versions of the same requirement to different releases
   1. The user can specify this.

...