Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > titles


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

Contents of

Exploring Requirements:
Quality Before Design

by Donald C. Gause and Gerald M. Weinberg

*Now in softcover, at a lower price*

ISBN: 978-0-932633-73-6  
©1989  320 pages   softcover  
$39.95 (plus shipping)

Subject(s): Requirements Engineering, Systems Analysis, Systems Design

For customers interested in the hardcover edition: Please note that we have a limited number of hardcover edition books (ISBN: 978-0-932633-13-2), available for their original price of $44.95, plus shipping. Contact us via e-mail, telephone, or fax to request hardcovers.

*For UPS Ground within U.S. only.
For more info., or for Int.'l or rush orders, click here.

Rate this


Part I: Negotiating a Common Understanding

1. Methodologies Aren't Enough

1.1 CASE, CAD, and the Cockroach Killer
1.2 Methods' Effects on Problems
1.3 Maps and Their Notation
1.4 Making Sure That Everyone Can Read the Map
1.5 Maps of Requirements Are Not Requirements
1.6 Helpful Hints and Variations
1.7 Summary

2. Ambiguity in Stating Requirements

2.1 Examples of Ambiguity

2.1.1 Missing requirements
2.1.2 Ambiguous words
2.1.3 Introduced elements

2.2 Cost of Ambiguity

2.3 Exploring to Remove Ambiguity

2.3.1 A picture of requirements
2.3.2 A model of exploration

2.4 Helpful Hints and Variations

2.5 Summary

3. Sources of Ambiguity

3.1 An Example: The Convergent Design Processes Lecture
3.2 A Test for Attentiveness
3.3 The Clustering Heuristic

3.3.1 Observational and recall errors
3.3.2 Interpretation errors
3.3.3 Mixtures of sources of error
3.3.4 Effects of human interaction

3.4 Problem Statement Ambiguity

3.5 Helpful Hints and Variations

3.6 Summary

4. The Tried but Untrue Use of Direct Questions

4.1 Decision Trees

4.1.1 Order of questions
4.1.2 Traversing the decision tree: an example

4.2 Results of an Ambiguity Poll

4.3 What Could Possibly Be Wrong?

4.4 Real Life Is More Real Than We Like to Think

4.5 Helpful Hints and Variations

4.6 Summary

Part II: Ways to Get Started

5. Starting Points

5.1 A Universal Starting Point
5.2 Universalizing a Variety of Starting Points

5.2.1 Solution idea
5.2.2 Technology idea
5.2.3 Simile
5.2.4 Norm
5.2.5 Mockup
5.2.6 Name

5.3 The Can-Exist Assumption
5.4 An Elevator Example

5.4.1 Naming our project

5.5 Helpful Hints and Variations
5.6 Summary

6. Context-Free Questions

6.1 Context-Free Process Questions
6.2 Potential Impact of a Context-Free Question
6.3 Context-Free Product Questions
6.4 Metaquestions
6.5 Advantages of Context-Free Questions
6.6 Helpful Hints and Variations
6.7 Summary

7. Getting the Right People Involved

7.1 Identifying the Right People

7.1.1 Customers versus users
7.1.2 Why include the users?
7.1.3 The Railroad Paradox
7.1.4 The product can create users
7.1.5 Are losers users?

7.2 A User-Inclusion Heuristic

7.2.1 Listing possible user constituencies
7.2.2 Pruning the user list

7.3 Participation

7.3.1 Who participates?
7.3.2 When do they participate?
7.3.3 How do we get their judgments?

7.4 Plan for Capturing Users
7.5 Helpful Hints and Variations
7.6 Summary

8. Making Meetings Work for Everybody

8.1 Meetings: Tools We Can't Live With, or Without

8.1.1 A terrible, but typical, meeting
8.1.2 Meetings as measurements

8.2 Participation and Safety

8.2.1 Establishing an interruption policy
8.2.2 Setting time limits
8.2.3 Outlawing personal attacks and put-downs
8.2.4 Reducing pressure
8.2.5 Allowing time to finish, yet finishing on time
8.2.6 Handling related issues
8.2.7 Amending the rules

8.3 Making It Safe Not to Attend a Meeting

8.3.1 Publishing an agenda and sticking to it
8.3.2 Staying out of emergency mode
8.3.3 Handling people who don't belong
8.3.4 Including the right people

8.4 Designing the Meeting You Need
8.5 Helpful Hints and Variations
8.6 Summary

9. Reducing Ambiguity from Start to Finish

9.1 Using the Memorization Heuristic
9.2 Extending the Ambiguity Poll
9.3 "Mary had a little lamb" Heuristic
9.4 Developing the "Mary conned the trader" Heuristic
9.5 Applying the Heuristics to the Star Problem
9.6 Helpful Hints and Variations
9.7 Summary

Part III: Exploring the Possibilities

10. Idea-Generation Meetings

10.1 A Typical Brainblizzard
10.2 First Part of the Brainstorm

10.2.1 Do not allow criticism or debate
10.2.2 Let your imagination soar
10.2.3 Shoot for quantity
10.2.4 Mutate and combine ideas

10.3 Second Part of the Brainstorm

10.3.1 Voting with a threshold
10.3.2 Voting with campaign speeches
10.3.3 Blending ideas
10.3.4 Applying criteria
10.3.5 Scoring or ranking systems

10.4 Helpful Hints and Variations
10.5 Summary

11. Right-Brain Methods

11.1 Mapping Tools

11.1.1 Sketching
11.1.2 Sketching Wiggle Charts

11.2 Braindrawing
11.3 Right-Braining
11.4 Helpful Hints and Variations
11.5 Summary

12. The Project's Name

12.1 Working Titles, Nicknames, and Official Names
12.2 The Influence of Names

12.2.1 A naming demonstration
12.2.2 What naming accomplishes

12.3 The Naming Heuristic
12.4 Helpful Hints and Variations
12.5 Summary

13. Facilitating in the Face of Conflict

13.1 Handling Inessential Conflicts

13.1.1 Wrong time, wrong project
13.1.2 Personality clashes
13.1.3 Indispensable people
13.1.4 Intergroup prejudice
13.1.5 Level differences

13.2 The Art of Being Fully Present
13.3 Handling Essential Conflicts

13.3.1 Reframing personality differences
13.3.2 Negotiating
13.3.3 Handling political conflicts

13.4 Helpful Hints and Variations
13.5 Summary

Part IV: Clarifying Expectations

14. Functions

14.1 Defining a function

14.1.1 Existence Function
14.1.2 Testing for a function

14.2 Capturing All and Only Functions

14.2.1 Capturing all potential functions
14.2.2 Understanding evident, hidden, and frill functions
14.2.3 Identifying overlooked functions
14.2.4 Avoiding implied solutions
14.2.5 The "Get It If You Can" List

14.3 Helpful Hints and Variations
14.4 Summary

15. Attributes

15.1 Attribute Wish List
15.2 Transforming the Wish List

15.2.1 Distinguishing between attributes and attribute details
15.2.2 Uncovering attribute ambiguity
15.2.3 Organizing the list
15.2.4 Discovering insights from the transformed list

15.3 Assigning Attributes to Functions

15.3.1 How attributes can modify functions
15.3.2 Gaining insights from the new function

15.4 Excluding Attributes

15.4.1 Categorizing into must, want, and ignore attributes
15.4.2 Implicit versus explicit elimination of attributes

15.5 Helpful Hints and Variations
15.6 Summary

16. Constraints

16.1 Defining Constraints
16.2 Thinking of Constraints as Boundaries
16.3 Testing the Constraints

16.3.1 Too strict?
16.3.2 Not strict enough?
16.3.3 Unclear?
16.3.4 Generating new ideas

16.4 Interrelated Constraints
16.5 Overconstraint
16.6 Psychology of Constraints

16.6.1 The tilt concept
16.6.2 Breaking constraints
16.6.3 The self-esteem bad-design cycle

16.7 Constraint Produces Freedom

16.7.1 Standards
16.7.2 Languages and other tools

16.8 Helpful Hints and Variations
16.9 Summary

17. Preferences

17.1 Defining a Preference

17.1.1 An example
17.1.2 The origin of preferences

17.2 Making Preferences Measurable

17.2.1 A reasonable approach to metrics
17.2.2 Making the preference measurable

17.3 Distinguishing Between Constraints and Preferences

17.3.1 Is meeting the schedule a constraint?

17.4 Constrained Preferences

17.4.1 What's-it-worth? graphs
17.4.2 When-do-you-need-it? graphs

17.5 Reframing Constraints into Preferences

17.5.1 Trading off among preferences
17.5.2 Zeroth Law of Product Development

17.6 Helpful Hints and Variations
17.7 Summary

18. Expectations

18.1 Reasons to Limit Expectations

18.1.1 People are not perfect
18.1.2 People are not logical
18.1.3 People perceive things differently
18.1.4 Designers are people, too

18.2 Applying the Expectation Limitation Process

18.2.1 Generate a specific expectation list
18.2.2 The elevator example
18.2.3 Generalize the expectation list
18.2.4 Limit the expectations

18.3 Limitations Need Not Be Limiting

18.3.1 The wheelchair example
18.3.2 Keeping possibilities open
18.3.3 Include the source of the limitation

18.4 Helpful Hints and Variations
18.5 Summary

Part V: Greatly Improving the Odds of Success

19. Ambiguity Metrics

19.1 Measuring Ambiguity

19.1.1 Using the ambiguity poll
19.1.2 Applying the polling method
19.1.3 Polling on different bases

19.2 Using the Metric as a Test

19.2.1 Measuring three kinds of ambiguity
19.2.2 Interpreting the results
19.2.3 Information from clustering
19.2.4 Choosing the group to be polled

19.3 Helpful Hints and Variations
19.4 Summary

20. Technical Reviews

20.1 A Walkover Example
20.2 The Role of Technical Reviews

20.2.1 Formal and informal reviews
20.2.2 Technical reviews versus project reviews

20.3 Review Reports

20.3.1 Need for review reports
20.3.2 Creating the issues list
20.3.3 Technical review summary report

20.4 Principal Types of Review

20.4.1 Vanilla reviews
20.4.2 Inspections
20.4.3 Walkthroughs
20.4.4 Round robin reviews

20.5 Real Versus Ideal Reviews
20.6 Helpful Hints and Variations
20.7 Summary

21. Measuring Satisfaction

21.1 Creating a User Satisfaction Test

21.1.1 Test attributes
21.1.2 A custom test for each project

21.2 Using the Test

21.2.1 Benefits
21.2.2 Plotting shifts and trends
21.2.3 Interpreting the comments
21.2.4 Feelings are facts

21.3 Other Uses of the Test

21.3.1 A communication vehicle
21.3.2 Continue use throughout the project
21.3.3 Use by designers

21.4 Other Tests

21.4.1 Prototypes as satisfaction tests

21.5 Helpful Hints and Variations
21.6 Summary

22. Test Cases

22.1 Black Box Testing

22.1.1 External versus internal knowledge
22.1.2 Constructing black box test cases
22.1.3 Testing the test cases

22.2 Applying the Test Cases

22.2.1 Examples
22.2.2 Iterating tests and answers
22.2.3 Clearly specifying ambiguity

22.3 Documenting the Test Cases
22.4 Helpful Hints and Variations
22.5 Summary

23. Studying Existing Products

23.1 Use of the Existing Product as the Norm
23.2 Interviewing

23.2.1 What's missing in the new product?
23.2.2 Why is it missing?
23.2.3 What's missing in the old product?
23.2.4 What's missing in the old requirements?

23.3 Substituting Features for Functions
23.4 Helpful Hints and Variations
23.5 Summary

24. Making Agreements

24.1 Where Decisions Come From

24.1.1 Choices, assumptions, and impositions
24.1.2 Elevator design decision examples
24.1.3 Writing traceable requirements

24.2 Where False Assumptions Come From

24.2.1 Lack of valid information
24.2.2 Invalidation over time
24.2.3 The turnpike effect
24.2.4 Requirements leakage

24.3 Converting Decisions to Agreements
24.4 Helpful Hints and Variations
24.5 Summary

25. Ending

25.1 The Fear of Ending
25.2 The Courage to End It All

25.2.1 Automatic Design and Development
25.2.2 Hacking
25.2.3 Freezing requirements
25.2.4 The renegotiation process
25.2.5 The fear of making assumptions explicit

25.3 The Courage to Be Inadequate
25.4 Helpful Hints and Variations
25.5 Summary


Return to Book Page

Table of Contents
Introduction to Part I, "Negotiating a Common Understanding"

Chapter 2, "Ambiguity in Stating Requirements"

Dorset House Catalog
This Book's Flyer

By this Author
Are Your Lights On?: How to Figure Out What the Problem Really Is
Quality Software Management, Vol. 4: Anticipating Change

Also Recommended

Complete Systems Analysis: The Workbook, the Textbook, the Answers, by James Robertson and Suzanne Robertson

General Principles of Systems Design, by Gerald M. Weinberg and Daniela Weinberg

The Practical Guide to Business Process Reengineering Using IDEF0, by Clarence G. Feldmann

Process for System Architecture and Requirements Engineering, by Hatley, Hruschka, and Pirbhai

To Satisfy & Delight Your Customer: How to Manage for Customer Value, by William J. Pardee

How to Order

To order this book by credit card directly from Dorset House in New York, please call (800) 342-6657 or (212) 620-4053, weekdays, 9am to 6pm. Alternatively, print out our Faxable Order Form and fax to (212) 727-1044.

To order this book from an online bookstore, please see above.

To purchase at a bookstore, contact our Recommended Booksellers to verify availability. Any store can order from Dorset House using the book's title and ISBN number. Also, bookstores can order our books through Baker & Taylor.

We'd like to make it easy for you to order, so please contact us at any time for help!

New: 3143 Broadway, Suite 2B    New York, New York 10027    USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044
Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal