Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn’t work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline. Baseline Defined The […]
Software products are rarely delivered in final form with the first release. More commonly, they evolve through a series of releases or iterations that correct defects, add progressively more features, and enrich or update previously implemented features. This means that during requirements development you’ll be accumulating requirements that could be targeted for various releases. You […]
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 […]
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