/
Refreeze requirements from a previous version

Refreeze requirements from a previous version

Once you have created a baseline from requirements, you will have the possibility to refreeze versions of requirements into a new baseline.

Use cases

  • If you want to update a few requirements in a baseline,

  • If you want to add or delete requirements from an existing baseline,

It will create a new baseline, with a new baseline number, with the text of the chosen requirements. All requirements in the new baseline will have the new baseline’s version number and there will be no trace of which version they came from. Technically, a refreeze takes as much space as a new baseline, users can’t save on data by using the refreeze.

Our recommendation: Due to the difficulties expressed at the bottom, we rather recommend to always create baselines from the current version of requirements. It means you can’t “fork” or “branch” requirements from a past version on DC.

How to refreeze requirements

  1. Navigate to 'Requirements' in the left sidebar, into the ‘Baselines' tab.

  2. Click on one baseline and 'Refreeze'.

Requirement Yogi - Baselines - Refreeze.png

  1. You are now being redirected to this screen.

    1. On the left side, you can see requirements in the baseline.

    2. It is possible to click on the version number and choose a specific version to change the version of that requirement.

  2. You can also make a new search that will look for requirements in their current version.

    1. You can drag and drop requirements you want to add to your baseline from the right side to the left.

Requirement Yogi - Refreeze.png

Understanding the screen layout

  • The right panel (white background) is a working area where you can search and preview other requirements.

  • The left panel is the only information that will be submitted in the baseline.

  • You can avoid using the right panel entirely, and just update each requirement’s version in the left panel.

Use the operator “was” in a search query to find a newer version of a requirement which was in a baseline.

  • baseline was 7 Returns all current versions of requirements which were in the baseline 7. After the search, drag’n'drop the cards to the left handside of the screen, and it will update the records accordingly.

  • baseline was 7 and baseline = 12 and @Property = 'ABC' Returns all requirements of baseline 12, which have the property ABC, and were also present in baseline 7.

Difficulties

This feature has a few drawbacks related to the links between requirements.

  • After the new baseline, there is no clue about the origin of each requirement. If you mix requirements from baseline 6, 7 and current, to build baseline 8, then it will be difficult for your users to understand which requirement came from which baseline,

  • If there are dependencies between requirements, links will refer to the original dependency’s baseline.

Understanding the dependency difficulty

Let’s take an example where the requirement R1 references R2, which references R3: R1 → R2 → R3.

Baseline 1 is created: R11 → R21 → R31

6 other baselines are created with varying requirements. R4 and R5 are created, such that R3 → R4 → R5.

A user refreezes baseline 1 into baseline 8, after adding R4 to the baseline. R4’s ancestor was in the current version, but R31 didn’t have a link to R4. Now the baseline 7 contains R18, R28, R38, R48, but the dependencies look like this:

R18 → R28 → R38 → Ø , R3current → R48 → R5current

In other words, R4 in baseline 8 has a dependency to R5, which is outside any baseline. R48 also has a parent R3, but it’s the R3 in ‘current’. Meanwhile, R38 references a child dependency, R4, but it’s R4current, not R48.

The reason we did this is to be authentic to the original data: R3 didn’t have a dependency towards R4 in baseline 1, but R4 has a dependency from R3, so we can’t accurately represent both sides when refreezing; Instead, we save the original dependencies of those requirements.

Impact

You won’t be able to create an accurate traceability matrix with the grandparents/children/grandchildren of a refrozen baseline.

You will still be able to represent flat data in a traceability matrix, such as a list of requirements, their first-level properties and Jira issues.

Notes

In hindsight, we don’t believe the refreeze feature correctly covers most people’s needs. Instead, customers needed:

  • Branches, i.e. the ability to create several “current” variants of their requirements on two separate branches (such as the preparation for a 1.1 and a 2.0 version). It is what we call “Variants”, which are available on the Cloud,

  • Baselines based on the requirement history, but it brings a lot of other problems,

Our recommendation is not to use the refreeze, but always freeze requirements from the current version of requirements.