What I was trying to say was that I agree that the term ‘baseline’ should be clearly defined in a process or system that spans different traditional areas of project work. Conflicting terminology is a common problem when trying to move from a development process and systems that are developed for groups in silos, like RM, SCM, Test Management, Project management, to an ALM approach. If you pitch an ALM process or system that uses baseline as defined in your post, without first clearly defining to RM practitioners and Project Managers what baseline means in this context, you will at the least get a lot of confused looks, at worst get a lot of resistance.

The “baseline” in requirements management, according to the likes of the Booch/Jacobson/Rumbaugh trio and others, is taken when the initial elicitation and analysis has been completed and the initial requirements have been approved. The requirements are ‘frozen,’ which is also not a very clear term, because they can still be changed after the baseline. Really, what taking a baseline means in most schools of requirements management is starting to apply some form of change control process on the requirements. From a Project Management perspective, especially in more traditional waterfall development shops, when the baseline has been taken, it’s relatively safe for development staff to start working with confidence that the requirements are unlikely to suddenly change drastically.

So, if you are working on a project and you start talking about taking multiple baselines some people, particularly business analysts and some project managers, get quite agitated. As you said, it’s important to be clear to the participants what the definition of a baseline is in the context of the project.