Exploring Requirements Two
Exploring Requirements Two
$9.99
Minimum price
$9.99
Suggested price
Exploring Requirements Two

Last updated on 2014-11-02

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

"Consciousness raising for systems analysts." —Tom Demarco, Atlantic Systems Guild

". . . a superb new book on systems analysis. . . . you simply must read and absorb this gem. It complements every brand-name systems analysis methodology currently being practiced." —Ed Yourdon, American Programmer

". . . provides an excellent set of principles amply illustrated by relevant and thought-provoking examples."—Barry Boehm, UCLA

"The title lays it out, that exploring requirements does imply quality before design, and the text provides the social, psychological, and intellectual processes to carry it out. Gause and Weinberg are unique in their experiences and abilities in the subject."— Harlan D. Mills, Florida Institute of Technology

Table of Contents

  • Exploring Requirements Two: First Steps to Design
  • Preface
  • Preface to the Ebook Version
  • Part IV Clarifying Expectations
  • Chapter 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
  • Chapter 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 format
    • 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
  • Chapter 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.4 Generating new ideas
    • 16.4 Interrelated Constraints
    • 16.5 Overconstraint
    • 16.6 The 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
  • Chapter 17. Preferences
    • 17.1 Defining a Preference
      • 17.1.1 An example of preferences
      • 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
  • Chapter 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
  • Chapter 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
  • Chapter 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 The 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
  • Chapter 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 Continued use throughout the project
    • 21.4 Other Tests
      • 21.4.1 Prototypes as satisfaction tests
    • 21.5 Helpful Hints and Variations
    • 21.6 Summary
  • Chapter 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
  • Chapter 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
  • Chapter 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
  • Chapter 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
  • Chapter of References
  • Bibliography
  • Further Reading
  • Acknowledgments

Bundles that include this book

Are Your Lights On?
What Did You Say?  The Art of Giving and Receiving Feedback
Exploring Requirements One
Exploring Requirements Two
Becoming a Change Artist
7 Books
$66.93
Suggested Price
$49.99
Bundle Price
Exploring Requirements One
Exploring Requirements Two
2 Books
$19.98
Suggested Price
$14.99
Bundle Price

About the Author

Gerald M. Weinberg
Gerald M. Weinberg

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...

Write and Publish on Leanpub

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub