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 […]
The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. […]
The first part in this series of articles presented an overview of requirements traceability, identified the potential kinds of traceability links you could define among a project’s artifacts, and stated several motivations for tracing requirements. This article, adapted from my book Software Requirements, 2nd Edition, describes the requirements traceability matrix. The Requirements Traceability Matrix The […]
Rather than expecting use cases to contain one hundred percent of the system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to […]
I once read a book about use cases that stated, “To sum up, all functional requirements can be captured as use cases, and many of the nonfunctional requirements can be associated with use cases.” I agree with the second part of this sentence, but not with the first part. It is certainly true that use […]
Use cases are recognized as a powerful technique for exploring user requirements. The great benefit they provide is to bring a user-centric and usage-centric perspective to requirements elicitation discussions. The business analyst employs use cases to understand what the user is trying to accomplish and how he envisions his interactions with the product leading to […]
In the first part of this two-part series I described some cues that help the business analyst detect when a customer has presented some input that could be classified as a business requirement, use case, business rule, or functional requirement. This article continues the discussion to help you classify customer input into several other categories […]
As you acquire requirements input from various sources, it comes in all stirred together. People don’t just tidily tell you, “Here are all my business rules, here are all my use cases” and so forth. Instead, the business analyst is bombarded with a more or less random array of information. Therefore, an important part of […]
Some agile software development approaches have as a central tenet the premise that every project needs a full-time, on-site customer who sits with the developers. The rationale is sound. Only knowledgeable and empowered customer representatives can answer questions and flesh out high-level requirements in appropriate detail. Failing to get timely answers or clarification holds up […]
The first article in this series described the critical role of the business analyst in bridging the communication gap between business and IT, understanding project scope, and asking meaningful questions during requirements elicitation. This concluding article continues by exploring several additional contributions that BAs make to a software project. Prioritize Early and Often Requirements development […]
CONNECT WITH US
USA
135 SW Taylor Suite 200
Portland, Oregon, 97204
EUROPE
Amsterdam Queens Tower
Delflandlaan 1, 1062EA Amsterdam
The Netherlands
© 2026 Jama Software