Exploring Requirements One
Last updated on 2014-10-29
About the Book
John von Neumann once said, "There's no sense being exact about something if you don't even know what you're talking about." In a world that is growing increasingly dependent on highly complex, computer-based systems, the importance of defining what you want to make before making it—that is, knowing what you're talking about—cannot be stressed enough.
Here's an innovative book that gives you the understanding you need to give people the solutions they want. The collaborative team of Gause and Weinberg tells how you can assure the requirements are right—before the product is designed.
Written by two recognized authorities in the field, this book is a collection of ideas developed, refined, and tested during their more than sixty combined years of work with both large and small organizations.
The techniques formulated in Exploring Requirements are not confined to software development; they have been used effectively to develop a wide range of products and systems—from computer software to furniture, books, and buildings.
Systems analysts and anyone involved with the challenges of the requirements process will greatly benefit from this book.
Renowned leaders in the software industry have this to say about Exploring Requirements:
"Anyone who wants to build a product should understand this book."—Watts S. Humphrey, SEI
Table of Contents
- Exploring Requirements 1: Quality Before Design
- Preface
- Preface to the Ebook Version
- Part I Negotiating a Common Understanding
-
Chapter 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 Everyone Can Read the Map
- 1.5. Maps of Requirements Are Not Requirements
- 1.6. Helpful Hints and Variations
- 1.7 Summary
-
Chapter 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
-
2.1 Examples of Ambiguity
-
Chapter 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
-
Chapter 4. The Tried but Untrue Use of Direct Questions
-
4.1 Decision Trees
- 4.1.1Order 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
-
4.1 Decision Trees
- Part II Ways to Get Started
-
Chapter 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.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
-
Chapter 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
-
Chapter 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 obtain their judgments?
- 7.4 Plan for Capturing Users
- 7.5 Helpful Hints and Variations
- 7.6 Summary
-
7.1 Identifying the Right People
-
Chapter 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
-
8.1 Meetings: Tools We Can’t Live With, or Without
-
Chapter 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
-
Chapter 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
-
Chapter 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
-
11.1 Mapping Tools
-
Chapter 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
-
Chapter 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
-
13.1 Handling Inessential Conflicts
- Chapter of References
- Bibliography
- Further Reading
- Acknowledgments
Bundles that include this book
About the Author
I've always been interested in helping smart people be happy and productive. To that end, I've published books on human behavior, including Weinberg on Writing: The Fieldstone Method, The Psychology of Computer Programming, Perfect Software and Other Fallacies, and an Introduction to General Systems Thinking. I've also written books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the nine-volume Quality Software series.
I try to incorporate my knowledge of science, engineering, and human behavior into all of my writing and consulting work (with writers, hi-tech researchers, software engineers, and people whose life-situation could require the use of a service dog). I write novels about such people, including The Aremac Project, Aremac Power, Jigglers, First Stringers, Second Stringers, The Hands of God, Freshman Murders, Where There's a Will There's a Murder, Earth's Endless Effort, and Mistress of Molecules—all about how my brilliant protagonists produce quality work and learn to be happy. My books that are not yet on Leanpub may be found as eBooks at <http://www.smashwords.com/profile/view/JerryWeinberg>; on Amazon at http://www.amazon.com/-/e/B000AP8TZ8; and at Barnes and Noble bookstore: http://tinyurl.com/4eudqk5.
Early in my career, I was the architect for the Project Mercury's space tracking network and designer of the world's first multiprogrammed operating system. I won the Warnier Prize, the Stevens Award, and the first Software Testing Professionals' Luminary Award, all for my writing on software quality. I was also elected a charter member of the Computing Hall of Fame in San Diego and chosen for the University of Nebraska Hall of Fame.
But the "award" I'm most proud of is the book, The Gift of Time (Fiona Charles, ed.) written by my student and readers for my 75th birthday. Their stories make me feel that I've been at least partially successful at helping smart people be happy.
Other books by this author
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
