You might hear this in the film industry when the director ends a scene and the assistant holds a clapperboard and snaps it together. The scene is over.
Establishing baselines in software development works similarly. You are probably not shooting the latest blockbuster, and you won’t need a clapperboard. Instead, you make a “cut” of your work and record it: a current state of your work results.
Baselines create reference points
A cut in a film is meant to create reference points because sound and images are often recorded with different equipment and a cut is used to synchronize them. The clapperboard contains important information, too: the name of the film and its director, the cameraperson, the settings or the scene so that it can be easily identified.
Software development also needs unique reference points and information to identify work results. Changes to the software code have to be documented, as does information about who made the changes and what was changed. It should also be possible to restore previous software states..
Requirements engineering is the same because here you also have to be able to trace who has changed what about a requirement, which requirements have been assigned and which ones are in the next release.
These tasks require version management. Creating and saving versions of individual work results is not enough. Often, you have to gather a selection of different requirements, documents, use cases and label them with something like “This is Release 1”. This selection is called a configuration and for this you need configuration management.
What does this have to do with baselines? A baseline is simply the option of providing a label for a configuration and generating an extra version of it.
When do you establish baselines?
You can secure the current state of your requirements with a baseline, for example. You can also generate a baseline for a group of different elements. Because in project management, corresponding baselines often generate milestones or releases with different work results. Once you, for example, have finished all results of release 1, draw a baseline. That way you can record both the state of the requirements as well as related artifacts like test cases or system components and documents.
Keep changes under control with baselines
Why are you making all the effort? Baselines are meant to keep the project under control. What happens, for example, if stakeholders are constantly changing their wishes and create new requirements that endanger the project schedule? Establish a baseline for the Release 1 requirements and have the stakeholders sign off on them so that you can use them as a reference point, this time to tell your stakeholders: “We agreed on these requirements for this release. If we have to implement more, we will not be able to keep the deadline.”
These days, version management and configuration management require software support. But often the different work results are created and versioned in different tools which causes mistakes and more effort. That is why we recommend an integrated tool that facilitates versioning and establishing baselines for all work results.
Work results are also connected with each other: requirements with a test case or a block diagram with a requirement. This means that even the changes to the relationships can be controlled and managed.
These challenges can be managed with one tool that supports version control as well as establishing baselines. That is what our requirements engineering software objectiF RM is for.
Version control with objectiF RM
You probably record requirements with a description, type, priority and connected risks. In objectiF RM this happens with the help of forms and other means. Maybe someone tells you to remove risk considerations from the form, so you no longer display the information there. Three weeks pass and then someone says “we need the risks again”. No problem, because you can display the original version of the form and decide if it should look like that again and, if so, restore the old version.
Establish baselines with objectiF RM
And what does a baseline for your requirements look like? Or for multiple, different elements, like requirements, test cases, documents, diagrams, etc.?
In objectiF RM, this happens in two steps:
- Create an element group.
- Create a revision of this group.
In element groups all related work results and ones which you would like to secure with a snapshot can be recorded. Then a review of this group can be created and given a suitable label, for example, “Release 1”. Done, you have established a baseline and created a reference point. All elements of the group now contain a version of your history automatically that is provided with the label.
By the way, if you establish a baseline for your requirements and one of them is connected with a test case, then the tool automatically versions the test case, too. Because both artifacts are related to each other. This way you can always access the state of the test for which the baseline was established, even if the form of the test case has changed in the meantime.
Through the combination of version management and configuration management, you create transparency, traceability and security.
Are you curious?
Then read all about objectiF RM here.
Or get started straight away with a free test.