Gerald M. Weinberg - Exploring Requirements 1 Quality before Design

Exploring Requirements 1:Quality Before Design

by

Donald C Gause and Gerald M. Weinberg

SMASHWORDS EDITION

PUBLISHED BY:

Gerald M. Weinberg on Smashwords

Exploring Requirements: Quality BeforeDesign

Copyright 2011 by Gerald M. Weinberg andDonald C. Gause, Sr.

Smashwords Edition License Notes

This ebook is licensed for your personalenjoyment only. This ebook may not be re-sold or given away toother people. If you would like to share this book with anotherperson, please purchase an additional copy for each person youshare 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 returnto Smashwords.com and purchase your own copy. Thank you forrespecting the author's work.

All rights reserved. Without limiting therights under copyright reserved above, no part of this publicationmay 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 theprior written permission of both the copyright owner and the abovepublisher of this book.

Contents

Chapter 10 Idea-GenerationMeetings

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

Development is the process of transformingsomeone's desires into a product that satisfies those desires. Thisbook is about the requirements processthe part of development inwhich people attempt to discover what is desired.

To understand this process, the reader shouldfocus on five critical words: desire, product, people, attempt, anddiscover.

First, consider the word "desire." Somereaders would prefer that we say "attempt to discover what isneeded," but we don't know how to figure out what people need, asopposed to what they desire. Besides, people don't always buy whatthey need, but they always desire what they buy, even if the desireis only transitory. By clarifying their desires, people sometimesclarify what they really need and don't need.

By "product," we mean any product attemptingto satisfy a complex set of desires. For one thing, the desires arecomplex because they come from many people. When we create aproduct to satisfy our own desiresas whenwe build a garden, for example, or a bookcasewe don't often needan explicit requirements process. We simply build something, lookat it, and make adjustments until we're satisfied.

But "people" might include many differentpeople, and discovering who "people" are is a major part of therequirements process. When many people are involvedand when theproduct is largethe kind of try-and-correct iterative process usedto discover personal requirements may simply prove too drawn out,too costly, and too risky.

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

Before working with us, many of our clientshoped product development was an exact discipline. Many of thoseclients were in the software businessa business that has beenplagued by ill-founded fantasies of an exact discipline fordeveloping products. We like to quote John von Neumann because manyof our clients consider him to be the founding father of software.They pay attention when he says, "There's no sense being exactabout something if you don't even know what you 're talkingabout."

If people don't know what they want, nodevelopment processno matter how exact, how clever, or howefficientwill satisfy them. And that's why we do requirementsworkso 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 routeto efficiency in development is to eliminate those products nobodywanted in the first place. Another way to put this is,

Anything not worth doing isnot worth doing right.

Which brings us to "discover," the mostcritical word. In this book, we're trying to help people discoverwhats really worth doing.

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

The product is nothing; the process iseverything.

Or, put another way,

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

Hence the title, Exploring Requirements.

A data dictionary, for example, is a way ofpreserving the definitions painstakingly derived with the aid ofsome of the methods in this book. In practice, however, hardlyanybody reads the data dictionary. Indeed, few people will read any of the documents developed in therequirements process. This observation bothers some people, but notus because we believe that

The document is nothing; the documenting iseverything.

If you watch how people really developsystems, you'll see the process of developing requirements isactually 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 notmet, the project will probably fail. Of course, there are manyother reasons why a product development project might fail, andthere are many books about methods to avoid such pitfalls. Thisbook, however, will concentrate on these three critical butneglected human aspects of the requirements process:

1. developing a consistent understanding ofrequirements among all participants

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

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

Because these topics are somewhat neglectedin the systems development literature, ExploringRequirements can be used as a supplement to any requirementsprocess you now use, formal or informal. Most of the chapters aredesigned as standalone modules, each presenting one or more toolsor methods to enhance your requirements process. You can read thebook from beginning to end, or read only the one chapter mostneeded at any given moment. Either way, it should help you do abetter job of knowing what you're talking about.

The original paper book version of ExploringRequirements has been divided into two ebook volumes for theconvenience of our readers:

Volume 1: Quality Before Design [getting theright requirements]

Volume 2: First Steps into Design [gettingthe requirements right]

Why did we divide the book where we did? Fundamentally, it's hard to tell whenrequirements stop and design begins, partly because requirementswork never stopseven after the product is "finished." These "firststeps into design" may be the tidying up of requirements or theymay be the beginning of design. Who knows? Those categories wereinvented by some human beings, and they can be modified or evendiscarded by other human beings. We prefer to think of"requirements," "design," "building," and "testing" as tasks to beaccomplished, not "phases" to proceed one after the other.