Mastering the Requirements Process [NOOK Book]

Overview

"If the purpose is to create one of the best books on requirements yet written, the authors have succeeded."

—Capers Jones

It is widely recognized that incorrect requirements account for up to 60 percent of errors in software products, and yet the majority of software development organizations do not have a formal requirements process. Many organizations appear willing to spend huge amounts on fixing and altering poorly specified software, but seem unwilling to invest a much ...

See more details below
Mastering the Requirements Process

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac

Want a NOOK? Explore Now

NOOK Book (eBook)
$34.49
BN.com price
(Save 42%)$59.99 List Price

Overview

"If the purpose is to create one of the best books on requirements yet written, the authors have succeeded."

—Capers Jones

It is widely recognized that incorrect requirements account for up to 60 percent of errors in software products, and yet the majority of software development organizations do not have a formal requirements process. Many organizations appear willing to spend huge amounts on fixing and altering poorly specified software, but seem unwilling to invest a much smaller amount to get the requirements right in the first place.

Mastering the Requirements Process, Second Edition , sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile development environments. In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility.

Features include

  • The Volere requirements process—completely specified, and revised for compatibility with agile environments
  • A specification template that can be used as the basis for your own requirements specifications
  • New agility ratings that help you funnel your efforts into only the requirements work needed for your particular development environment and project
  • How to make requirements testable using fit criteria
  • Iterative requirements gathering leading to faster delivery to the client
  • Checklists to help identify stakeholders, users, nonfunctional requirements, and more
  • Details on gathering and implementing requirements for iterative releases
  • An expanded project sociology section for help with identifying and communicating with stakeholders
  • Strategies for exploiting use cases to determine the best product to build
  • Methods for reusing requirements and requirements patterns
  • Examples showing how the techniques and templates are applied in real-world situations


Read More Show Less

Editorial Reviews

Robert L. Glass
Requirements are a make or break phase of the software development process. If the requirements are carefully chosen to represent what the customer wants, needs, and expects, then the project has a good chance of success. If not, the project may very well be doomed.

That said, it is easy to say that this book is about an important topic.
But is it a good book about that important topic?

My vote is "yes." This is a nicely crafted, well-thought-through, complete, up-to-date view of the task of creating a requirements specification for a software project.

Nicely crafted? It is well written, readable, never pedantic. Well-thought-through? The authors base the book on seminars they have given and honed over the years. Complete and up-to-date? Not only are the basic topics covered, but the authors also mention such advanced topics as requirements reuse, requirements patterns, traceability, and an event + use case-driven approach.

The book is written for the requirements novice. There are plenty of detail-level discussions of steps and approaches, templates for framing the results, and an elaborated case study (how refreshing it is to see a case study based on de-icing roadways, rather than one of the traditional, overused topics like video rental or cruise control!) But the book can also be useful to the patient requirements expert - there is more verbiage than the expert will want, but by scanning carefully the essence of the book can be easily distilled out. Importantly, the essence of the book is conceptual rather than formula/methodology-driven - the authors say the book is intended "not as a set of canonical rules that must be obeyed, but as a reliable companion to intelligent work."

Given all of that, I found some things that were mildly annoying: Some of the terminology the authors use is cutesy, although often it is appropriate, but (a) "blastoff: as the term for project start? (The projects I've been involved with rarely start with a "blast"!); (b) "requirements leakage" for requirements that erroneously get accepted into a project? (I would have thought that things leak out of a project, not in!) The authors claim that their book can be used not just for customized software development projects, but also for software maintenance and even for projects that aggregate pre-built packages. But later they say that the requirements process should never consider the technology of the solution (all well and good for customization, but impossible for the latter two categories). The authors take the (debatable) position that "object-orientation has become the standard way of developing systems," but then mix the two terms "use cases" and "event-driven" as if they were the same, both related to the OO approaches. In my view, event-driven approaches are rather different from object-oriented ones (for example, Visual Basic allows the programmer to build an event-driven system, but the result may or may not (likely not!) be object-oriented). The authors speak of a "post-mortem review" (an excellent idea), but it is not until page 271 (near the end of the book) that it becomes clear that "post-mortem" means "after the requirements phase," not "after the project is complete." (Either could be correct, but the authors should make it clear which they mean when they first bring up the topic 250 pages earlier). There is an appropriate and thorough discussion of the topic of "fit," by which the authors mean that requirements should be expressed in a measurable way. But the authors fail to acknowledge that some things simply don't lend themselves to measurement, with the result that much mischief is done by those who attempt to measure the unmeasurable (e.g., the terrible tendency to state "the software product shall be modular" in terms of the length of program segments - "modules shall contain no more than 50 lines of code").

Things I particularly like about the book are Requirements representation is treated as a pragmatic topic, where requirements are to be readable by both application customers and software designers. There is none of the formal specification discussion that computer scientists love to advocate but that seldom fits the needs of real-world requirements. There is also a nice discussion of software tools, appropriately mentioning that they are a means to an end, not an end in themselves. (Interestingly, there is no mention of the now-in-disrepute term "CASE"!) The discussion of the "quality gateway," which covers the process of making a final decision as to which requirements to include in the final specification, is both important and nice. There are very well-done discussions of such topics as "requirements creep," "gold plating," "traceability," and "viability." (I was reminded of the wry comment by Jerry Weinberg at a conference many years ago that software may be the only discipline where the answer to the early-project question of feasibility is always "yes"!) The discussions of the avant-garde requirements topics like requirements reuse and requirements patterns are very nice. I was less pleased with the discussion of traceability - what the book contains is excellent material, but it fails to go far enough to note that tracing requirements into design and code, although extremely desirable, is so far an out-of-reach topic (due to the "explosion" of business requirements into design requirements as the life cycle proceeds, an explosion estimated by some to be measured in orders of magnitude).

There should be at least one book on requirements in the library of every enterprise, even every software professional. You could do a lot worse than choosing this one.

Booknews
She specializes in systems analysis and requirements modeling and specifications; he advises companies on requirements. They set out an industry-tested and adaptable template for gathering and verifying requirements for software products, errors in which they estimate account for up to 60% of the failures. The provide techniques and insights for discovering precisely what the customer wants and needs. Annotation c. Book News, Inc., Portland, OR booknews.com
Read More Show Less

Product Details

  • ISBN-13: 9780132565431
  • Publisher: Pearson Education
  • Publication date: 3/31/2006
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 2
  • Pages: 592
  • File size: 5 MB

Meet the Author

Suzanne Robertson and James Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development. Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005).

James Robertson and Suzanne Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development. Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005).



Read More Show Less

Read an Excerpt

In the six years since we published the first edition of this book, the world's knowledge of requirements has grown, and more people have a job called "business analyst," "requirements engineer," or something similar. The Volere Requirements Specification Template has been downloaded countless times. The Volere Requirements Process is in use by thousands of people who are engaged in the activity of successful requirements gathering. They, in turn, have given us feedback over the years about what they needed to know, and what they are doing when gathering requirements.

This book is a reflection of the feedback we have received, and of the way people have made use of the first edition.

The requirements activity has moved away from wanting to be seen as an engineering discipline, to the realization that it is a sociotechnical activity. Requirements analysts now see their role first as one of communication, and second as a technician adding rigor and precision to the results of the human communication.

As a result, we have updated and expanded the project sociology analysis section of the book. In a similar vein, we have added the appropriate rigor to the technicalities of recording and measuring the requirements.

Perhaps the greatest change to come along since the first edition has been the arrival of agile methods, accompanied by some wonderful technological advances. Agile methods have influenced the way people develop software, with the result being that greater emphasis is placed on close customer relationships, and less emphasis is placed on documentation. We heartily applaud this advance. However, we have also seen too many people, who, in the name of agility, rush to a solution without first understanding the real business problem to be solved.

This, then, is the role of requirements in the agile world: to ensure that we hear not only one customer's voice, but also the voices of the other stakeholders—those with some value to add to the requirements for the product. Agile requirements analysts ensure that the work is considered, not just the product, and that the nonfunctional requirements are studied, not left to the whim of the programmer.

Agile methods have brought with them a healthy disdain for documentation. We agree with this view. Throughout this second edition we urge you to consider the benefit before committing anything to writing. But while we suggest sometimes you can develop software successfully without formally written requirements, we never suggest you can do it without understanding the requirements.

The emphasis on iterative development means that the requirements "phase" is no longer completed before building begins. The drive toward short, sharp release cycles means requirements analysts get feedback on their requirements efforts more quickly. Stakeholders receive positive reinforcement when they see the time they invest in requirements paid back with progressive versions of working software that does what they expect, and what they need.

Technological advances have changed requirements gathering. Blogs and wikis mean that requirements analysts can gather their requirements informally and iteratively using the convenience of networking with their stakeholders. Desktop videoconferencing and instant messaging mean closer, quicker communication with stakeholders, which is, of course, necessary for good requirements gathering.

The gap between what we wrote in 1999 and what we found ourselves doing when gathering requirements gradually grew wider, until we knew it was time to update our book. The volume that you hold in your hands is the result of the last few years of our work and teaching. We trust you find it interesting, enlightening, and useful.

Read More Show Less

Table of Contents

Preface to the Second Edition xxi

Foreword to the First Edition xxiii

Acknowledgments xxiv

Chapter 1 What Are Requirements? 1

Requirements Gathering and Systems Modeling 3

Agile Software Development 4

Why Do I Need Requirements? 8

What Is a Requirement? 9

Evolution of Requirements 11

The Template 11

The Shell 14

The Volere Requirements Process 15

Chapter 2 The Requirements Process 17

Agility Guide 19

Requirements Process in Context 20

The Process 21

A Case Study 21

Trawling for Requirements 24

Prototyping the Requirements 25

Scenarios 25

Writing the Requirements 26

The Quality Gateway 28

Reusing Requirements 29

Reviewing the Specification 29

Iterative and Incremental Processes 30

Requirements Retrospective 31

Your Own Requirements Process 31

In Conclusion 33

Chapter 3 Project Blastoff 35

Agility Guide 38

IceBreaker 38

Scope, Stakeholders, Goals 40

Setting the Scope 40

Stakeholders 45

Other Stakeholders 51

Finding the Stakeholders 54

Goals: What Do You Want to Achieve? 55

Requirements Constraints 60

Naming Conventions and Definitions 61

How Much Is This Going to Cost? 62

Risks 63

To Go or Not to Go 64

Blastoff Alternatives 65

Summary 65

Chapter 4 Event-Driven Use Cases 67

Agility Guide 67

Understanding the Work 67

Use Cases and Their Scope 69

The Work 70

The Context of the Work 70

Business Events 73

Why Business Events and Business Use Cases Are a Good Idea 75

Finding the Business Events 76

Business Use Cases 78

The Role of Adjacent Systems 79

Business Use Cases and Product Use Cases 86

Summary 90

Chapter 5 Trawling for Requirements 93

Agility Guide 93

Responsibility 94

Trawling and Business Use Cases 96

The Role of the Current Situation 98

Apprenticing 101

Observing Structures and Patterns 103

Interviewing the Stakeholders 104

Getting to the Essence of the Work 107

Solving the Right Problem 109

Innovative Products 110

Business Use Case Workshops 113

Creativity Workshops 116

Brainstorming 117

Personas 119

Mind Maps 122

Wallpaper 124

Video and Photographs 124

Wikis, Blogs, and Discussion Forums 125

Document Archeology 126

Some Other Requirements-Gathering Techniques 128

Determining What the Product Should Be 129

Does Technology Matter? 131

Choosing the Best Trawling Technique 132

Summary 134

Chapter 6 Scenarios and Requirements 135

Agility Guide 135

Scenarios 136

Normal Case Scenarios 140

Diagramming the Scenario 142

Alternative Cases 144

Exception Cases 145

What If? Scenarios 146

Misuse Cases and Negative Scenarios 147

Scenario Template 148

Product Use Case Scenarios 150

Summary 152

Chapter 7 Functional Requirements 155

Agility Guide 155

Functional Requirements 157

Finding the Functional Requirements 157

Level of Detail or Granularity 160

Exceptions and Alternatives 161

Avoiding Ambiguity 162

Technological Requirements 164

Requirements, Not Solutions 165

Grouping Requirements 166

Alternatives to Functional Requirements 167

Summary 169

Chapter 8 Nonfunctional Requirements 171

Agility Guide 172

Nonfunctional Requirements 173

Use Cases and Nonfunctional Requirements 174

The Nonfunctional Requirements 174

Look and Feel Requirements: Type 10 176

Usability and Humanity Requirements: Type 11 178

Performance Requirements: Type 12 182

Operational and Environmental Requirements: Type 13 184

Maintainability and Support Requirements: Type 14 186

Security Requirements: Type 15 187

Cultural and Political Requirements: Type 16 190

Legal Requirements: Type 17 192

Finding the Nonfunctional Requirements 195

Don't Write a Solution 199

Summary 201

Chapter 9 Fit Criteria 203

Agility Guide 203

Why Does Fit Need a Criterion? 204

Scale of Measurement 206

Rationale 206

Fit Criteria for Nonfunctional Requirements 208

Fit Criteria for Functional Requirements 217

Use Cases and Fit Criteria 218

Fit Criterion for Project Purpose 219

Fit Criteria for Solution Constraints 219

Summary 220

Chapter 10 Writing the Requirements 223

Agility Guide 223

Turning Potential Requirements into Written Requirements 225

Knowledge Versus Specification 225

The Volere Requirements Specification Template 227

1 The Purpose of the Project 229

2 The Client, the Customer, and Other Stakeholders 232

3 Users of the Product 233

4 Mandated Constraints 234

5 Naming Conventions and Definitions 237

6 Relevant Facts and Assumptions 238

7 The Scope of the Work 240

8 The Scope of the Product 241

The Shell 241

The Atomic Requirement 243

Writing the Specification 248

9 Functional Requirements 249

Nonfunctional Requirements 251

Project Issues 252

18 Open Issues 252

19 Off-the-Shelf Solutions 253

20 New Problems 254

21 Tasks 254

22 Migration to the New Product 254

23 Risks 254

24 Costs 255

25 User Documentation and Training 256

26 Waiting Room 256

27 Ideas for Solutions 257

Summary 257

Chapter 11 The Quality Gateway 259

Agility Guide 260

Requirements Quality 261

Using the Quality Gateway 262

Testing Completeness 263

Testing Traceability 265

Consistent Terminology 267

Relevant to Purpose? 268

Testing the Fit Criterion 270

Viable within Constraints? 272

Requirement or Solution? 273

Customer Value 274

Gold Plating 275

Requirements Creep 276

Implementing the Quality Gateway 279

Summary 281

Chapter 12 Prototyping the Requirements 283

Agility Guide 285

Prototypes and Reality 286

Low-Fidelity Prototypes 288

High-Fidelity Prototypes 292

Storyboards 294

Object Life History 296

The Prototyping Loop 297

Summary 301

Chapter 13 Reusing Requirements 303

What Is Reusing Requirements? 303

Sources of Reusable Requirements 306

Requirements Patterns 307

A Business Event Pattern 309

Forming Patterns by Abstracting 313

Domain Analysis 317

Trends in Reuse 318

Reuse and Objects 318

Summary 319

Chapter 14 Reviewing the Specification 321

Agility Guide 322

Reviewing the Specification 323

Inspections 323

Find Missing Requirements 324

Have All Business Use Cases Been Discovered? 325

Define the Scope 326

Customer Value 332

Prioritizing the Requirements 333

Conflicting Requirements 337

Ambiguous Specifications 339

Risk Analysis 340

Measure the Required Effort 342

Summary 342

Chapter 15 Whither Requirements? 345

Adapting the Process 345

What About Requirements Tools? 347

Mapping Tools to Purpose 348

Publishing the Requirements 350

Requirements Traceability 353

Dealing with Change 357

Requirements Retrospective 360

Your Notebook 363

The End 363

Appendix A Volere Requirements Process Model 365 Appendix B Volere Requirements Specification Template 451 Appendix C Function Point Counting: A Simplified Introduction 507 Appendix D Project Sociology Analysis Templates 523 Glossary 531 Bibliography 535 Index 539

Read More Show Less

Preface

In the six years since we published the first edition of this book, the world's knowledge of requirements has grown, and more people have a job called "business analyst," "requirements engineer," or something similar. The Volere Requirements Specification Template has been downloaded countless times. The Volere Requirements Process is in use by thousands of people who are engaged in the activity of successful requirements gathering. They, in turn, have given us feedback over the years about what they needed to know, and what they are doing when gathering requirements.

This book is a reflection of the feedback we have received, and of the way people have made use of the first edition.

The requirements activity has moved away from wanting to be seen as an engineering discipline, to the realization that it is a sociotechnical activity. Requirements analysts now see their role first as one of communication, and second as a technician adding rigor and precision to the results of the human communication.

As a result, we have updated and expanded the project sociology analysis section of the book. In a similar vein, we have added the appropriate rigor to the technicalities of recording and measuring the requirements.

Perhaps the greatest change to come along since the first edition has been the arrival of agile methods, accompanied by some wonderful technological advances. Agile methods have influenced the way people develop software, with the result being that greater emphasis is placed on close customer relationships, and less emphasis is placed on documentation. We heartily applaud this advance. However, we have also seen too many people, who, in the name of agility, rush to a solution without first understanding the real business problem to be solved.

This, then, is the role of requirements in the agile world: to ensure that we hear not only one customer's voice, but also the voices of the other stakeholders—those with some value to add to the requirements for the product. Agile requirements analysts ensure that the work is considered, not just the product, and that the nonfunctional requirements are studied, not left to the whim of the programmer.

Agile methods have brought with them a healthy disdain for documentation. We agree with this view. Throughout this second edition we urge you to consider the benefit before committing anything to writing. But while we suggest sometimes you can develop software successfully without formally written requirements, we never suggest you can do it without understanding the requirements.

The emphasis on iterative development means that the requirements "phase" is no longer completed before building begins. The drive toward short, sharp release cycles means requirements analysts get feedback on their requirements efforts more quickly. Stakeholders receive positive reinforcement when they see the time they invest in requirements paid back with progressive versions of working software that does what they expect, and what they need.

Technological advances have changed requirements gathering. Blogs and wikis mean that requirements analysts can gather their requirements informally and iteratively using the convenience of networking with their stakeholders. Desktop videoconferencing and instant messaging mean closer, quicker communication with stakeholders, which is, of course, necessary for good requirements gathering.

The gap between what we wrote in 1999 and what we found ourselves doing when gathering requirements gradually grew wider, until we knew it was time to update our book. The volume that you hold in your hands is the result of the last few years of our work and teaching. We trust you find it interesting, enlightening, and useful.

Read More Show Less

Customer Reviews

Average Rating 4
( 5 )
Rating Distribution

5 Star

(2)

4 Star

(2)

3 Star

(0)

2 Star

(1)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 – 4 of 5 Customer Reviews
  • Anonymous

    Posted May 24, 2006

    a sociological text

    [A review of the SECOND EDITION, 2006.] The main context of this book is for software projects. If you are reading these words, you probably hail from that environment. But the authors do explain that the processes they describe are applicable to almost any project. This is not a software book, per se. Not a line of code appears here, as far as I can tell. Most programmers know that design is important, and should usually precede any coding. The book's contribution is about that design and its prelude. Namely the gathering and determination of what the requirements might be. The authors point out that this makes the book in no small part a sociological text. About how to get a group of people together, and to solicit their contributions and perceptions into the project's requirements. Managing the dynamics of this is the purview of sociology [and psychology]. Without a solid performance here, subsequent design and coding may rest on quicksand. The book does acknowledge that recent technological innovations like blogs and wikis can lead to quicker feedback. And hence contribute to a more interactive and iterative scenario of updating requirements as the project proceeds. All in the Agile spirit that many teams are now using. Just remember that the blogs and wikis are not a substitute for physically getting the team together. Much of the dynamics and feedback in the processes given by the book do really require that physical presence, to enhance the members' contributions.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted March 17, 2010

    No text was provided for this review.

  • Anonymous

    Posted February 19, 2010

    No text was provided for this review.

  • Anonymous

    Posted October 18, 2011

    No text was provided for this review.

Sort by: Showing 1 – 4 of 5 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)