Requirement Versioning and Releasing

To effectively navigate the dynamic landscape of evolving requirements throughout the product life cycle, our new feature (as of April 2024) introduces a versioning system using the change history. This system assigns version numbers to requirements, enabling meticulous tracking and management. With the capability to release requirements post-gate reviews or milestones, this feature ensures a systematic approach to capturing changes and updates. Moreover, users can seamlessly utilise baselines to revisit and analyse previous versions of specifications, providing a comprehensive view of the product development journey.

This Versions feature enhances the overall tracking and management of requirements and specifications, fostering a more streamlined and adaptable product development process.

Requirement Level Versioning:

Versioning initiates at the requirements level, commencing at 0. Any modification to the attributes of a requirement, such as alterations to the requirement text, identifier, rationale, etc., automatically triggers a minor version increment, transitioning, for instance, from 0 to 0.1.

In short, any updates on the requirement which are saved/added to the “requirement” history field associated with a requirement, the version number of the requirement is likewise adjusted to reflect these changes. This systematic approach ensures a comprehensive and traceable versioning system for requirements throughout their lifecycle.

Note that the versions are shown only in the new history. If it is not shown, toggle on on the “Activate New History” on the right corner within the history option.

List of Changes that Triggers a version number increment

Here are the list of changes in the requirement that trigger the minor version increment

• Editing the Text of the Requirement’s attributes such as “Text”, ”Title”, “Rationale”, “custom columns”

• Adding or Removing the “Parent” and “Children”

• Changing the “Type”, “State”, “Compliance”

• Adding or removing the tags

Adding an image or adding attachments to the component of the verification method, does not trigger a version number increment.

Changes in the requirements attribute prompt an increment of either 2 or 3 decimals, such as from 0.12 to 0.14. This adjustment is a result of how modifications are handled in the backend system.

Note: For now Version control on Verification and Validation Activities is not active and will be included at a later stage.

Release Requirements

Upon finalization of a requirement during the product development phase, achieved thorough reviews, milestones, baselines, or gate reviews, the requirement becomes eligible for release. This signifies a major release for the requirement, which can be executed using the release option associated with the requirement. The act of releasing requirements not only marks their completion but also serves as the conclusive step in version finalization.

When the user releases the requirement, the version number remains the same. However, when there is any changes to the requirement attribute, there is a major increment in the version number i.e it proceeds to next integer. For example any edit on 0.15 version of released requirement POWER-0012 will trigger a version 1.0 increment.

How to Release Requirements

The release option can be accessed through the three dots icon in the “Action” menu, allowing users to release requirements individually or in bulk.

A quick video to demonstrate the bulk release of the requirements is shown below.

The users can toggle on the “Last release” button on the module to see the last released requirements. Refer Figure Latest release toggle

Release Specifications

Users have the option to release specifications associated with multiple requirements. They can access this option by right-clicking the specification name in the tree hierarchy ( Refer to Figure Release Specification).

Upon selecting the release option on the specification level, the users have two options to release the specification.

Associate all requirements current version

The first option, “Associate all requirements current version”, releases all the requirements within the specification and makes the specification release.

Scenarios

• Note that the requirements that are in the released state are not released.

• If the requirement was released and some changes were done to the requirement, the requirement with changes is released again.

Associate only requirements with released versions

Contrary to the first option, the second option, “Associate only requirements with released versions”, takes only the released requirements at that time within the specification and releases the specification. For example, if you have 5 released requirements and 5 unreleased requirements, the specification release creates a specification version with only the 5 released requirements.

Before releasing the specification, the user must provide the comments/reasons on why the specification is released.

Release requirements by reviews

Users can initiate the release of requirements via the Review Center. After the reviewer completes the review, it must be approved by the approver to conclude the review process. The approver has the option to "Release Requirements" as part of finalizing the review (refer to the Figure Release requirements through the Review center)

Please note that even if the requirements are in a "Needs Work" or "Rejected" state, selecting "Release Requirements" will proceed with the release of these requirements.

Compare different Versions of Requirements.

Users can compare requirements across two different versions. To do this, navigate to the requirement's history (ensure "Complex History" is enabled) and click on the release symbol adjacent to the version of interest. From there, select the specific versions you wish to compare.

Please refer to the video below for the steps.