Defining and Implementing Requirements Baselines
|
Developers often want to freeze software requirements following some initial work and then proceed with development, unencumbered by those pesky changes. This is the classic waterfall paradigm. It doesn’t work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline.
What is a Requirements Baseline?
A requirements baseline is a snapshot in time that represents an agreed-upon, reviewed, and approved set of requirements that have been 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 project 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.
A change control process 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.
Typically, a baseline is also given a unique name so that all the project participants can refer to it unambiguously. And good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.
Implementing a Requirements Baseline
Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies only those requirement specifications that the project will implement. A baseline is not a tangible item but rather a defined list of items. One possible storage location is a software requirements specification (SRS) document.
If that SRS document contains only—and all—the requirements for a specific product release, the SRS constitutes the requirements baseline for the release. However, the SRS document might include additional, lower-priority requirements that are intended for a later release.
Conversely, a large project might need several software, hardware, and interface requirement specifications to fully define the baseline’s components. The goal is to provide the project stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.
Perhaps you’re storing your requirements in a requirements management solution, rather than in documents. In that case, you can define a baseline as a specific subset of the requirements stored in the database that are planned for a given release.
RELATED: The Gap Between the Increasing Complexity of Products and Requirements Management
Storing requirements in a solution allows you to maintain an aggregated set of both currently committed requirements and planned future requirements. Some commercial requirements management tools include a baselining function to distinguish those requirements (perhaps even down to the specific version of each requirement) that belong to a certain baseline.
Alternatively, you could define a requirement attribute in the solution to hold the release number or another 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. However, you might well allocate the same requirement (or different versions of the same requirement) to several baselines if you’re concurrently developing multiple versions of your product, such as home and professional versions. Tool support is essential for such complex baseline management.
When following an incremental or iterative development life cycle, the baseline for each iteration will represent just a fraction of the overall system’s functionality.
A small project my team once worked on took this approach. This project worked in three-week release cycles. For each cycle, the BA specified the software requirements that were to be designed, coded, integrated, and verified during the next three weeks. Each requirements baseline was therefore quite small. In a classic agile approach, the product grew incrementally toward full functionality as the developer periodically released useful versions to the users.
RELATED: How to Perform Better Impact Analysis on Upstream and Downstream Relationships
When to Perform a Requirements Baseline
Business analysts sometimes struggle with exactly when to define a requirements 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.
Project managers determine the staffing levels and budgets needed. There are five dimensions to a software project that must be managed: features, quality, schedule, staff, and budget. Once the features and quality goals are defined in the baseline, the project manager adjusts the other three dimensions to accomplish the project’s objectives. It can work the other way, too. If staff, budget, and/or schedule are pre-established by external forces, the baseline composition is necessarily constrained to fit inside the project box bounded by those limits.
RELATED: Getting the Most from a Requirements Management Tool
Project 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 (per their requirements management plan) 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: perhaps the BA is trying too hard to perfect the set of requirements before handing them to the development team.
Keep in mind that requirements elicitation 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.
Table 1. Factors to Consider Before Defining a Requirements Baseline
| 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. |
| Customer Perspective |
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 BA use the knowledge gained to revise the SRS? |
| 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. These consumers include designers, programmers, testers, documentation and help writers, human factors specialists, and anyone else who will base their own work on the requirements. |
| Scope | Confirm that all requirements being considered for the baseline are 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 SRS document 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. |
RELATED POST: 8 Do’s and Don’ts for Writing Requirements
You’re never going to get perfect, complete requirements. The BA and project 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.
And software surprises are rarely good news.
To learn more about how to write requirements in a way that all stakeholders have a clear understanding of development needs, download our eBook, Best Practices for Writing Requirements.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at ProcessImpact.com.
Subject matter expert Karl Wiegers writes on best practices for writing requirements, requirements management, and requirements traceability.
Latest posts by Karl Wiegers (see all)
- Best Practices for Change Impact Analysis - September 12, 2022
- Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS) - May 30, 2022
- Defining and Implementing Requirements Baselines - June 18, 2019
Nice article. I am conflicted on how to create a baseline for a project. Which of the following scenarios would be considered a “best practice” for creating a project baseline in which to measure progress and get some schedule-related EVM metrics? Is Primavera Really usefull for this process, What you did was exactly what I suggested???
Primavera Training