Spotlight on Spira 6.5.2 - Requirements and Test Case Baselining

What is Baselining, and Why is it Important?

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".

Changing Requirements in Agile Projects

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.

What is a Baseline?

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 in SpiraTeam and SpiraPlan

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.

Enabling Baseline Support

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.

Creating Baselines

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.

Reporting on 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.

What's Planned Next

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:

• Baseline Administration - We will be adding new administration screens where you can centrally view all of the baselines in a product, drill-down to see all the changes between two baselines, and make changes to the baselines in a central place.
• Standard Baseline Reports - Replacing the current custom reports, there will be a set of standard summary and detailed reports related to baselines to view all of the baselines in a product and release, as well as see the unified differences between two selected baselines.
• Association Change Tracking - The initial version of baselining tracks the changes to made to the fields, attributes and custom properties of each artifact in the system. We will be adding support for tracking and versioning the associations themselves. For example, you will be able to see if a requirement was associated with a test case (or the association removed) in between two different baselines.
• Additional Visualizations - The display of baselines and differences will be initially in the form of simple data grids and textual representations. We are planning on adding more sophisticated and visual tools for viewing the differences between versions and baselines.