Gause D., Exploring Requirements: Quality Before Design (1989)
Many well-written books on requirements sink into details trying to establish formal processes that promise flawless execution. Often they create rigid complicated systems, difficult to apply in practice.
This book provides seemingly forgotten basics that flexibly guide our requirements journeys leading to unambiguous knowledge and products customers love. It can serve as the single comprehensive source of basic knowledge, allowing beginners to start practicing requirements extraction right away—both in substance and process.
For reference, here is a number of more modern practical books on the subject worth to study: 1, 2, 3.
The intro is so much to the point that I just put this long quote here.
[Gause D.] Before you invest your time in a book, you want to know what you'll get from reading it. This book is about development projects. In particular, it's about tasks that ought to be done before pieces of a product are designed and built.
Similarly, in a development project, you want to know what you'll get from building something before you're willing to invest too much of your time. But unless you know what you want, you'll never be very sure of what you'll get.
If you employ other people to help you develop what you want, you'd describe to them what you want. Such a description is called a problem statement or a set of requirements, and that's what this book is about. Obviously, requirements are important because if you don't know what you want, or don't communicate what you want, you reduce your chances of getting what you want. (p. 11)
Summary
The book contain 5 parts. It mimics the a team process of going from zero domain understanding to a designed product - the list of qualities and functionality it should possess. Here is are the parts of the process and the book:
- I. Negotiating a Common Understanding
- II. Ways to Get Started
- III. Exploring the Possibilities
- IV. Clarifying Expectations
- V Greatly Improving the Odds of Success
Most chapters end with "Helpful Hints and Variations" and "Summary" sections, making self-study convenient—both for skimming and for repeated reference
In the review I concisely present a selected core valuable observations in the order they appear in the book.
The PDF book is presented in 2 parts therefore page numbers start from 1 in the second book.
I. Negotiating a Common Understanding
Book 1.
(ch. 1: Methodologies Aren't Enough, p. 13)
Each method exploring requirements has its own visual notation, a symbolic language 1 to document the requirements' elements and parties for future use and refinement. Whatever symbolic language is used it should be easy to update and familiar to every stakeholder (p. 18). The book calls these documents maps to convey the exploratory process of requirements elicitation.
Maps of requirements are not requirements. When the map and reality diverge, trust reality and revise maps (p. 20, 25). Maps are required to keep and share the common understanding across people and time.
Share complex design expertise with customers willing to participate in design to allow them contributing better value to design. Learn the problem domain from those customers to speak the same language 2 to bring better value to to design.
(ch. 2: Ambiguity in Stating Requirements, p. 27)
Ambiguity in requirements comes from human misunderstanding (missing instructions, ambiguous words) and costs 1 to 1000 times depending on the stage of the project the requirements error is discovered 3.
All stakeholders in a project, including engineering, pretty clearly known what they want from product and what they do not want. The third group is ambiguous knowledge. To convert it to clear requirements explore the subject domain iteratively, with different stakeholders and from different angles. Document and refine (p. 34).
The relative costs of fixing the requirements errors on different project stages
II. Ways to Get Started
(ch. 5: Starting Points, p 68)
Starting points can be a defined problem with non-existent solution or vise versa. The start of the design can brig biggest errors. If you find yourself designing or building the product with no clearly documented starting conditions, revisit the starting point, scrutinize and document the requirements. Chose the clear unambiguous name for the project at starting point.
(ch. 6: Context-Free Questions, p. 82)
Context-free questions on process and product are the primary source of problem domain knowledge. Meta-questions - questions probe if there is more domain knowledge to discover, what we did not get from process or product questions or how / where to better get the missing domain knowledge.
See the example lists of these type of questions on p. 90.
(ch. 7: Getting the Right People Involved, p. 95)
Identify right people to explore requirements with. Customers are not necessarily users. Group users. Requirements always have to be explored with users that a product targets. See Railroad Paradox explaining peculiarities of finding target customers for non-existent products and Pareto Optimization vs Veblen Principle to demoing user benefits trade-off.
Include as many user types as imagined in the initial list. Prune the list to keep only desired types.
(ch. 8: Making Meetings Work for Everybody, p. 111)
Meetings are used to explore requirements. If your meetings are terrible the process is sick. The participation and safety, efficiency and effectiveness rules for meetings are given.
(ch. 9: Reducing Ambiguity from Start to Finish, p. 126)
4 interesting ambiguity-reducing heuristics are given.
III. Exploring the Possibilities
[Gause D.] The following chapters will discuss exploration tools for discovering some of the exciting destinations possible in the requirements process. 4
(ch. 10: Idea-Generation Meetings, p. 144)
The new unexplored territories require idea generation process. Short but effective explanation of conducting structured, effective brain-storming meetings is provided.
(ch. 11: Right-Brain Methods, p. 158)
The methods to visualize requirements in addition to textual documentation are Sketching, Wiggle Charts, Braindrawing, Right-braining.
(ch. 12: The Project's Name, p. 167)
The importance of the effective project name is discussed with its place in the requirements mapping, selection, functions and demands.
(ch. 13: Facilitating in the Face of Conflict, p. 176)
The inessential and essential conflicts are discussed with conflicts typology and the ways of treatment are proposed.
IV. Clarifying Expectations
Book 2
(ch. 14: Functions, p. 3)
After the possibilities were explored it is time to plan the product functionality. Functions are statements about what product should do that start from phrases "We want the product to...".
The designers must capture all functions and only the functions. This can be done by brainstorming 5. Select the functions that are desired by customer. Group them into Evident, Hidden and Frill groups (p. 17). Identify overlooked functions and avoid implied solutions.
(ch. 15: Attributes, p. 28)
A Rolls Royce has more or less the same functions as a Ford, but many, many different attributes.
Create the attributes wish list. Distinguish between attributes and their details. Uncover attribute ambiguity. Organize the list (p. 33) and discover the insights from it. Assign attributes to functions. Gain insights from the resulting document. Categorize attributes by Must, Want and Ignore and exclude what needs to be excluded (p. 38).
(ch. 16: Constraints, p. 43)
A constraint is the mandatory condition placed on an Must attribute when you examine attributes. The final design solution is acceptable when every constraint is satisfied. The constraint is defined the way enabling participants to determine objectively whether it is satisfied in the finished product.
Example:
- attribute: length;
- constraints: must be greater then 0; must be less than 10 cm;
Constraint must be tested against being: too strict, not strict enough, unclear (p. 48). Interrelated and overconstraints either broaden the solution space to unimplementable or shrink it to inexistent (p. 51).
(ch. 17: Preferences, p. 64)
A preference is a desirable and optional condition placed on an attribute. Out of the possible solutions designers select the ones that satisfy preferences. Preferences come from the client, not the designer Preferences are the attributes that improve a solutions, not that constrain it.
Unconstrained preferences (p. 72) lead to spending efforts on optional attributes that may harm product launch. Constrain preferences in favor of non-optional behavior using "what's-it-worth?" analysis (p. 74).
(ch. 18: Expectations, p. 84)
Understand why different user expectations arise and apply heuristics to discover and limit user expectations. The limitation allows to explore and clarify the expectations for each user group separately.
Reasons to limit expectations: people are not perfect, not logical, perceive things differently, designers are people too. Importance of limiting: it impacts the variety and value of design solutions. Omitted limiting leads to missing solutions or categories of solutions due to unconscious nature of limiting.
Steps to limit expectations (p. 88):
- Generate a specific expectation list
- Generalize the expectation list
- Limit the expectations: categorize according to feasibility - Achievable now, Deferred for later, Impossible;
Explicit upfront limitations are better on users than sudden ones after the fact.
V. Greatly Improving the Odds of Success
(ch. 19: Ambiguity Metrics, p. 105)
Measure requirements ambiguity with a poll of informed individuals, using 3 kinds of ambiguity:
- Problem-statement ambiguity
- Design-process ambiguity
- Final-product ambiguity
The measured ambiguity allows to understand the amount of design work remained.
(ch. 20: Technical Reviews, p. 115)
Technical reviews test whether requirements contain all and only reliable information. They include only experts on the subject matter and deal solely with technical issues. They feedback management on the actual technical status of the project. They feed information to subsequent project reviews.
Technical reviews provide customers, users, and management a reliable answer to the fundamental question: Does this requirement do the job it's supposed to do?
Principal Types of Review (p. 125):
- Vanilla reviews
- Inspections
- Walkthroughs
- Round-robin reviews
(ch. 21: Measuring Satisfaction, p. 131)
Measure user satisfaction to avoid dissatisfaction. Do it along the way, as the design takes form. Test attributes, make a custom test for each project, use other test types (non-formal, prototypes etc.). Conduct satisfaction tests and measure satisfaction.
(ch. 22: Test Cases, p. 146)
We can test the requirements developed so far for completeness, accuracy, clarity, and conciseness of any requirements. Use black box testing.
(ch. 23: Studying Existing Products, p. 161)
Use the existing product to test the adequacy of the requirements job. Use them as a norm, interview users about what and why is missing in the new and old product.
(ch. 24: Making Agreements, p. 172)
Elevate all assumptions to consciousness so you can control them as the development process continues. Do this in written, trace assumptions to their sources, get participants to sign the document.
(ch. 25: Ending, p. 183)
Pay special attention to ending the requirements process because fears of imperfection can lead you into endless cycles.
Footnotes
-
The modern approaches to visually document requirements are quite well covered in Beatty J., Visual Models for Software Requirements (2012) ↩
-
Does it remind you the DDD's Ubiquitous Language that appeared nearly 1.5 decades later? ↩
-
See Boehm B., Software Engineering Economics (1981), p.39. ↩
-
There exist is a couple of interesting modern methods that conclude or compliment raw requirements with even deeper domain knowledge extraction and modeling (designing) processes and products. They are EventStorming and Domain Storytelling. Another great approach is Knowledge Crunching of DDD (see Evans E., DDD: Domain-Driven Design (2004), p. 7). ↩
-
There is a number of other techniques like of observing domain experts or users behavior, listening to them thinking aloud, interviewing, documentation analysis etc. ↩