Parent and Child Requirements When writing requirements in a hierarchical fashion, the BA records a parent requirement and one or more child requirements. The parent requirement is satisfied by implementing all of its children. Here’s an illustration of a hierarchical requirement with some problems: 3.4 The requester shall enter a charge number for each chemical […]
Writing requirements is hard! There is no simple, formulaic approach to software specification. High-quality requirements begin with proper grammar, accurate spelling, well-constructed sentences, and a logical organization. This series of four articles, adapted from my book More about Software Requirements (Microsoft Press, 2006), presents numerous style guidelines to keep in mind when writing functional requirements. […]
Whether you like it or not, requests to modify the requirements are going to come your way on a software project. To keep the inevitable changes from throwing your project into chaos, someone has to make the decisions about which changes to accept and which to reject. The industry-standard term for these decision makers is […]
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 […]
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