I admit it: I’m a process kind of guy. My opinion is that any time we have a relatively complex activity that needs to be performed numerous times and involves multiple people, it’s a good idea to write down the steps in that activity. It’s also a good idea to train people so they know […]
One of the few constants about software development is that change happens. I doubt any project has ever delivered a product that exactly matched its original specifications. Software change isn’t a bad thing. It’s virtually impossible to define all of a product’s requirements up front, and the world changes as development progresses. An effective software […]
In the previous article in this series, I described several conditions in which writing less detailed requirements is appropriate. However, there are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article (adapted from my book More about Software Requirements), expect […]
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 […]
USA
135 SW Taylor Suite 200
Portland, Oregon, 97204
EUROPE
Amsterdam Queens Tower
Delflandlaan 1, 1062EA Amsterdam
The Netherlands
© 2025 Jama Software