In the first article in this series, I pointed out that there’s no easy answer to the question of how detailed the requirements need to be. Instead, I can present a thought process the business analyst can use to assess the appropriate level of detail for each case. As I describe in this article, which […]
Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed […]
Experienced project managers and developers understand the value of translating software requirements into robust designs and rational project plans. These steps are necessary whether the next release represents one percent or one hundred percent of the final product. This article explores some approaches for bridging the gap between requirements development and a successful product release. […]
I don’t know of any way to be absolutely certain that you have not missed any requirements during elicitation. This makes it hard to know just when you can declare your set of requirements—whether for the full product or just the next iteration—complete. Even though you can’t know for sure if you’re done, at some […]
If you’re going to go to all the trouble to build software system, you’d like to be confident that you’re working from the right requirements. You’d like to know that the product you build has a high chance of satisfying customer needs and will let them get their jobs done in a way they find […]
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 […]
I’ve been a big fan of technical peer reviews and inspections for nearly twenty-five years now. I’ve seen the benefits, and I’ve learned something from every review in which I’ve participated. Weaving peer reviews into the cultural fabric of an organization takes time, though. A new review process is fragile, being easily disrupted by unpleasant […]
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 […]
CONNECT WITH US
USA
135 SW Taylor Suite 200
Portland, Oregon, 97204
EUROPE
Amsterdam Queens Tower
Delflandlaan 1, 1062EA Amsterdam
The Netherlands
© 2025 Jama Software