A requirements baseline is a snapshot in time that represents the agreed-upon, reviewed and approved set of requirements committed to a specific product release. That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).
Once the product team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly requested functionality and altering or deleting existing requirements. Change control is not about stifling change. It’s about providing decision makers with the information that will let them make timely and appropriate decisions to modify the planned functionality. That planned functionality is the baseline.
The Requirements Baseline
Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies only those requirements that the product will implement. A baseline is not a tangible item but rather a defined list of items. One possible storage location is a Product Requirements (PRD) document. If that PRD contains only—and all—the requirements for a specific product release, the PRD constitutes the requirements baseline for the release. However, the PRD might include additional, lower-priority requirements that are intended for a later release. Conversely, a complex product might need several software, hardware and interface specifications to fully define the baseline’s components. The goal is to provide the product stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.
One of the many benefits of storing your requirements in a requirements management tool, rather than in documents, is that you can define a baseline as a specific subset of the requirements stored in the database that are planned for a given release. Storing requirements in a tool allows you to maintain an aggregated set of both currently committed requirements and planned future requirements.
Alternatively, you could define a requirement attribute in the tool to hold the release number or other baseline identifier. Moving a requirement from one baseline to another is then a simple matter of changing the value for that requirement attribute. The attribute approach will work when each requirement belongs to only a single baseline. Tool support is essential for such complex baseline management.
When to Baseline
It’s an important decision because establishing the baseline has the following implications:
Formal change control begins. Change requests are made against an established baseline. The baseline therefore provides the point of reference for each proposed change. Make sure your change control process and players are in place before you define any project baselines.
Product managers determine the staffing levels and budgets needed. There are five dimensions to a product that must be managed: features, quality, schedule, staff, and budget. Once the features and quality goals are defined in the baseline, the product manager adjusts the other three dimensions to accomplish the product’s objectives. It can work the other way, too.
Product managers make schedule commitments. Prior to baselining, requirements are still volatile and uncertain, so estimates are similarly volatile and uncertain. Once a baseline is established, the contents of the release should be sufficiently well understood so that managers can make realistically achievable commitments. The managers still need to anticipate requirements growth by including sensible contingency buffers in their committed schedules.
Baselining requirements too early can push your change process into overdrive. In fact, receiving a storm of change requests after defining a baseline could be a clue that your requirements elicitation activities were incomplete and perhaps ineffective. On the other hand, waiting too long to establish a baseline could be a sign of analysis paralysis.
Keep in mind that requirements development attempts to define a set of requirements that is good enough to let the team proceed with construction at an acceptable level of risk. Use the checklist in Table 1 to judge when you’re ready to define a requirements baseline as a solid foundation for continuing the development effort.
|Business Rules||Determine whether you’ve identified the business rules that affect the system and whether you’ve specified functionality to enforce or comply with those rules.|
|Change Control||Make sure a practical change control process is in place for dealing with requirement changes and that the change control board is assembled and chartered. Ensure that the change control tool you plan to use is in place and configured and that the tool users have been trained.|
|Check back with your key customer representatives to see whether their needs have changed since you last spoke. Have new business rules come into play? Have existing rules been modified? Have priorities changed? Have new customers with different needs been identified?|
|Interfaces||See if functionality has been defined to handle all identified external interfaces to users, other software systems, hardware components, and communications services.|
|Model Validation||Examine any analysis models with the user representatives, perhaps by walking through test cases, to see if a system based on those models would let the users perform their necessary activities.|
|Prototypes||If you created any prototypes, did appropriate customers evaluate them? Did the PM use the knowledge gained to revise the PRD?|
|Alignment||Check to see if the defined set of requirements would likely achieve the project’s business objectives. Look for alignment between the business requirements, user requirements and functional requirements.|
|Reviews||Have several downstream consumers of the requirements review them.|
|Scope||Confirm that all requirements being considered for the baseline lie within the project scope as it is currently defined. The scope might have changed since it was originally defined early in the project.|
|TBDs||Scan the documents for TBDs (details yet to be determined). The TBDs represent requirements development work remaining to be done.|
|Templates||Make sure that each section of the PRD template has been populated. Alternatively, look for an indication that certain sections do not apply to this project. Common oversights are quality requirements, constraints, and assumptions.|
|User Classes||See whether you’ve received input from appropriate representatives of all the user classes you’ve identified for the product.|
|Verifiability||Determine how you would judge whether each requirement was properly implemented. User acceptance criteria are helpful for this.|
Table 1. Factors to Consider Before Defining a Requirements Baseline
You’re never going to get perfect, complete requirements. The product manager must judge whether the requirements are converging toward a product description that will satisfy some defined portion of customer needs and is achievable within the known project constraints. Establishing a baseline at that point establishes a mutual agreement and expectation among the project stakeholders regarding the product they’re going to have when they’re done. Without such an agreed-upon baseline, there’s a good chance someone will be surprised by the outcome of the project. Software surprises are rarely good news.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama Software. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.