Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn\u2019t work well in most situations. It\u2019s far more realistic to define a requirements baseline and then manage changes to that baseline.<\/p>\n
The term baseline<\/i> comes from the domain of configuration management. The IEEE Standard Glossary of Software Engineering Terminology defines a baseline as:<\/p>\n
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.<\/p>\n
A baseline is given a unique name so that the project participants can refer to it unambiguously. Good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.<\/p>\n
A requirements baseline is a <\/b>snapshot in time that represents the agreed-upon, reviewed, and approved set of requirements committed to a specific product release. That \u201crelease\u201d could be a complete delivered product or any interim development increment of the product. When stakeholders \u201csign off\u201d on requirements, what they\u2019re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).<\/p>\n
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\u2019s 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.<\/p>\n
Whereas the scope definition distinguishes what\u2019s in from what\u2019s out, the requirements baseline explicitly identifies only those requirements 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 contains only\u2014and all\u2014the requirements for a specific product release, the SRS constitutes the requirements baseline for the release. However, the SRS might include additional, lower-priority requirements that are intended for a later release. Conversely, a large project might need several software, hardware, and interface specifications to fully define the baseline\u2019s components. The goal is to provide the project stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.<\/p>\n
Perhaps you\u2019re storing your requirements in a requirements management tool, 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. Storing requirements in a tool allows you to maintain an aggregated set of both currently committed requirements and planned future requirements. Some commercial RM 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.<\/p>\n
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. However, you might well allocate the same requirement (or different versions of the same requirement) to several baselines if you\u2019re concurrently developing multiple versions of your product, such as home and professional versions. Tool support is essential for such complex baseline management.<\/p>\n
When following an incremental or iterative development life cycle, the baseline for each iteration will represent just a fraction of the overall system\u2019s 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 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.<\/p>\n
Business analysts sometimes struggle with exactly when to define a requirements baseline. It\u2019s an important decision because establishing the baseline has the following implications:<\/p>\n
Formal change control begins.<\/b> 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.<\/p>\n
Project managers determine the staffing levels and budgets needed. <\/b>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\u2019s 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.<\/p>\n
Project managers make schedule commitments.<\/b> 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.<\/p>\n
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.<\/p>\n
Keep in mind that requirements development attempts to define a set of requirements that is good enough <\/i>to let the team proceed with construction at an acceptable level of risk. Use the checklist in Table 1 to judge when you\u2019re ready to define a requirements baseline as a solid foundation for continuing the development effort.<\/p>\n
Table 1. Factors to Consider Before Defining a Requirements Baseline<\/p>\n