Exploring Requirements 2: First Steps into Design

By Gerald M. Weinberg

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

• Language: English
• Publisher: Gerald M. Weinberg
• Release date: Jul 16, 2011
• ISBN: 9781466067806

Gerald M. Weinberg

Gerald M. Weinberg (Jerry) writes "nerd novels," such as The Aremac Project, Aremac Power, First Stringers, Second Stringers, The Hands of God, Freshman Murders, and Mistress of Molecules—about how brilliant people produce quality work. His novels may be found as eBooks at or on Kindle. Before taking up his science fiction career, he 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. He also wrote books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the four-volume Quality Software Management series. He incorporates his knowledge of science, engineering, and human behavior into all of writing and consulting work (with writers, hi-tech researchers, and software engineers). Early in his career, he was the architect for the Mercury Project's space tracking network and designer of the world's first multiprogrammed operating system. Winner of the Warnier Prize and the Stevens Award for his writing on software quality, he is also a charter member of the Computing Hall of Fame in San Diego and the University of Nebraska Hall of Fame. The book, The Gift of Time (Fiona Charles, ed.) honors his work for his 75th birthday. His website and blogs may be found at http://www.geraldmweinberg.com.

Book preview

Exploring Requirements 2: First Steps to Design

by

Donald C Gause Gerald M. Weinberg

SMASHWORDS EDITION

PUBLISHED BY:

Weinberg & Weinberg on Smashwords

Exploring Requirements 2: First Steps to Design

Copyright © 2011 by Gerald M. Weinberg and Donald C. Gause, Sr.

Smashwords Edition License Notes

This ebook is licensed for your personal enjoyment only. This ebook may not be resold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you're reading this book and did not purchase it, or it was not purchased for your use only, then you should return to Smashwords.com and purchase your own copy. Thank you for respecting the author's work.

All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.

Contents

Part IV Clarifying Expectations

Chapter 14 Functions

Chapter 15 Attributes

Chapter 16 Constraints

Chapter 17 Preferences

Chapter 18 Expectations

Part V Greatly Improving the Odds of Success

Chapter 19 Ambiguity Metrics

Chapter 20 Technical Reviews

Chapter 21 Measuring Satisfaction

Chapter 22 Test Cases

Chapter 23 Studying Existing Products

Chapter 24. Making Agreements

Chapter 25. Ending

Bibliography

Further Reading

Dedication

Acknowledgments

Preface

There's no sense being exact about something if you don't even know what you're talking about. —John von Neumann

Development is the process of transforming someone's desires into a product that satisfies those desires. This book is about the requirements process—the part of development in which people attempt to discover what is desired.

To understand this process, the reader should focus on five critical words: desire, product, people, attempt, and discover.

First, consider the word desire. Some readers would prefer that we say attempt to discover what is needed, but we don't know how to figure out what people need, as opposed to what they desire. Besides, people don't always buy what they need, but they always desire what they buy, even if the desire is only transitory. By clarifying their desires, people sometimes clarify what they really need and don't need.

By product, we mean any product attempting to satisfy a complex set of desires. For one thing, the desires are complex because they come from many people. When we create a product to satisfy our own desires—as when we build a garden, for example, or a bookcase—we don't often need an explicit requirements process. We simply build something, look at it, and make adjustments until we're satisfied.

But people might include many different people, and discovering who people are is a major part of the requirements process. When many people are involved—and when the product is large—the kind of try-and-correct iterative process used to discover personal requirements may simply prove too drawn out, too costly, and too risky.

What about attempt? If we're writing a book, shouldn't we be more certain, more positive? Shouldn't we guarantee results? Well, we've used the requirements techniques in this book to help our clients develop all types of products—computer hardware, computer software, automobiles, furniture, buildings, innovative consumer products, books, films, organizations, training courses, and research plans. Nobody yet has demanded money back, but we can't prove no client ever will, because we do not know how to make product development into an exact discipline.

Before working with us, many of our clients hoped product development was an exact discipline. Many of those clients were in the software business—a business that has been plagued by ill-founded fantasies of an exact discipline for developing products. We like to quote John von Neumann because many of our clients consider him to be the founding father of software. They pay attention when he says, There's no sense being exact about something if you don't even know what you 're talking about.

If people don't know what they want, no development process—no matter how exact, how clever, or how efficient—will satisfy them. And that's why we do requirements work—so we don't design systems people don't want.

Effectiveness always comes before efficiency. But even if efficiency is your hot button, the most important route to efficiency in development is to eliminate those products nobody wanted in the first place. Another way to put this is,

Anything not worth doing is not worth doing right.

Which brings us to discover, the most critical word. In this book, we're trying to help people discover whats really worth doing.

Dwight Eisenhower once said, 'The plan is nothing; the planning is everything." We agree, and we also extend the same thinking to the requirements process:

The product is nothing; the process is everything.

Or, put another way,

The discovery is nothing; the discovering (the exploring) is everything.

Hence the title, Exploring Requirements.

A data dictionary, for example, is a way of preserving the definitions painstakingly derived with the aid of some of the methods in this book. In practice, however, hardly anybody reads the data dictionary. Indeed, few people will read any of the documents developed in the requirements process. This observation bothers some people, but not us because we believe that

The document is nothing; the documenting is everything.

If you watch how people really develop systems, you'll see the process of developing requirements is actually a process of developing a team of people who

• understand the requirements

• (mostly) stay together to work on the project

• know how to work effectively as a team

We believe if one of these conditions is not met, the project will probably fail. Of course, there are many other reasons why a product development project might fail, and there are many books about methods to avoid such pitfalls. This book, however, will concentrate on these three critical but neglected human aspects of the requirements process:

1. developing a consistent understanding of requirements among all participants

2. developing the desire to work as a team on the project

3. developing the necessary skills and tools for working effectively as a team to define requirements

Because these topics are somewhat neglected in the systems development literature, Exploring Requirements can be used as a supplement to any requirements process you now use, formal or informal. Most of the chapters are designed as standalone modules, each presenting one or more tools or methods to enhance your requirements process. You can read the book from beginning to end, or read only the one chapter most needed at any given moment. Either way, it should help you do a better job of knowing what you're talking about.

Preface to the Ebook Version

The original paper book version of Exploring Requirements has been divided into two ebook volumes for the convenience of our readers:

Volume 1: Quality Before Design [getting the right requirements]

Volume 2: First Steps into Design [getting the requirements right]

Why did we divide the book where we did? Fundamentally, it's hard to tell when requirements stop and design begins, partly because requirements work never stops–even after the product is finished. These first steps into design may be the tidying up of requirements or they may be the beginning of design. Who knows? Those categories were invented by some human beings, and they can be modified or even discarded by other human beings. We prefer to think of requirements, design, building, and testing as tasks to be accomplished, not phases to proceed one after the other.

Part IV Clarifying Expectations

Some time has passed since the first meeting on the Superchalk Project. Barbara, Larry, and Todd, the design team from BU Design, are back in the chalk cave with Byron, Wilma, and John. The BLT designers now know that Byron, President of Cheap Chalk Corporation (CCC), is their customer, and John and Wilma are representatives of two different user populations. They understand how much Byron is willing to spend, and the reason this project has been initiated: CCC has discovered a new vein of super-pure white chalk, which they wish to market in a new, distinctive form.

Larry: As you know, Byron, BLT Design is the world leader in the design of writing instruments.

Byron: That's why we hired you to design Superchalk.

Larry: Of course. At this stage in the requirements process, we need to find out exactly what you expect Superchalk to be like. Now, over our many years of designing writing instruments, BLT has developed a standard list of attributes every writing instrument should have.

(Larry unrolls a sheet of flipchart paper, tapes it to the chalkboard, and takes out a felt-tip marker pen. Byron winces but doesn't say anything.)

Larry: Here's our list. A writing instrument should be user-friendly, profitable, manufacturable, easy to sell, innovative, unique, strong, reliable, safe, nontoxic, nonallergenic, clean, easy to package, versatile, appropriately erasable, and should produce easy-to-read writing. Don't you agree?

Byron: Hmmm.

Barbara: Good. And Wilma, what do you think?

Wilma: Sounds wonderful.

John: I can't see anything to add.

Barbara: Good, then we all agree on the attributes.

Todd: I can't wait to get started on the design!

Chapter 14 Functions

The BLT team may be ready to start designing a product, but they're going to be in a heap of trouble if they don't have a clearer idea of precisely what CCC wants from Superchalk. They can proceed to get this information in an orderly way by moving from functions, to attributes, to constraints, to preferences, to expectations, as we'll do on several projects in the next five chapters.

14.1 Defining a Function

Frequently, the first step in this orderly process of gaining information is to define functions. Functions are the what of a product, describing what the product is to accomplish. They are verbs, representing actions for which the product is the subject.

14.1.1 Existence function

The first function of any system is to exist, which at this early stage is not a certainty, but only an assumption

This assumption is at the root of the decision tree. For example, the client says:

• We want Superchalk to exist.

• We want the Elevator Information Device to exist.

The development of the problem statement starts with this existence function and proceeds by defining what the product must do to exist for the client. For example, Superchalk will exist when it writes on slate and satisfies our customers. Writes on slate and satisfies our customers are both desired functions of Superchalk, deriving from the function exists.

14.1.2 Testing for a function

To test whether a requirement is actually a function, put the phrase We want the product to... in front of it. Alternatively, you can say, The product should... For example, rephrase the previous statements as,

• Superchalk should write on slate.

• Superchalk should satisfy our customers.

To take another example, display current floor is a function because we can sensibly say:

The Elevator Information Device should display the current floor.

Purple is not a function, because we cannot sensibly say,

The Elevator Information Device should purple.

To make sense, the sentence would have to read,

The Elevator Information Device should be purple.

The EID should become purple when an entry error is made.

Thus, purple is not a function; it is an attribute of the system or of some function of the system, as we shall see in Chapter 15.

14.2 Capturing All and Only Functions

Since there are many books on requirements doing a good job of teaching us how to describe functions clearly and accurately, our task here is to concentrate on methods that

1. capture all the functions the client wants

2. understand those functions

3. don't capture functions the client doesn't want

14.2.1 Capturing all potential functions

The first step in the process is to help the client brainstorm all conceivable functions to be performed by the system. The designer should not contribute ideas at this stage, but simply facilitate the client's imagination in dreaming up wishes. Several questions may be used to prime the brainstorming process:

1. How would you (the client) like to use this product?

2. What is the purpose of this product?

3. How would others like to use this product? (Refer the client to the user list.)

4. Pretend you're not concerned about how much it would cost. What would you like?

5. Don't worry if it can really be done. What would you like?

Using such a brainstorm, the client dreamed up the following functions for the Elevator Information Device:

1. display current floor

2. display the selected floor stops ahead

3. display relevant outside weather conditions

4. provide local 24-hour weather forecast

5. give the floor selection of passengers

6. perform a security check for secured floors

7. de-select for inadvertent selections

8. furnish a priority override for emergencies