Software products are rarely delivered in final form with the first release. More commonly, they evolve through a series of releases or iterations that correct defects, add progressively more features, and enrich or update previously implemented features. This means that during requirements development you’ll be accumulating requirements that could be targeted for various releases. You need to determine the best way to store and manage these requirements so that no one is confused about the contents of each upcoming release.
A related issue pertains to requirements that were proposed, but never approved. Similarly, you might approve certain requirements for a specific release, only to delete them later (perhaps deferring them to a future release or iteration) either because they are no longer valuable or because of time and resource limitations. Deleted requirements, rejected requirements, ideas, and potential requirements for the future have a way of resurfacing before the project is finished. You don’t want to lose sight of the fact that these requirements once were proposed or considered to be in scope. Nor do you want anyone to work on them under the mistaken belief that they’re intended for the next release.
There are several ways to deal with requirements that are not a part of the current build. The goal is to produce specifications that clearly identify the requirements for each release, while still providing access to all requirements that describe the historical and possible future states of the product. This article compares three strategies for solving this problem:
• Storing all requirements in a single software requirements specification (SRS).
• Creating a separate SRS for each release.
• Storing requirements in a requirements management tool.
Single Requirements Specification
One option is to begin by writing an SRS that contains just those requirements that are planned for the initial product release. This approach makes sense if your team is continuously working on the next set of prioritized requirements and modifications in the backlog, creating a release whenever they have a bundle of enhancements and changes ready to go. When you think the initial SRS is complete, define it as a baseline for that first release. Store the baselined document in a version control tool. Then use check-in and check-out procedures to make changes to the SRS and maintain a revision history of changes made.
As you identify new or modified requirements for any planned release, highlight those changes using your word processor’s revision marks feature. Indicate the planned release number so everyone will know which requirements are in scope for each release. Also, explicitly identify those requirements that have been deleted or that were proposed once but not approved, along with an explanation of why each decision was made. This retains those requirements for possible future use.
After you’ve recorded all the requirements you intend to implement in the next release, take the following actions:
1. Archive the SRS in the version control tool, with the revision marks included to identify changes made since the previous version of the document was baselined.
2. Create a copy of the marked-up file. Accept all the revisions, thereby making all the requirements and changes made to them current. Save that version in your version control tool, too. Identify this document as now representing the full set of requirements for the specified product release, including all functionality that was implemented in previous releases.
3. Continue the process of entering changes with revision marks turned on and periodically baselining the SRS for each subsequent release.
This approach results in developing a single master SRS that contains all the requirements that fully describe your product as it grows through multiple releases. The revision marks in any single historical version represent just the deltas from the previous version.
Creating a master SRS provides the advantage of collecting all the requirements in a single place. You can place new requirements placed in context wherever they belong. It’s also easy to handle requirements that were originally planned for a future release but have moved into scope for the current release. Because these requirements are already in the document, it’s just a matter of indicating that they are now planned for the upcoming release.
The single-spec approach has some shortcomings, though. It’s easy to get confused about which requirements the developers are supposed to implement in a specific release. It’s also difficult to view just the subset of the requirements that describe a specific incremental release because the requirements for multiple releases are all threaded together. Suppose that for release 5 you have 23 new requirements sprinkled throughout your 50-page master SRS. Developers and testers will need to print the entire document and study the revision marks to figure out exactly what to do. This is inefficient and error-prone.
Multiple Requirements Specifications
If your organization treats each new product release as a separate project, consider writing a separate SRS for each such release. This can also work in an iterative environment, treating each iteration as a micro-project. The SRS for the first release should follow a comprehensive SRS template, such as the one available from http://www.processimpact.com/goodies.shtml. Much of this information will remain unchanged for future releases.
Each incremental SRS for a subsequent release will be simpler than the first one, without all the global and background information that appeared in the initial SRS. Each incremental SRS will describe just those functional requirements that are being added or changed, along with associated performance requirements, other quality attributes, and business rules. Consider using different document templates for the comprehensive initial SRS and for the smaller and simpler incremental specs.
If you create multiple specifications in this way, then you can use each separate document to describe exactly what the team is going to do in a particular release. This is more reliable than hoping that every reader will correctly glean all the changes from an increasingly bulky master SRS. Individual specifications are smaller, less intimidating, and easier to work with, especially in hard copy form.
Creating multiple specifications presents some disadvantages, though. Shifting a requirement from one planned release to another requires that you actually move the text describing that requirement from one document to another. Writing a separate SRS for each release doesn’t provide the context and big-picture synthesis of what the whole product is today. Someone who wants to get a complete description of any feature, let alone the entire product, has to assemble bits of information from multiple sources. With multiple specifications, it’s also easy to lose track of those requirements that were not allocated to a particular product release and yet remain in the backlog of possible future work. There’s no logical place to put them, unless you create yet another document to contain the “leftover” requirements that might be of future interest.
Requirements Management Tool
The most robust strategy is to store the requirements in the database of a commercial requirements management tool. This keeps the requirements for all releases stored together. You can use the tool’s baseline-definition feature to distinguish the subsets of requirements that belong to different releases. Alternatively, you could define a requirement attribute to hold the planned release number for each requirement. Reallocating a requirement from one release to another then becomes a simple matter of changing this attribute. A status attribute helps you distinguish rejected or deleted requirements from the others.
When you store requirements in a tool, an SRS becomes a report generated from the database contents according to specific query and filter criteria. You have several options:
• To see a complete specification for the entire product to date, extract all the requirements for the current version and all previous releases.
• To see the specification for a single release, report just the requirements allocated to that release.
• To see the requirements that were proposed but rejected, or those that never made it into the product in the first place, base your query on the appropriate values of the status attribute.
Requirements management tools overcome many of the limitations of document-based storage. For example, some tools will retain all historical versions of every individual requirement, whereas version control tools generally maintain previous versions of entire documents. Commercial RM tools let you store requirements in a single master location that is always current and is accessible via the Internet to authorized stakeholders. These products aren’t cheap, but their capabilities often outweigh the costs. You can find descriptions and feature comparisons of many commercial RM tools at http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx and http://www.volere.co.uk/tools.htm. Chapter 23 of my book More about Software Requirements (Microsoft Press, 2006) provides recommendations for how to use requirement management tools effectively on a project.
As with so many of the other thorny issues about requirements, there is no perfect and simple solution to the matter of concurrently managing requirements for multiple product releases (or similarly, multiple variations of a single product). It’s most important that your project team determine in advance what techniques and tools it will use to deal with this situation, using the strategies I’ve described here as a starting point.
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. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
