July 6th, 2020 by inflectra
One of the focus areas in the upcoming release v6.5.2 of SpiraTeam and SpiraPlan is support for baselining. This is an exciting new piece of functionality that will make SpiraTeam and SpiraPlan especially well suited for managing requirements, test cases and artifacts on more complex systems and engineering projects.
If you read our whitepaper discussing the Change and Configuration Management of Requirements, it discusses the ways in which requirements management systems can help you manage versions and baselines of artifacts such as requirements and test cases. It also discusses in detail, the differences between changes, versions, and baselines and why it's important to be able to have functionality to manage sets of changes between different baselines or "snapshots".
Most things are managed incrementally in Agile projects, and requirements are no exception; the detailed analysis and fleshing out of the requirements does not all happen up front as it does with traditional development methods. Because much of the requirements work is still to be done while the system is already in development, change is looked upon more favorably than it would be otherwise. Moreover, change is actually encouraged in Agile projects as it is considered part of the drive for quality improvement; the idea being that upcoming requirements can be changed and adapted based on what the team, (including the stakeholders) learn in the preceding stages or iterations.
A baseline is nothing more than a collection of versions, frozen so that they may not be altered. Baselining a meaningful set of requirements and test cases allows a team to work on a stable set of information without necessarily stifling change at the same time. Work can progress against the baselines while new changes may apply to the current, non-baselined data. A perfect example is an Agile project in which a team can begin working on a set of baselined requirements for a development iteration while those requirements continue to evolve and grow ready for the next iteration.
One important distinction between baselining and simple artifact versioning, is that with simple artifact versioning, each artifact's change history is tracked separately:
In contrast, baselines become a complete definition of the entire system at each build point and possible release, incrementally growing with each iteration’s new requirements as well as including any changes made to previously implemented requirements. We can also add requirements related artifacts such as designs, tests, defects, etc. into the baseline, so it is important to have the baselining or versioning of relationships as well as the versioning of the changes to the artifacts themselves.
For example, a typical baseline of a product containing requirements and test cases might look like the following:
Baselining allows you to take a snapshot of the entire product at a specific point in time. You can use this feature to see the state of every test case, requirement, and incident as they were the moment that baseline was created. You can see how an artifact changed between two baselines. In SpiraPlan, we attach baselines to a release, as well as to the state of the product changes. This is to help you more easily use baselines as part of your release planning and review: baselines are, in effect, tied to the progress of your releases and sprints. You may wish to create a baseline when your release starts, and then create another when it is released. You may create a baseline at the end of every sprint and then use your baselines to see what happened between those two sprints.
To enable baseline support in SpiraPlan, simply go to the Administration menu for the current Product and click on the button to View Details:
Simply change the "Baselining Enabled" slider to Yes and click Save. Baselining is now enabled for this product.
Once baselining is enabled, you will be able to go to the main Planning > Releases page and click on the Release or Sprint that you want to create a baseline for. There will be a new Baselines tab visible on the Release or Sprint:
Click on the New Baseline button and then enter the Name and Description of the baseline you wish to create. Then click the Add button to complete the addition.
The new baseline will be created for the current release. In the example below we created an initial baseline at the start of the release, and then created a second, incremental baseline during the release:
You can see that the ChangeSet ID of the system is larger for the second baseline. That shows number of changes in the entire system that have happened between the two baselines.
Now that you have created your baselines, you typically will want to report on them. In this initial version of baseline support, we are using a set of Baseline Custom Reports to provide this functionality.
In this example custom report, you can see the change history between the two different baselines. The report shows the artifact name, type and the change that was made. We can also go one level detail and see the fields that were changed in each of the unique changesets in the revision history.
This is just the initial set of baseline-related functionality we have planned for SpiraTeam and SpiraPlan this year. In parallel with the release of this new version, our product team will be working on the following additional features: