Wasted time and money

Strained business/IT relationships

Missed Project Deadlines

Are These Your Requirements Problems?

Requirements errors are the greatest source of defects and quality problems.
(Schwaber, 2006; Weinberg, 1997; Nelson et. al, 1999)

“Deficient requirements are the single biggest cause of software project failure.”
(Hofmann and Lehner, 2001)

Are bugs in your software costing you money? Did you know that most defects originate in the requirements phase? They do! If you don’t do requirements right, this one part of your software development effort can cost you the most in time, money, and customer dissatisfaction.

Success with requirements pays off - quickly. See how

Why aren’t YOU doing requirements right? Read more

Can you relate to these situations?

Wasted time and money

Is your team hampered by tight budgets due to rework? 

Are your customers frustrated by long meetings that go nowhere in clarifying their business needs?

Are you spending precious time and money writing up requirements that never get implemented?

Our clients used to have requirements problems, too. Read more

Poor requirements are one of the biggest reasons for failed projects. Poor requirements mean rework, and rework delays your delivery and eats up staff time. Read more

Top risks for projects center on requirements problems: unstable, constantly changing requirements (66% risk) and poor specifications (66% risk) (Rodrigues, 2001).

Requirements errors contribute to one-third of total delivered defects (Leffingwell and Widrig, 1999).

Requirements processes are the source of most (50% or more) serious quality problems (Weinberg, 1997).

50% of all software errors are requirements errors (Nelson et al, 1999).

50% of defects are due to requirements problems (Schwaber, 2006).
Note: citations are at the bottom of this page

Most of the requirements you specify never get implemented (The Standish Group International, 2003b).

You can’t afford not to meet business needs. The pressure is great. Time to market is compressed. Competition is fast and furious. Complying with regulations is harder than ever. Failing to get the right requirements can cost you precious time, money, and customer goodwill.

Fixing requirements errors eats up roughly one-third of your software project budget. If you’re budgeting $500,000, you’re spending about $150,000 fixing defects that originate in your requirements.

Requirements errors consume 28% to 42.5% of total software development costs (Hooks and Farry, 2001).

Fixing requirements errors consumes 70 to 80 percent of a project’s rework costs (Leffingwell, 1997).

Overall, rework costs 40 to 50 percent of the total software development budget (Jonesb, 1996; Boehm, 1987).

It will cost you—big time—for not finding and fixing bad requirements as soon as possible. The cost to repair missing, erroneous, incomplete, inconsistent, or ambiguous requirements grows exponentially as your product development lifecycle proceeds. It’s much cheaper to detect and fix errors earlier—during requirements—than later in development. A requirements error, left undetected, can cost you 20 to 100—even 400— times the cost to fix it downstream. You do the math. Read more

Finding and fixing defects outside their phase of injection can cost you 400 times as much. It might cost $25 to $100 to find and fix a requirements error during the requirements phase.  But if you don’t find that error until the product is transitioned to the customer, repairing it can cost you $8,000 to $10,000 (Reifer, 2007).

A requirements error can take 50 times as much to correct in testing as in the requirements phase (Dabney and Barber, 2003).

Finding and fixing requirements defects after system delivery is often 100 times as expensive as finding and fixing them during the requirements and design phases (Boehm and Basili, 2001).

Fixing a defect in requirements versus downstream in testing can cost you 5 times more, and 100 times more once it is transitioned to your customer. This is known as the 1-5-100 rule. You can spend $1 finding and fixing an early lifecycle error (such as requirements errors), $5 to correct it halfway through your project, and $100 to correct it late in the development lifecycle (Nelson et al., 1999).

It can cost you up to 110 times more to correct a requirements defect found in production than if that same defect were found during requirements development (Grady, 1999).

Reworking a requirements problem costs 50 to 200 times what it would take to fix it during the requirements phase (Boehm and Papaccio, 1988).
Note: citations are at the bottom of this page

EBG provides training and consulting in requirements development and management good practices based on real-life, practical experience. You will gain skills and techniques that work in YOUR environment.

Top of page

Strained business/IT relationships

Frustrated by endless meetings to try to explain your requirements to technical staff?

Buried under reams of requirements docs that don’t give you what you really need?

Is your technical staff continually complaining about uncooperative or unavailable business experts?

Are you losing valuable time and effort trying to keep up with requirements that are constantly changing?

Our clients used to have these requirements problems, too. Read more

Customer involvement is one of the, if not the, most important factor in a project’s success. We feel your pain—we know that these disconnect between business and IT people result in costly defects and unhealthy relationships. But business people and IT people CAN work effectively together to define the right requirements. They just have to know how.

Many defects result from missing nonfunctional requirements and poor understanding of requirements dependencies, and they result in costly rework (Light, 2005).
The highest-ranking project success factor is user or customer involvement (Standish group, 2003).

Collaboration is crucial—but collaboration doesn’t just happen. It needs to be engineered into your project. Both sides of the relationship—business and IT—are accountable to develop the right requirements together (Schwaber, 2006; Gottesdiener, 2002; Rodrigues, 2001).

Text requirements (“the system shall…” statements) are not the best way to articulate user needs. They have their place when you need formal specifications, but most successful projects also use other techniques to explore business and user requirements.

Adopting different ways to define and represent requirements helps involve different stakeholders and reduces the risk of missing requirements (Schwaber, 2007).

To be effective, business analysts need to know and use an appropriate combination of requirements techniques. This includes using multiple, interconnected analysis models. These models need to be developed iteratively and verified and validated continually with customers.

The highest-ranking project success factor is user or customer involvement (Standish group, 2003).
To prevent defects, the best combination includes a variety of elicitation, verification, and validation techniques. This approach can prevent 37% of defects and can slash total development costs by 6% (Lauesen and Vinter, 2001).

In our training and consulting EBG Consulting is widely recognized for our emphasis on collaboration. You will reduce conflict and build effective relationships. Your business analysts will learn essential skills that translate into better requirements, cost savings, and satisfied customers.

Top of page

Missed project deadlines

Is your team missing deadlines? Are you under pressure to deliver faster?

Do your requirements seem to constantly change and grow?

Are you exploring agile methods to accelerate delivery? Are you worried about how this will affect your team’s attitudes and productivity?

Are you rushing to select and install a packaged software solution like COTS (commercial off-the-shelf software)? Do you worry that you’ll pick the wrong product?

Are you hoping that outsourcing will reduce your delivery cycle and fix your requirements difficulties?

Is your organization involved in corporate process improvement activities (such as BPM or Six Sigma) to streamline delivery of business solutions? Are you worried about how to incorporate this into your business processes and work flows?

Our clients used to have these requirements problems, too. Read more

Scope creep is the highest risk for software development projects. Unrestrained by good requirements practices and mutual agreement between customers and product developers, the scope of the project expands as the work proceeds. We all know that market and business conditions change, and requirements have to change, too. But you CAN avoid the kind of scope creep that happens when you haven’t skillfully explored, clarified, and prioritized requirements. Read more

One of the top three risks for projects is related to customer issues—approval delays, requirements changes, and poor communication (42% risk) (Rodrigues, 2001).

80% of all projects are at risk of creeping user requirements (Jones, 1996).  
Scope creep is one of the most common, and sometimes the most common, source of cost and schedule overruns, and it is a major factor in project cancellations (Jones, 1996c; Lederer and Prasad, 1992; Vosburgh et al., 1984).

Not getting your software’s requirements right will lead to big problems. The formal requirements phase takes about 5 percent of your software effort, but the accumulated time spent on requirements—formal requirements plus creeping requirements—takes as much as 30 percent of your time (Boehm, 1981; Jones, 2000).

Problems with requirements—frequent changes, missing requirements, insufficient user communication, poor specifications, and insufficient analysis—account for the five top causes of poor software cost estimation (Davis, 1995).

The development team can spend as much as 30 to 80 percent of their project effort reworking mistakes they made earlier (Fagan, 1976).
Note: citations are at the bottom of this page

Agile methods, COTS (commercial off-the-shelf software), outsourcing —there is no silver bullet. Even if you use these techniques, you still need to articulate product requirements. To achieve your goals, you’ve got to adopt effective business and user requirements practices.

If you’re adopting agile practices, it doesn’t mean that you don’t need requirements. With agile approaches, you successively elaborate requirements. Agile is not just about speed and lightweight documentation. It’s also about suitable adaptation to yield economic value. To avoid thrashing, you must balance fast definition of needs with the quality of your requirements. And if you’re building a large, complex product, it would be a huge mistake to jump into iteration planning without first defining your product and release roadmaps.  

Many organizations want to accelerate delivery by seeking and installing COTS (commercial off-the-shelf software) package solutions. You may think that requirements are not needed if you buy a packaged solution. Not so. In these situations, business analysis is critical to prepare for the business process changes that will undoubtedly impact your business community.

You cannot make good software acquisition choices unless you have a baseline of requirements (including design and implementation constraints). And when it’s time to implement your software package, your business process models and requirements are the basis for implementation.

“Relying on [external service providers] to capture, define and redefine requirements is often more costly than doing it internally and then coordinating with the [external service provider].” (Light, 2005)

When you outsource your project, the need for requirements development becomes even more critical. You have to have clear requirements analysis and specification. And you will save time and money by doing the business analysis yourself. Your internal business analysts should develop and manage requirements and act as the communication points with your external providers. The role of the business analyst is more crucial than ever; your organization depends on them to help you meet your delivery deadlines by articulating clear and comprehensive requirements.

“Companies are looking to [business] analysts to lead them into the Promised Land of business agility.” (Henschen et al., 2007)

If you’re struggling with requirements, EBG will help you get the right stuff, fast, to start smart.

Success with requirements pays off - quickly. See how

Why aren’t YOU doing requirements right? Read more

 For a list of cited research materials, click here

Top of page