Exploring Requirements 2: First Steps into Design
()
About this ebook
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
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.
Read more from Gerald M. Weinberg
The Stringers Teaching People Teaching Dogs Rating: 0 out of 5 stars0 ratingsLove Poems After Fifty Years Rating: 0 out of 5 stars0 ratings
Related to Exploring Requirements 2
Titles in the series (8)
Perfect Software and Other Illusions About Testing Rating: 5 out of 5 stars5/5Becoming a Technical Leader Rating: 4 out of 5 stars4/5The Psychology of Computer Programming: Silver Anniversary eBook Edition Rating: 4 out of 5 stars4/5Roundtable on Project Management Rating: 0 out of 5 stars0 ratingsUnderstanding the Professional Programmer Rating: 4 out of 5 stars4/5Exploring Requirements 2: First Steps into Design Rating: 0 out of 5 stars0 ratingsExploring Requirements 1: Quality Before Design Rating: 0 out of 5 stars0 ratingsRoundtable on Technical Leadership Rating: 1 out of 5 stars1/5
Related ebooks
Exploring Requirements 1: Quality Before Design Rating: 0 out of 5 stars0 ratingsPerfect Software and Other Illusions About Testing Rating: 5 out of 5 stars5/5Managing Yourself and Others Rating: 0 out of 5 stars0 ratingsThe Fragile Methodology Rating: 0 out of 5 stars0 ratingsThe Rock Crusher: A Model for Flow-Based Backlog Management Rating: 0 out of 5 stars0 ratingsOutcomes over Output: Why Customer Behavior Is the Key Metric for Business Success Rating: 4 out of 5 stars4/5Hypothesis-Driven Development Rating: 0 out of 5 stars0 ratingsLoops: Building Products with Clarity & Confidence Rating: 0 out of 5 stars0 ratingsWho Does What By How Much Rating: 0 out of 5 stars0 ratingsProduct Management for UX People: From Designing to Thriving in a Product World Rating: 5 out of 5 stars5/5Understanding the Professional Programmer Rating: 4 out of 5 stars4/5The Design of Insight: How to Solve Any Business Problem Rating: 0 out of 5 stars0 ratingsAgile Advice - Creating High Performance Teams In Business Organizations Rating: 0 out of 5 stars0 ratingsHow To Be An Agile Business Analyst Rating: 0 out of 5 stars0 ratingsQuality Software: Volume 1.1: How Software Is Built Rating: 0 out of 5 stars0 ratingsSpecification by Example: How Successful Teams Deliver the Right Software Rating: 0 out of 5 stars0 ratingsRethinking Systems Analysis and Design Rating: 5 out of 5 stars5/5Are Your Lights On? Rating: 4 out of 5 stars4/5Change Done Well Rating: 0 out of 5 stars0 ratingsHow to Observe Software Systems Rating: 0 out of 5 stars0 ratingsWhy Software Gets In Trouble Rating: 0 out of 5 stars0 ratingsCHANGE: Planned & Unplanned Rating: 0 out of 5 stars0 ratingsActive Regulation: General Systems Design Principles Rating: 5 out of 5 stars5/5Software Requirements and Design: The Work of Michael Jackson Rating: 0 out of 5 stars0 ratingsSurveying Fundamentals for Business Analysts Rating: 0 out of 5 stars0 ratingsDigital Master: Debunk the Myths of Enterprise Digital Maturity Rating: 0 out of 5 stars0 ratingsEveryday Information Architecture Rating: 0 out of 5 stars0 ratingsRoundtable on Technical Leadership Rating: 1 out of 5 stars1/5An Introduction to General Systems Thinking Rating: 5 out of 5 stars5/5
Careers For You
The Everything Guide To Being A Paralegal: Winning Secrets to a Successful Career! Rating: 5 out of 5 stars5/5How to Write a Grant: Become a Grant Writing Unicorn Rating: 5 out of 5 stars5/5The 12 Week Year: Get More Done in 12 Weeks than Others Do in 12 Months Rating: 4 out of 5 stars4/5Real Artists Don't Starve: Timeless Strategies for Thriving in the New Creative Age Rating: 4 out of 5 stars4/5The Confidence Code: The Science and Art of Self-Assurance---What Women Should Know Rating: 4 out of 5 stars4/5The Pathless Path Rating: 5 out of 5 stars5/5The Ultimate Side Hustle Book: 450 Moneymaking Ideas for the Gig Economy Rating: 4 out of 5 stars4/5The Growth Mindset: The Art of Growth, #1 Rating: 5 out of 5 stars5/5Ultralearning: Master Hard Skills, Outsmart the Competition, and Accelerate Your Career Rating: 4 out of 5 stars4/5From 150 to 179 on the LSAT Rating: 4 out of 5 stars4/5Working for Yourself: Law & Taxes for Independent Contractors, Freelancers & Gig Workers of All Types Rating: 5 out of 5 stars5/5Wise as Fu*k: Simple Truths to Guide You Through the Sh*tstorms of Life Rating: 5 out of 5 stars5/5Peak: Secrets from the New Science of Expertise Rating: 4 out of 5 stars4/5Audition: Everything an Actor Needs to Know to Get the Part Rating: 4 out of 5 stars4/5The 4-Hour Workweek (Review and Analysis of Ferriss' Book) Rating: 4 out of 5 stars4/5Quitting: Why I Left My Job to Live a Life of Freedom Rating: 4 out of 5 stars4/5Buy Then Build: How Acquisition Entrepreneurs Outsmart the Startup Game Rating: 4 out of 5 stars4/5The Hard Truth About Soft Skills: Soft Skills for Succeeding in a Hard Wor Rating: 3 out of 5 stars3/5Mean Girls at Work: How to Stay Professional When Things Get Personal Rating: 3 out of 5 stars3/5The Art of Work: A Proven Path to Discovering What You Were Meant to Do Rating: 4 out of 5 stars4/5You Can't Lie to Me: The Revolutionary Program to Supercharge Your Inner Lie Detector and Get to the Truth Rating: 4 out of 5 stars4/5Own Your Greatness: Overcome Impostor Syndrome, Beat Self-Doubt, and Succeed in Life Rating: 4 out of 5 stars4/5The Everything Career Tests Book: 10 Tests to Determine the Right Occupation for You Rating: 0 out of 5 stars0 ratingsIntroduction to Conducting Private Investigations: Private Investigator Entry Level (02E) Rating: 5 out of 5 stars5/5Creative, Inc.: The Ultimate Guide to Running a Successful Freelance Business Rating: 4 out of 5 stars4/5The Start Your Own Business Bible: 501 New Ventures You Can Launch Today Rating: 4 out of 5 stars4/5Setting the Table: The Transforming Power of Hospitality in Business Rating: 5 out of 5 stars5/5The Professional Voiceover Handbook: Voiceover training, #1 Rating: 5 out of 5 stars5/5How to Be Everything: A Guide for Those Who (Still) Don't Know What They Want to Be When They Grow Up Rating: 4 out of 5 stars4/5
Reviews for Exploring Requirements 2
0 ratings0 reviews
Book preview
Exploring Requirements 2 - Gerald M. Weinberg
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