Mastering the Requirements Process: Getting Requirements Right / Edition 3

Hardcover (Print)
Buy New
Buy New from BN.com
$51.23
Used and New from Other Sellers
Used and New from Other Sellers
from $45.07
Usually ships in 1-2 business days
(Save 30%)
Other sellers (Hardcover)
  • All (10) from $45.07   
  • New (8) from $45.07   
  • Used (2) from $47.23   

Overview

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

—Capers Jones

Software can solve almost any problem. The trick is knowing what the problem is. With about half of all software errors originating in the requirements activity, it is clear that a better understanding of the problem is needed.

Getting the requirements right is crucial if we are to build systems that best meet our needs. We know, beyond doubt, that the right requirements produce an end result that is as innovative and beneficial as it can be, and that system development is both effective and efficient.

Mastering the Requirements Process: Getting Requirements Right, Third Edition, sets out an industry-proven process for gathering and verifying requirements, regardless of whether you work in a traditional or agile development environment. In this sweeping update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs, in the most efficient manner possible.

Features include

  • The Volere requirements process for discovering requirements, for use with both traditional and iterative environments
  • A specification template that can be used as the basis for your own requirements specifications
  • Formality guides 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
  • Checklists to help identify stakeholders, users, non-functional requirements, and more
  • Methods for reusing requirements and requirements patterns

New features include

  • Strategy guides for different environments, including outsourcing
  • Strategies for gathering and implementing requirements for iterative releases
  • “Thinking above the line” to find the real problem
  • How to move from requirements to finding the right solution
  • The Brown Cow model for clearer viewpoints of the system
  • Using story cards as requirements
  • Using the Volere Knowledge Model to help record and communicate requirements
  • Fundamental truths about requirements and system development
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: 9780321815743
  • Publisher: Addison-Wesley
  • Publication date: 8/20/2012
  • Edition description: New Edition
  • Edition number: 3
  • Pages: 768
  • Sales rank: 175,085
  • Product dimensions: 9.60 (w) x 7.70 (h) x 1.40 (d)

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 Third Edition xxi

Foreword to the First Edition xxiii

Acknowledgments xxv

Chapter 1: Some Fundamental Truths 1

in which we consider the essential contribution of requirements

Truth 1 1

Truth 2 2

Truth 3 3

Truth 4 4

Truth 5 5

Truth 6 6

Truth 7 7

Truth 8 7

Truth 9 8

Truth 10 8

Truth 11 9

What Are These Requirements Anyway? 9

The Volere Requirements Process 11

Chapter 2: The Requirements Process 13

in which we present a process for discovering requirements and discuss how you might use it

The Requirements Process in Context 14

A Case Study 15

Project Blastoff 15

Trawling for Requirements 17

Quick and Dirty Modeling 19

Scenarios 20

Writing the Requirements 20

Quality Gateway 22

Reusing Requirements 23

Reviewing the Requirements 23

Iterative and Incremental Processes 24

Requirements Retrospective 25

Evolution of Requirements 26

The Template 27

The Snow Card 29

Your Own Requirements Process 31

Formality Guide 32

The Rest of This Book 33

Chapter 3: Scoping the Business Problem 35

in which we establish a definition of the business area to be changed, thereby ensuring that the project team has a clear vision of what their project is meant to achieve

Project Blastoff 35

Formality Guide 38

Setting the Scope 38

IceBreaker 41

Scope, Stakeholders, and Goals 43

Stakeholders 44

Other Stakeholders 50

Finding the Stakeholders 54

Goals: What Do You Want to Achieve? 54

Constraints 59

Naming Conventions and Definitions 60

How Much Is This Going to Cost? 61

Risks 62

To Go or Not to Go 63

Blastoff Meetings 64

Summary 65

Chapter 4: Business Use Cases 67

in which we discuss a fail-safe way of partitioning the work and so smooth the way for your requirements investigation

Understanding the Work 67

Formality Guide 69

Use Cases and Their Scope 69

The Scope of the Work 70

Business Events 73

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

Finding the Business Events 78

Business Use Cases 80

Business Use Cases and Product Use Cases 82

Summary 85

Chapter 5: Investigating the Work 87

in which we come to an understanding of what the business is doing, and start to think about what it might like to do

Trawling the Business 87

Formality Guide 89

Trawl for Knowledge 89

The Business Analyst 91

Trawling and Business Use Cases 92

The Brown Cow Model 93

The Current Way of Doing Things (How-Now) 94

Apprenticing 98

Business Use Case Workshops 99

Interviewing the Stakeholders 102

Looking for Reusable Requirements 106

Quick and Dirty Process Modeling 107

Prototypes and Sketches 109

Mind Maps 116

The Murder Book 119

Video and Photographs 120

Wikis, Blogs, Discussion Forums 122

Document Archeology 123

Family Therapy 125

Choosing the Best Trawling Technique 125

Finally . . . 127

Chapter 6: Scenarios 129

in which we look at scenarios, and how the business analyst uses them to communicate with the stakeholders

Formality Guide 129

Scenarios 130

The Essence of the Business 135

Diagramming the Scenario 138

Alternatives 139

Exceptions 140

What if? Scenarios 142

Misuse Cases and Negative Scenarios 142

Scenario Template 143

Summary 145

Chapter 7: Understanding the Real Problem 147

in which we “think above the line” to find the true essence of the business, and so deliver the right product–one that solves the right problem

Formality Guide 149

The Brown Cow Model: Thinking Above the Line 149

Solving the Right Problem 156

Moving into the Future 157

How to Be Innovative 160

Systemic Thinking 162

Value 165

Personas 166

Challenging Constraints 169

Innovation Workshops 171

Brainstorming 173

Back to the Future 174

Chapter 8: Starting the Solution 177

in which we bring the essence of the business into the technological world of the implementation

Iterative Development 179

Essential Business 179

Determine the Extent of the Product 180

Consider the Users 181

Designing the User Experience 183

Innovation 184

Sketching the Interface 188

The Real Origin of the Business Event 189

Adjacent Systems and External Technology 190

Cost, Benefit, and Risks 194

Document Your Design Decisions 195

Product Use Case Scenarios 196

Putting It All Together 199

Chapter 9: Strategies for Today’s Business Analyst 203

in which we consider strategies for the business analyst to guide requirements discovery in today’s changing environments

Balancing Knowledge, Activities, and People 204

Common Project Requirements Profiles 204

How Much Knowledge Is Needed Before Each Breakout? 205

External Strategy 206

Iterative Strategy 210

Sequential Strategy 212

Your Own Strategy 215

Sharpening Your Requirements Skills 215

Summary 222

Chapter 10: Functional Requirements 223

in which we look at those requirements that cause the product to do something

Formality Guide 224

Functional Requirements 225

Uncovering the Functional Requirements 225

Level of Detail or Granularity 228

Description and Rationale 229

Data, Your Secret Weapon 231

Exceptions and Alternatives 233

Conditional Requirements 234

Avoiding Ambiguity 234

Technological Requirements 237

Grouping Requirements 237

Alternatives to Functional Requirements 238

Requirements for COTS 241

Summary 242

Chapter 11: Non-functional Requirements 245

in which we look at the requirements that specify how well your product does what it does

An Introduction to Non-functional Requirements 246

Formality Guide 246

Functional Versus Non-functional Requirements 247

Use Cases and Non-functional Requirements 248

The Non-functional Requirements Types 249

Look and Feel Requirements: Type 10 250

Usability and Humanity Requirements: Type 11 253

Performance Requirements: Type 12 257

Operational and Environmental Requirements: Type 13 259

Maintainability and Support Requirements: Type 14 261

Security Requirements: Type 15 262

Cultural Requirements: Type 16 266

Legal Requirements: Type 17 268

Finding the Non-functional Requirements 271

Blogging the Requirements 271

Don’t Write a Solution 276

Summary 277

Chapter 12: Fit Criteria and Rationale 279

in which we show how measuring requirements makes them unambiguous, understandable, communicable, and testable

Formality Guide 280

Why Does Fit Need a Criterion? 280

The Rationale for the Rationale 282

Deriving Fit Criteria 284

Scale of Measurement 285

Fit Criteria for Non-functional Requirements 286

Fit Criteria for Functional Requirements 295

Forms of Fit Criteria 296

Use Cases and Fit Criteria 299

Fit Criterion for Project Purpose 299

Fit Criteria for Solution Constraints 300

Summary 301

Chapter 13: The Quality Gateway 303

in which we prevent unsuitable requirements from becoming part of the specification

Formality Guide 304

Requirements Quality 305

Using the Quality Gateway 306

Within Scope? 307

Testing Completeness 311

Testing the Fit Criterion 312

Consistent Terminology 313

Viable within Constraints? 314

Requirement or Solution? 316

Requirement Value 316

Gold Plating 317

Requirements Creep 317

Implementing the Quality Gateway 319

Summary 321

Chapter 14: Requirements and Iterative Development 323

in which we look at how to discover and implement requirements in an iterative development environment

The Need for Iterative Development 323

An Iterative Requirements Process 324

Business Value Analysis and Prioritization 327

How to Write a Good User Story 329

Iterative Requirements Roles 333

Summary 335

Chapter 15: Reusing Requirements 337

in which we look for requirements that have already been written and explore ways to make use of them

What Is Reusing Requirements? 338

Sources of Reusable Requirements 341

Requirements Patterns 342

A Business Event Pattern 344

Forming Patterns by Abstracting 346

Domain Analysis 351

Summary 351

Chapter 16: Communicating the Requirements 353

in which we turn the requirements into communicable form

Formality Guide 353

Turning Potential Requirements into Written Requirements 354

Knowledge Versus Specification 354

The Volere Requirements Specification Template 357

Discovering Atomic Requirements 359

Attributes of Atomic Requirements 361

Assembling the Specification 365

Automated Requirements Tools 366

Functional Requirements 367

Non-functional Requirements 368

Project Issues 369

Summary 369

Chapter 17: Requirements Completeness 371

in which we decide whether our specification is complete, and set the priorities of the requirements

Formality Guide 372

Reviewing the Specification 373

Inspections 373

Find Missing Requirements 374

Have All Business Use Cases Been Discovered? 376

Prioritizing the Requirements 382

Conflicting Requirements 386

Ambiguous Specifications 388

Risk Assessment 388

Measure the Required Cost 391

Summary 391

Appendix A: Volere Requirements Specification Template 393

a guide for writing a rigorous and complete requirements specification

Contents 393

Use of This Template 394

Volere 394

Requirements Types 395

Testing Requirements 396

Atomic Requirements Shell 396

1. The Purpose of the Project 397

2. The Stakeholders 400

3. Mandated Constraints 407

4. Naming Conventions and Terminology 415

5. Relevant Facts and Assumptions 416

6. The Scope of the Work 420

7. Business Data Model and Data Dictionary 425

8. The Scope of the Product 429

9. Functional and Data Requirements 433

Non-functional Requirements 435

10. Look and Feel Requirements 435

11. Usability and Humanity Requirements 437

12. Performance Requirements 441

13. Operational and Environmental Requirements 447

14. Maintainability and Support Requirements 449

15. Security Requirements 451

16. Cultural Requirements 454

17. Legal Requirements 455

Project Issues 457

18. Open Issues 457

19. Off-the-Shelf Solutions 458

20. New Problems 460

21. Tasks 462

22. Migration to the New Product 463

23. Risks 465

24. Costs 467

25. User Documentation and Training 468

26. Waiting Room 470

27. Ideas for Solutions 471

Appendix B: Stakeholder Management Templates 473

Stakeholder Map 473

Stakeholder Template 475

Appendix C: Function Point Counting: A Simplified Introduction 479

in which we look at a way to accurately measure the size or functionality of the work area, with a view toward using the measurement to estimate the requirements effort

Measuring the Work 479

A Quick Primer on Counting Function Points 481

Counting Function Points for Business Use Cases 484

Counting the Stored Data 489

Adjust for What You Don’t Know 492

Now That I Have Counted Function Points, What’s Next? 492

Appendix D: Volere Requirements Knowledge Model 495

Definitions of Requirements Knowledge Classes and Associations 495

Glossary 511

Bibliography 517

Index 523

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

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

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

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