It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, we are going to take a look at another book Jerry co-authored with Donald C. Gause: Exploring Requirements – Quality Before Design published by Dorset House Publishing in 1989.
Don Gause and Jerry Weinberg tackle many perspectives around the gathering of requirements in this book. To be honest, I don’t recall much of it years after reading it. The only exception probably is the mentioning of the Dictum in the Swedish Army:
When the map and the territory don’t agree, always believe the territory.
I recall that I reached out to Jerry once to find out about the origin of that Dictum to reference it properly. He basically wrote me back that the origin was personal communication, probably with someone from the Swedish Army.
Upon re-visiting the table of contents for this review, I start to notice that there is more that I regularly use from this book. Gause and Weinberg describe the difference between the problem space and the solution space. The problem space is the area where much of the domain knowledge stems from, and where a potential problem for a user of your system lies. The solution space is the space where possible solutions to a problem lie. If you overlap the two, there usually are several solutions to a given problem. The act of gathering requirements is to explore this overlap and find suitable solutions to a problem while keeping in mind all the other constraints and other solutions – narrowing down the number of solutions we want to implement to just a few.
While going through the table of contents to remember what I have read in it, I find a chapter on ambiguity and the discussion around context-free questions, that starts to ring a bell for me. When talking to users and customers, there may some ambiguity be lurking in the communication. I think this is also the chapter where the term Lullaby language was coined by Jerry. Lullaby language basically consists of terms like “all”, “always”, “never”, and the like. Gause and Weinberg motivate to narrow down these quantifiers in order to make our language less ambiguous. Gojko Adzic took on much of this in his Bridging the Communication Gap book, and later on as well in his Specification by Example book.
Context-free questions help to understand the problem space without judging too much about it. While talking to users and customers, it’s easy to suppose our solutions on them while these don’t solve a problem. Context-free questions help us to really understand the problem before trying to come up with solutions.
Of course, Gause and Weinberg also take a closer look at the quality aspects after requirements have been understood and how they will benefit from the gathering of requirements. They basically included chapters on other phases of the (classical) product development cycle, including technical reviews, test cases, and the like. Since Jerry wrote separate books about all these aspects, I recall having gained more from these subject-specific books.
In hindsight, I took much more from Jerry’s work in the Quality Software Management series or the Secrets of Consulting series with me. Maybe I will tackle these books in the upcoming weeks. Exploring Requirements, nevertheless, is referenced in a couple of ATDD and BDD books. Going through the book, I found a profound quote right at the beginning, that will also conclude this review:
There’s no sense being exact about something if you don’t even know what you’re talking about.John von Neumann