Tools and techniques for tracking changes to software requirements

Is it necessary to track changes to requirements? In an earlier “Ask the Experts” answer, I noted that best practice organizations track requirements changes with respect to a baseline. If you don’t track changes, you risk scope creep and miscommunication among project team members and stakeholders.

Two types of requirements changes need to be tracked:

• Changes to the actual content and intent of a requirement or to the terminology used to explain it.
• Changes to the attributes that help characterize a requirement, such as its status, its source, planned release, estimated size, and priority.

What kind of tracking tool should you use? That depends on several factors: the kinds of changes you’re tracking (content or attributes), whether you’re trying to measure the effectiveness of your requirements practices, the size of your team, the formality of your organization, regulatory constraints, and whether you have more than one way to track changes. Choose the lightest-weight tracking mechanism that meets your needs. If you choose a more rigorous system than you need, you risk either increasing your project overhead or decreasing the likelihood that your team will honor its responsibilities for tracking changes.

Here’s the spectrum of ways to track requirements changes:

• Keeping it simple: For some organizations, it may be sufficient to record changes in a requirements document or maintain a simple change log document or spreadsheet.
• Using version management software: Some version management software lets you create versions of anything, including the content of requirements. You can use it to baseline and update the content, comment on the reason for a change, and revert to a previous version of a requirement. You can often use this kind of software to measure requirements volatility (the frequency of requirements content changes).
• Using change management software: Change management software lets you classify, track, monitor, and collect measurements about changes of any kind, including changes to requirements content or attributes. Many change management tools also let you automate all or part of a change management process, especially approvals of content changes. Some applications also include version management capabilities; others focus solely on supporting change control activities. You can use the measurements you collect from change management tools to help evaluate the effectiveness of your requirements practices.
• Using requirements or visual modeling tools (or both) to capture, baseline, and track changes to requirements content and attributes: These tools are referred to as requirements definition and management (RDM) tools by tool vendors. Implementation might be as simple as keeping a change log along with the most recent version of the requirement. Some RDM tools store and retrieve previous versions either internally or by invoking the services of a version management tool. RDM tools that provide traceability enable requirements change activities by supporting change impact analysis.

Often, organizations choose to represent many or all of their requirements as visual models.  Many visual modeling tools no longer provide their own version and change management services. Instead, they invoke the services of version management or change management software to let you track changes to the content or attributes of the models.

Whether the tool you use is text based or visual, the specific tool you choose will determine how small a requirements change you can detect and track. Highly regulated organizations often must track all changes rigorously, no matter how small the changes are, and must be very careful to pick tools that will meet their needs.

• Using team collaboration software: Products are now available to explicitly integrate an organization’s existing software development environment with components for capturing requirements content and attributes and for implementing version and change management, thereby enabling team collaboration. These tools can be configured to reduce the overhead associated with tracking requirements changes.

Additionally, it’s possible to track changes in requirements attributes by using project or resource management software. By choosing this option, organizations using waterfall or iterative development approaches often track content changes separately, using a requirements tool, and create a cross reference between content changes and attribute changes when needed. For Agile organizations using user stories to capture and trace requirements, and as the basis for Agile planning, a better choice might be to use Agile project management tools for requirements management.

It’s not a problem to track requirements content and attribute changes in separate places. But this practice exposes you to the risk of duplication of effort or inconsistent definition or tracking. Thus, it’s a good idea to choose a single tool to track your requirements content changes and a single tool (maybe the same tool) to track your requirements attribute changes. If, for whatever reason, you must track either kind of change in more than one place, designate one location as the authoritative record of the change. If you are recording changes redundantly, then, whenever possible, you should use automation to replicate the record of the change from the authoritative record to the duplicate storage.