Details of Requirement Version Management
This document explains the version management of Requirements in RMsis.
The following presentation demonstrates a complex case of managing multiple versions of a requirement within a release as well as across releases.
Overview of Implementation
RMsis implements the requirements versions as follows:
- General
- An entity, with at least one committed version will be declared as a committed requirement and will continue in the same state for ever.
- An entity, with no committed version can be treated as a container OR a requirement.
- However, it will be treated as a container, when child requirements are assigned to it.
- All versions of a requirement will be bundled together.
- This implies that at any point of time, a requirement set will have only one unique hierarchy.
- Certain operations, which are likely to create confusion (like Indent / Outdent / Move) will be disabled in "All Versions View".
- Effort computation at the parent level is suppressed for now.
- States
- A requirement version can have the following states
- Editable
- Non-Editable / Committed
- Archived - Remove from the main table view (this function is not available from RMsis 1.2.0 till this release)
- Multiple versions can be in editable state (say versions of a requirement allocated to Alpha / Beta release)
- State of a Requirement comprises of
- the values of it's attributes
- Summary
- Description
- links to the associated documents
- use cases defined for the requirement (this function is not available in RMsis 1.2.0 till this release)
- links to Requirements, most notably
- preceding version
- the values of it's attributes
- User analysis (perceived) data is excluded. This includes
- Feasibility
- Effort
- Priority
- Criticality
- Comments
- Release
- State
- The following links are external and do not affect the state of a requirement
- Links to other Requirements.
- Other associated artifacts like bugs, feature requests, change requests.
- User comments
- Release
- Categories
- Baseline
- History associated with the requirement. The history will be maintained for the lifetime of a specific version of a requirement.
- When a requirement is committed, it's links are frozen. However,
- if the document is maintained at an external location, the user has to make sure that the document version is preserved.
- the dependencies between Requirements can still be edited.
- 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.
- the latest hierarchical structure will prevail for all views.
- Underlying requirements and their versions can change.
- documents attached to parent requirements will always be editable.
- All state changes require explicit user action.
- 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.
- A requirement version can have the following states
- The system allows creation of multiple versions.
- While creating versions of a requirement, two possibilities exist :
- Create multiple versions of a requirement on multiple branches.
- Here, the base version (say version 1) of the requirement is committed and multiple versions of requirement are created from this base version.
- This creates multiple branches.
- Create multiple versions of a requirement on a single branch.
- Here, versioning of requirement is done sequentially.
- 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.
- Now version 2 of the requirement is committed and a new version (version 3) of the requirement is created from version 2.
- So, in this case, a single branch exists.
- Create multiple versions of a requirement on multiple branches.
- At the requirement level, the user will have an option to
- Create another version on the existing branch.
- This is an example of creating multiple versions of a requirement on single branch
- Suppose a requirement (say FIR-R17 {1}) exists and this requirement is committed.
- A new version of this requirement is created. The new version of requirement will be FIR-R17 {2}.
- The above operation creates FIR-R17 {2} on branch 1.
- Now FIR-R17 {2} is committed.
- And then a new version of FIR-R17 {2} is created. The new version of requirement will be FIR-R17 {3}.
- The above operation creates FIR-R17 {3} on existing branch 1.
- So by using the above feature, multiple versions of a requirement can be created on same branch.
- This is an example of creating multiple versions of a requirement on single branch
- Create another version of a committed (non-editable) version of the requirement.
- This will effectively fork a new branch but branch-id's are not being displayed for maintaining simplified versioning scheme.
- This is an example of creating multiple versions of a requirement on multiple branches.
- Suppose a requirement (say FIR-R18 {1}) exists and this requirement is committed.
- A new version of this requirement is created. The new version of requirement will be FIR-R18 {2}.
- The above operation creates FIR-R18 {2} on branch 1.
- Now, a new version of requirement FIR-R18 {1} is again created. The new version of requirement will be FIR-R18 {3}.
- FIR-R18 {3} will be created on branch 2.
- So by using the above feature, multiple versions of a requirement can be created on multiple branches.
- The evolution of requirement can be viewed in the detailed view of a requirement.
- Create another version on the existing branch.
- Branches of a requirement can be created across projects. (However this feature is not available in RMsis V.1.2.0).
- Requirement ID will remain same across all the projects.
- While creating versions of a requirement, two possibilities exist :
- Version Numbering
- The versions will be auto numbered and sequential.
- The source information for a version will be stored in database.
- Creating version from the latest version of a requirement will create a copy in the same branch. For example
- "Create Version" from R2-V3 will create R2-V4
- Creating version from an old version will fork a new branch.
- "Create Version" from R2-V3 again will create a new branch for R2-V5 with R2-V3 as the source.
- Manage versions & baseline only at the requirement level
- Requirements will exist at the leaf level and cannot be converted to a parent / container.
- The detailed view of the requirement will show evolution tree for the requirement.
- All cross referencing will be with respect to versions (where applicable).
- User Actions and State Transitions
- Multiselect feature will work for all the versioning related operations.
- Create another Version
- This ensures that the current version should be in committed state.
- 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.
- Version can be created only for a requirement at the leaf level and not for a parent / container.
- The state of a newly created version is set to Open.
- Commit Requirement
- Change the state to Non-Editable. This Requirement state will be preserved.
- Linking another requirement to a Committed Requirement
- A link is created and it is not necessary to create another version of the committed requirement.
- An instance of a requirement can be deleted only if itself and the tree beneath does not include a committed / non-editable requirement
- Move | Cut - Paste
- All versions of a requirement are bunched together. Hence a move will move all the versions of a requirement.
- Parent / container can be moved, irrespective of the state of underlying requirements.
- Indent / Outdent in the context of versioning
- A requirement cannot become a parent, if any of it's versions are committed.
- If the current version is in Editable mode, no new copies are created and the links to parents are rearranged.
- Indent / Outdent will be contextual... will work, based on the current view of the user.
- Baseline
- If the selected version is in Editable mode, then the version is committed.
- If the selected requirement is in Non-Editable / committed mode, then it's state remains unchanged.
- If only a parent is selected, an error message will be returned to the user.
- There is no impact on the other children of ascendants.
- 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
- A child inherits the description associated with the parent. This includes attached documents.
- Other links to test cases, code, design etc have to be explicitly specified by the user.
- 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
- The user can specify this.
Overview of User Interface
- Latest View
- Latest version of a requirement, which is at the leaf level, will be displayed.
- View of Multiple versions in a single table
- There will be an option to view all versions of requirements.
- All versions of a requirement (which are not archived) will be displayed.
- 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
- User Options
- Create a Version
- Commit Version
- Provide these options in
- Context Menu
- Version & Baseline (Dropdown Options)
- User Options
Scope
- Baseline scope is restricted to Requirements only.
- Versions of other artifacts like issues, feature requests will not be managed in the current version of RMsis.
- Versioning of test cases is available and its user's responsibility to maintain those.