Requirements & Requirements Management

Improving Your Requirements Processes

By |

Books on business analysis and requirements engineering, such as my own Software Requirements, describe dozens of “good practices” that can help any organization improve the way it develops and manages requirements for its products. Learning about the practices is one thing; implementing them and reaping the benefits is quite another.

Putting better practices into action is the essence of software process improvement. In a nutshell, process improvement consists of using more of the approaches that work well for us and avoiding those that have given us headaches in the past. However, the path to improved performance is paved with false starts, resistance from those who are affected, and the frustration of having too little time to handle current tasks, let alone improvement programs.

The ultimate objective of software process improvement is to reduce the cost of creating and maintaining software. There are several ways to accomplish this:

  • Correcting problems encountered on previous or current projects.
  • Anticipating and preventing problems that you might encounter on future projects.
  • Adopting practices that are more efficient than the practices currently being used.

If your team’s current methods seem to work well (or if people insist that they do despite evidence to the contrary), people might not see the need to change their approach. However, even successful software organizations can struggle when confronted with larger projects, different customers, long-distance collaborations, tighter schedules, or new application domains. An approach that works for a co-located team of five people with a single customer doesn’t scale up to 125 project participants located in two different time zones who are serving hundreds of corporate customers. At the least, you should be aware of other approaches to requirements that could be valuable additions to your software engineering tool kit.

Let’s begin our journey through requirements process improvement by seeing how requirements activities relate to various other key project processes. Changing how your projects handle requirements will of necessity affect these other processes, and vice versa. If you want to succeed with requirements improvement, you’ll need to get the owners of these other process areas to play along.

How Requirements Relate to Other Project Processes

Requirements lie at the heart of every well-run software project, supporting and enabling the other technical and management activities. Figure 1 illustrates some connections between requirements and other processes; the sections that follow briefly describe these process interfaces.

Figure 1. Relationship of requirements to other project processes.

 

Project planning. Too often, project deadlines and staff allocations are determined before the requirements are well understood. It’s no wonder then that so many projects overrun their schedules and budgets. A more realistic approach is to make requirements the foundation of the project planning process. The planners select an appropriate software development life cycle and develop resource and schedule estimates based on the requirements. Thoughtful planning might indicate that it’s not possible to deliver the entire desired feature set within the available bounds of resources and time. The planning process can lead to reductions in the project scope or to selecting an incremental or iterative to deliver functionality in planned chunks.

Project tracking and control. Project tracking includes monitoring the status of each requirement so that the project manager can see whether construction and verification are proceeding as intended. If not, management might need to request a scope reduction through the change control process. If you find early on that your team isn’t implementing requirements as quickly as planned, you’ll need to adjust the expectations to reflect the reality of your team’s productivity. Sometimes this means reallocating lower priority requirements from the backlog into later iterations than planned. It doesn’t matter whether you, your managers, or your customers like this or not: that’s just the way it is.

Change control. After a set of requirements has been baselined, all subsequent changes should be made through a defined change control process. The change control process helps ensure that:

  • The impact of a proposed change is understood.
  • All people who are affected by a change are made aware of it.
  • The appropriate people make informed decisions to accept changes.
  • Resources and commitments are adjusted as needed.
  • The requirements documentation is kept current and accurate.

System testing. The testing and requirements processes are tightly coupled. User requirements and functional requirements are key inputs to system testing. If the expected behavior of the software under various conditions is not clearly specified, the testers will be hard-pressed to identify defects and to verify that all planned functionality has been implemented as intended. An excellent starting point is to start thinking about testing from the very beginning. Think of user acceptance tests for each requirement as you specify it. This is a great way to identify missing exceptions and ambiguous requirements.

Construction. Although executable software is the ultimate deliverable of a software project, requirements form the foundation for the design and implementation work, and they tie together the various construction work products. Use design reviews to ensure that the architecture and detailed designs correctly address all of the requirements, both functional and nonfunctional. Unit testing can determine whether the code satisfies the design specifications and the pertinent requirements. Requirements tracing lets you document the specific software design and code elements that were derived from each requirement.

User documentation. I once worked in an office area that also housed the technical writers who prepared user documentation for complex software-containing products. I asked one of the writers why they worked such long hours. “We’re at the end of the food chain,” she replied. “We have to respond to the final changes in user interface displays and the features that got dropped or added at the last minute.” The product’s requirements are an essential input to the user documentation process, so poorly written or late requirements will lead to documentation problems. The long-suffering people at the end of the requirements chain, such as technical writers and testers, are often enthusiastic supporters of improved requirements engineering practices.

The central point here is that you can’t modify your requirements practices in a vacuum. The thoughtful improvement leader will consider the context and identify stakeholders of other internal processes who would be affected by changes in the requirement development and management processes. By engaging those counterparts in a collaborative effort to improve the way your teams approach requirements, everyone will come out ahead.

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)