Version Handling

This page describes two ways how multiple versions of requirements can be managed:

Postfixing requirement IDs with the version.
Separating requirements based on version.

Postfixing Requirement IDs

A version number can be appended to any requirement ID. For example, the requirement ID SRS_Req_Abc for version 1 could be represented as SRS_Req_Abc-v1. This approach ensures that each version of a requirement is uniquely identifiable.

When the requirement changes, a new version can be created in same requirements file, adjacent to the original requirement, e.g. SRS_Req_Abc-v2.

SRS_Req_Abc-v1:
  text: All software modules shall implement the security features.

SRS_Req_Abc-v2:
  text: All software modules shall implement the security features
        along with the safety measures.

If there is no change in a requirement, then creating new version for requirement can be skipped.

A single requirements file contains all versions of the requirement and can be used for reviews and other workflows.

To export a specific version of the requirements to a different location, a filter script can be applied. This script can select only the desired version of each requirement, remove the version postfixes, and export the filtered requirements.

Separating Requirements In Different Files

Whenever a requirement changes, a new requirements file can be created with the version specified in the filename.

E.g., if requirements in featureX.dim need to be changed, the file is copied to featureX_v2.dim and the changes are made in the new file.

This method will result in duplicate requirements across multiple requirements files. To manage these duplicates, all files can be loaded in a script, a filter applied and finally only specific versions of the requirements are selected.