Requirements Management

Change Happens

By |

One of the few constants about software development is that change happens. I doubt any project has ever delivered a product that exactly matched its original specifications. Software change isn’t a bad thing. It’s virtually impossible to define all of a product’s requirements up front, and the world changes as development progresses. An effective software team can nimbly respond to necessary changes so that the product they build provides timely customer value. This series of five articles, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003) addresses many aspects of handling requirement changes effectively.

The change process is fraught with problems. Most developers have encountered an apparently simple change request that turned out to be far more complicated than expected. Developers sometimes don’t—or can’t— produce realistic estimates of the cost and other ramifications of a proposed software change. And, when developers who want to be accommodating agree to add enhancements that a user requests, requirements changes slip in through the back door instead of being approved by the right stakeholders. Such uncontrolled change is a common source of project chaos, schedule slips, and quality problems. An organization that’s serious about managing its software projects must ensure that:

  • Proposed requirements changes are carefully evaluated before being committed to.
  • The appropriate individuals make informed business decisions about requested changes.
  • Approved changes are communicated to all affected participants.
  • The project incorporates requirements changes in a consistent fashion.

But change always has a price. Revising a simple Web page might be quick and easy; modifying an integrated chip design can cost tens of thousands of dollars. Even a rejected change request consumes the resources needed to submit, evaluate, and decide to reject it. Unless project stakeholders manage changes during development, they won’t really know what will be delivered, which ultimately leads to an expectation gap. The closer you get to the release date or the end of a development iteration, the more you should resist changing that release because the consequences of making changes become more severe.

The business analyst should incorporate approved changes into the project’s requirements documentation. Your philosophy should be that the requirements documentation will accurately describe the delivered product. If you don’t keep the software requirements specification (SRS) current as the product evolves, its value will decrease and the team might function as though it doesn’t even have an SRS. And requirements documentation that doesn’t match the reality of the product is practically useless as a maintenance aid.

When you need to make a change, start at the highest level of abstraction that the change touches and cascade the impact of the change through related system components. For example, a proposed change might affect a use case and its functional requirements but not any business objectives. A modified high-level system requirement could have an impact on multiple software requirements. Some changes pertain only to system internals, such as the way a communications layer is implemented. These are not user-visible requirements changes but rather design or code changes.

Several problems can arise if a developer implements a requirement change directly in the code without flowing it through the requirements and design descriptions. The description of what the product does, as embodied in the requirements specification, becomes less accurate because the code is the ultimate software reality. The code can become brittle and fragile if changes are made without respecting the program’s architecture and design structure. On one project, developers introduced new and modified functionality that the rest of the team didn’t discover until system testing. This required unplanned rework of test procedures and user documentation. Consistent change control practices help prevent such problems and the associated frustration, development rework, and wasted testing time.

The Change Control Process

While performing a software process assessment once, I asked the project team how they incorporated changes in the product’s requirements. After an awkward silence, one person said, “Whenever the marketing rep wants to make a change, he asks Bruce or Sandy because they always say ‘yes’ and the rest of us give marketing a hard time about changes.” This didn’t strike me as a great change process.

A rational change control process lets the project’s leaders make informed business decisions that will provide the greatest customer and business value while controlling the product’s life cycle costs. The process lets you track the status of all proposed changes, and it helps ensure that suggested changes aren’t lost or overlooked. Once you’ve baselined a set of requirements, follow this process for all proposed changes to that baseline.

Customers and other stakeholders sometimes balk at being asked to follow a new process, but a change control process is not intended to be an obstacle to making necessary modifications. It’s a funneling and filtering mechanism to ensure that the project incorporates the most appropriate changes. If a proposed change isn’t important enough for a stakeholder to take just a couple of minutes to submit it through a standard, simple channel, then it’s not worth considering for inclusion. Your change process should be well documented, as simple as possible, and—above all—effective. If you ask your stakeholders to follow a new change control process that’s ineffective, cumbersome, or too complicated, people will find ways to bypass the process—and perhaps they should.

Managing changes in requirements is similar to the process for collecting and making decisions about defect reports. The same tools can support both activities. Remember, though: a tool is not a substitute for a process. Using a commercial problem-tracking tool to manage proposed modifications to requirements doesn’t replace a written process that describes the contents and processing of a change request.

Change Control Policies

Management should clearly communicate a policy that states its expectations of how project teams will handle proposed requirements changes. Policies are meaningful only if they are realistic, add value, and are enforced. I’ve found the following change control policy principles to be helpful:

  • All requirements changes shall follow the process. If a change request is not submitted in accordance with this process, it won’t be considered.
  • No design or implementation work other than feasibility exploration shall be performed on unapproved changes.
  • Simply requesting a change doesn’t guarantee that it will be made. The project’s change control board (CCB) will decide which changes to implement. A later article in this series discusses the change control board.
  • The contents of the change database shall be visible to all project stakeholders.
  • The original text of a change request shall not be modified or deleted.
  • Impact analysis shall be performed for every change.
  • Every incorporated requirement change shall be traceable to an approved change request.
  • The rationale behind every approval or rejection of a change request shall be recorded.

Of course, tiny changes will hardly affect the project and big changes will have a significant impact. In principle, you’ll handle all of these through your change control process. In practice, you might elect to leave certain detailed requirements decisions to the developers’ discretion, but no change affecting more than one individual’s work should bypass your change control process. However, your process should include a “fast path” to expedite low-risk, low-investment change requests in a compressed decision cycle.

The sweet spot is to establish a set of change control policies and practices that facilitate making good, timely change decisions, without misusing the process as a barrier to halt any changes. Change is inevitable—deal with it. The remaining articles in this series will look at the change control process in some detail, the change control board, change control tools, and performing impact analysis for proposed changes.

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.

 

Latest posts by Karl Wiegers (see all)