Software developers often want to freeze the requirements following some initial requirements development work and then proceed with design and construction, unencumbered with 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.
Baseline is a term from the domain of configuration management. The IEEE Standard Glossary of Software Engineering Terminology defines it as the following (1990):
A specification or product that has been formally reviewed and agreed on, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.
A baseline is given a unique name so that the project participants can refer to it by name and review exactly what elements a previous baseline included. Good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.
In a broad sense, any approved set of requirements could be defined as a baseline, even before release planning has been done. In this chapter, though, we will think of a requirements baseline as being a snapshot in time that represents the current agreed-upon, reviewed, and approved set of requirements committed to a specific product release. That "release" could be a complete delivered product or any defined, interim increment of the product. The baseline also includes supporting documentation, such as the scope definition that was used to establish the set of committed requirements, information about who approved the baseline, and key source documents for the requirements. When stakeholders "sign off" on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline. See Chapter 2 of Software Requirements, Second Edition for more recommendations on the requirements approval or sign-off process.
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. 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.
Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies those requirements that the project will implement. That is, the baseline is a precise description of what is in scope, but it doesn’t identify what is left out. The techniques described in Chapter 17, provide high-level descriptions of the release contents. The detailed baseline description consists of an explicitly identified set of functional requirements committed for the release.
Where does the baseline live? It’s not a tangible item but rather a defined list of items. One possible storage location is a software requirements specification written in the form of a word-processing document. If that SRS contains only the requirements for a specific product release and it indeed contains all the requirements for that release, the SRS constitutes the requirements baseline for the release. However, the SRS might include additional requirements that are intended for a later release. (See Chapter 20.) Conversely, perhaps multiple software, hardware, and interface specification documents are needed to fully define the components of the baseline. It’s essential that the project stakeholders have a clear understanding of exactly what is intended to go into the upcoming release.
But perhaps you’re storing your requirements in a requirements management tool or in some other database, rather than in the form of 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. Storing requirements in a tool 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 (even down to the specific version of each requirement, perhaps) that belong to a certain baseline.
Alternatively, you could define a requirement attribute 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 requirements 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. Tool support is essential for this type of complex baseline management.
Note that you need not baseline all the requirements for the entire product at once. 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. The developer (who also served as project manager, analyst, and tester) worked in three-week cycles. For each cycle, he specified the requirements that were to be designed, coded, verified, and integrated during the next three weeks. Each requirements baseline was therefore quite small. The product grew incrementally toward full functionality as the developer released useful versions periodically to the users.
Analysts sometimes struggle with exactly when to define a baseline for their requirements. 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 (Wiegers 1996).[1] Once the features and quality goals are established in the baseline, the project manager manipulates the other three dimensions to see what it will take to accomplish the project’s objectives. It can work the other way, too. If staff, budget, and schedule are pre-established by external forces, the baseline composition is necessarily constrained to fit inside the project box bounded by those limits.
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 accommodate the likelihood of requirements growth by including sensible contingency buffers in their committed schedules.
Baselining requirements too early can push your change control process into overdrive. If the requirements are still evolving and many new requirements are still being identified, you can devote an undue amount of effort to handling changes formally. 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 analysts are trying too hard to perfect the set of requirements before handing them to the development team for implementation.
Remember, requirements development attempts to define a set of requirements that is not perfect but is good enough to let the team proceed with construction at an acceptable level of risk. Unfortunately, no convenient green light comes on to signify when you’ve reached this point. Instead, use the checklist in Table 18-1 to judge when you’re ready to define a requirements baseline as a solid foundation for continuing the product development effort.
Table 18-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 functional requirements 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, or CCB, 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? Has marketing made any promises that the analysts haven’t heard about yet? |
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? Was the knowledge gained used to revise the requirements specification? |
Requirements Alignment | Perform a reality check against the project’s business objectives to see if the defined set of requirements would likely achieve those objectives. Look for alignment between the business requirements, user requirements, and functional requirements. |
Requirements Reviews | Have several downstream consumers of the requirements review them. These consumers include designers, programmers, testers, documentation writers, help system designers, user interface designers, and anyone else who will base their own work on the requirements. Conduct this sort of review activity in an incremental and ongoing fashion. Don’t wait until you think the requirements are complete before you ask some people to judge whether they could execute their part of the work based on those requirements. |
Scope | Check whether all the requirements being contemplated 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) that indicate gaps remaining in the requirements knowledge. Baselining requirements that still contain TBDs increases the uncertainty level in the document. The TBDs represent requirements development work remaining to be done. |
Examine the document templates you’re using to store your various types of requirements. Make sure that each section of the specification has been populated or that an indication has been supplied that that section does not apply to this project. (One example might be, "No constraints have been identified for this project.") Common oversights in the templates are quality attribute 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. |
You’re never going to get perfect, complete requirements. You’re never going to know the perfect time to declare a requirements baseline and move on with the project. However, the analyst can use the practices in this chapter to 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.
[1] Some people add other dimensions, such as risk. The important concept is to avoid the overly simplistic "iron triangle" approach, which considers only three of these dimensions—most commonly scope, time, and resources, although exactly which three varies from author to author. The iron triangle makes assumptions about which dimensions are static (typically features or quality) and which can be combined (typically features + quality = "scope," or staff + budget = "resources"). In reality, all five of these dimensions can be adjusted and traded off against one another.