The major consequence of requirements problems is rework—doing over something that you thought was already done. Rework can consume 30 to 50 percent of your total development cost, and requirements errors account for 70 to 85 percent of the rework cost. The data from Hewlett-Packard in Figure 1 shows that it costs far more to correct a defect that’s found late in the project than to fix it early on. Preventing requirements errors and catching them early therefore has a huge leveraging effect on reducing rework. Imagine how different your life would be if you could cut your rework effort in half! You could build products faster, build more and better products in the same amount of time, and perhaps even go home occasionally.

Shortcomings in requirements practices pose many risks to project success. I describe some of the most common requirements risks in this post.

Insufficient User Involvement

Customers often don’t understand why it is so essential to work hard on gathering requirements and assuring their quality. Developers might not emphasize user involvement, either because working with users isn’t as much fun as writing code or because they think they already know what the users need. In some cases, it’s difficult to gain access to people who will actually use the product, and user surrogates don’t always understand what users really need. Insufficient user involvement leads to late-breaking requirements that delay project completion. There’s no substitute for having the development team work directly with actual users throughout the project.

Creeping Requirements

As requirements evolve and grow during development, projects often exceed their planned schedules and budgets. Such plans aren’t always based on realistic understandings of the size and complexity of the requirements; constant requirements modifications make the problem worse. The problem lies partly in the users’ frequent requests for changes in the requirements and partly in the way that developers respond to these requests.

To manage scope creep, begin with a clear statement of the project’s business objectives, strategic vision, scope, and success criteria. Evaluate proposed new requirements or changes against this reference. An effective change process that includes impact analysis will help the stakeholders make informed business decisions about which changes to accept and the associated cost. Change is often necessary, but change always has a price. To minimize quality degradation, flow requirements changes through the architecture and design rather than implementing them directly into code.

Ambiguous Requirements

One symptom of ambiguity is that a reader can interpret a requirement statement in several ways. Another sign is that multiple readers of a requirement arrive at different understandings of what it means. Ambiguity also results from imprecise and insufficiently detailed requirements that force developers to fill in the blanks. Ambiguous requirements result in wasted time when developers implement a solution for the wrong problem. Testers who expect the product to behave differently from what the developers intended waste time resolving the differences.

One way to ferret out ambiguity is to have people who represent different perspectives formally review the requirements. Simply passing around the requirements document for comments isn’t sufficient to reveal ambiguities. Suppose different reviewers interpret a requirement in different ways but it makes sense to each of them. That doesn’t reveal the ambiguity! Writing test cases against the requirements and building prototypes are other ways to discover ambiguities.

Gold Plating

Gold plating takes place when a developer adds new functionality that he believes “the users are just going to love.” Often, users don’t care about that functionality, and the time spent implementing it is wasted. Rather than simply inserting new features, developers and analysts should present the customers with creative ideas and alternatives for their consideration. Developers should strive for leanness and simplicity, not for going beyond what the customer requests without customer approval.

Customers sometimes request features or elaborate user interfaces that look cool but add little value to the product. Everything you build costs time and money, so you need to maximize the delivered value. To reduce the threat of gold plating, trace each bit of functionality back to its origin so that you know why it’s included.

Minimal Specification

Sometimes marketing staff or managers are tempted to create a limited specification, perhaps just a product concept sketched on a napkin. They expect the developers to flesh out the spec as the project progresses. This approach can work with a tightly integrated, agile team that’s building an application incrementally, on exploratory or research projects, or when the requirements truly are flexible. In other cases, though, it frustrates the developers (who might be operating under incorrect assumptions and with limited direction) and disappoints the customers (who don’t get the product they envisioned).

Overlooked User Classes

Most products have several groups of users who might use different subsets of features, have different frequencies of use, or have varying experience levels. If you don’t identify the important user classes for your product early on, some user needs won’t be met. After identifying all user classes, make sure that each has a voice, some person who will work with the business analyst to elicit the needs of a specific user class.

Inaccurate Planning

“Here’s my idea for a new product; when will you be done?” Don’t answer this question until you know more about the problem being discussed. Vague, poorly understood requirements lead to overly optimistic estimates, which come back to haunt us when the inevitable overruns occur. An estimator’s off-the- cuff guess sounds a lot like a commitment to the listener. The top contributors to poor software cost estimation are frequent requirements changes, missing requirements, insufficient communication with users, poor specification of requirements, and insufficient requirements analysis.

Benefits from a High-Quality Requirements Process

A great reward from effective requirements processes comes from reducing unnecessary rework during development and throughout the lengthy operational period. Many people mistakenly believe that time spent discussing requirements simply delays delivery by the same duration. A holistic cost-of-quality perspective, though, reveals the value of emphasizing early-stage quality practices. Sound requirements processes emphasize a collaborative approach to product development that involves multiple stakeholders in a partnership throughout the project. Collecting requirements lets the development team better understand its users or market.

Engaging users in the requirements-gathering process generates enthusiasm for the product and builds customer loyalty. By emphasizing user tasks instead of superficially attractive features, the team can avoid writing code that won’t ever be used. Customer involvement reduces the expectation gap between what the user needs and what the developer delivers. You’re going to get the customer feedback eventually. Try to get it early rather than late, perhaps with the help of prototypes that stimulate user feedback. This is far cheaper than correcting a lot of problems in beta testing or after release. Documented, unambiguous requirements greatly facilitate system testing, which in turn increases your chances of delivering high-quality products that satisfy all stakeholders.

No one can promise a specific return on investment from an improved requirements process. You can go through an analytical thought process to imagine how better requirements could help you, though. First, consider the cost of investing in a better process. This includes the cost of assessing your current practices, developing new procedures and document templates, training the team, buying books and tools, and perhaps using outside consultants.

Your greatest investment is the time your teams spend gathering, documenting, reviewing, and managing their requirements. Next, think about the possible benefits you might enjoy and how much time or money they could save you. You can’t quantify all the following benefits, but they’re real:

• Fewer requirements defects • Reduced development rework • Fewer unnecessary features • Lower enhancement costs • Faster development • Fewer miscommunications • Reduced scope creep • Reduced project chaos • Higher customer and team member satisfaction

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.