I define a baseline as a stable, change-controlled configuration of work products. In other words, I freeze a specific set of requirement versions. First, I select only stable and released artifacts. Next, I formally check and release the configuration. Then, I label it as the requirements baseline for a given release or milestone.
I use baselines for clear planning. For example, I use them for release planning and for release definition. In addition, I use them to estimate implementation costs. Therefore, baselines help me and my stakeholders compare our planned release with competing products on the market. Consequently, baselines increase transparency. Moreover, they create a common reference point for development, testing, and delivery.
I create baselines at defined project milestones. For example, I may create a requirements baseline when the architecture design is ready. Alternatively, I may create one when a specification goes to review. If I create it at the “for review” milestone, I may include artifacts with status “In evaluation.” However, if I create it at the “creation of the architecture design” milestone, I include only artifacts with status “Released.” Thus, I pick the artifacts based on the milestone and their status.
I recommend that you document baseline rules in your requirements management plan. First, state the purpose for which you create baselines. Second, define who is allowed to create them. Third, list the criteria for selecting requirement artifacts. In other words, you must treat the artifacts in a baseline as an accepted and commissioned specification. Consequently, you must allow changes only through a controlled change management process. Otherwise, the baseline loses its value as a stable reference.
I distinguish between a requirements configuration and a requirements baseline. A configuration can contain current work items and may serve internal needs. On the other hand, I make a baseline visible to the outside world. Specifically, I release a baseline as a formally checked configuration of stable requirement versions. Therefore, I usually use baselines for external communication, release management, and cost estimation. Meanwhile, I use configurations more for internal composition and temporary frozen states.
I also use baselines as a basis for reset. If necessary, I revert or compare current work against a baseline. Thus, I can restore a consistent project state from an older, approved status. Furthermore, in agile contexts, I sometimes treat the sprint backlog at the start of an iteration as a baseline for that iteration. Consequently, baselines work in both plan-driven and agile processes.
Finally, I emphasize traceability and discipline. First, baselines should contain only requirements planned for the specific product version. Second, baselines should not contain proposed or in-progress items. Third, any change to baseline items must follow a controlled change process. As a result, baselines give me a stable and auditable foundation for planning, estimating, and delivering software.