Note: This is the third post in our series of Managing Your Requirements 101. Read the first two posts here -
Usually projects start with unclear requirements and expectations. Lack of base lined requirements can result in chaos with lots of requirements changes resulting in requirements and scope creeps. Baselines can also help in acceptance testing and prototyping efforts. Baselines are especially valuable in fixed price contracts.
A baseline is all about getting to a common base agreement between stakeholders. It essentially involves setting the right expectations including responsibilities, risks, assumptions, deliverable and approaches. Once an agreement is reached; it could be put in source control to manage the base line going forward.
Why bother base lining requirements? As mentioned in earlier posts, requirements are the foundation stones to a project and unless we know what we are creating; how do we know what changes to make in due course? Starting the projects without a proper analysis of requirements is a recipe for disaster - it’s like building a house without a blue print. When it comes to software projects, lack of base lines can incentivize clients to make endless changes while the project is in progress and resulting in requirements and scope creeps. Requirements must be initially base-lined and put under change control in the Statement of Work (SOW) so that the project can be planned, estimated and executed. When it comes to a requirements management tool like Rational DOORS or Rational Requirements Composer, a requirements project baseline captures the entire project at a specific moment in time including folder structures and artifacts. Baselines also play a significant role in enabling traceability. It provides the foundation linkages to establish the traceability matrix later in the project.
What to be included in a baseline? Though the contents of a baseline can vary; it is essentially provides the functional and nonfunctional requirements taken into consideration for a release or an iteration. It may contain other aspects like sub system and hardware dependencies also. It is also important to note here that requirements baselines evolve over time. The Business Analyst or Project Manager concerned takes the call on creating new baselines as requirements change or new requirements pops up. As mentioned above, a requirements baseline essentially captures the entire state of a project as t a given point in time. Essentially this includes the vision/scope document, glossary of terms, use case (stories). The starting point for not resulting in requirements creep is setting the boundaries.
Ideal time for base-lining. Baselines drive formal change controls. A project manager is always trying to address the triple constraint – scope, time and cost (coined by Kathy Schwalbe) . Baselines help in managing the scope constraint and focus on other aspects. Baselines also pave way to setting the schedules. Karl E. Wiegers in his book (More About Software Requirements) provides an exhaustive list of factors to be considered before defining a requirements baseline.
What do you think about baselines?
This is the third part of our six part blog posts series on basics of requirements management. Read the remaining parts here -
1. What is requirements management and why is it important?
2. How to write good requirements and types of requirements
3. Why base line your requirements?
4. What is Traceability?
5. The uses and value of traceability
6. Revisiting Requirements Elicitation