Exploring Requirements Two
Minimum price
Suggested price

Exploring Requirements Two

First Steps to Design

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

  • Share this book

  • Categories

    • Agile
    • Software
    • Project Management
    • Testing
    • Design
  • Feedback

    Email the Author(s)

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.

Bundles that include this book

Bought separately
Bundle Price
Bought separately
Bundle Price

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

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

80% Royalties. Earn $16 on a $20 book.

We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

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. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub