Mastering the Requirements Process (2nd Edition) (Hardcover)

by Suzanne Robertson (Author), James C. Robertson (Author) "The most useful products are those where the developers have understood what the product is intended to accomplish for its users and how it must..." (more)
Key Phrases: quality gateway, mandated constraints, active stakeholders, Dorset House, Event-Driven Use Cases, Whither Requirements (more...)

Editorial Reviews

Amazon.com Review
Written in an engaging style and relevant for any software analyst or designer, Mastering the Requirements Process provides a powerful and useful guide to defining more complete software requirements that lead to better software overall. It's also filled with innovative advice.

The heart of this book is the authors' Volere Requirements Process Model, a step-by-step guide to gathering your requisites. Throughout this book, the authors use this process to explicate a single case study--a system for a municipality that will optimize the de-icing of roadways during snowy weather. Along the way, the book provides a solid guide to identifying and refining requirements, both functional and nonfunctional (such as performance and ease of use).

There are many excellent ideas in the book, including the notion of fitness for your requirements, which can be later used to track whether the software is successful. The book also wisely separates technology from requirements so that analysts can concentrate on understanding and modeling business problems instead of moving right away to the nuts and bolts of implementation. Even if you don't adopt the Volere model in toto, you can benefit from the concepts of "trawling" (a metaphor for the requirements-gathering process), quality gateways (in which tentative requirements are evaluated for inclusion in a project), and the wise use of patterns to help simplify the process.

Anchored by numerous examples (including many samples of successful requirements), the book provides an appealing mix of new ideas along with a remarkably clear presentation. In short, Mastering the Requirements Process provides useful advice that can make the project specification building phase of the software process easier and more robust. It provides the first steps for improving overall software quality for your organization. --Richard Dragan

Topics covered: Volere Requirements Process Model; project blastoff; determining requirements; user and stakeholders; project constraints; requirements constraints; use cases; business events; adjacent systems; innovation; trawling for requirements: apprenticing, interviews, and videotape; functional and nonfunctional requirements; fit criteria; quality gateways; traceability; prototyping and scenarios; low and high fidelity prototypes; patterns and requirements reuse; improving the requirements gathering process. --This text refers to the Hardcover edition.

Review
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. -- Robert L. Glass --This text refers to the Hardcover edition.

See all Editorial Reviews

Product Details

• Hardcover: 592 pages
• Publisher: Addison-Wesley Professional; 2 edition (March 27, 2006)
• Language: English
• ISBN-10: 0321419499
• ISBN-13: 978-0321419491
• Product Dimensions: 9.6 x 7.7 x 1.3 inches
• Shipping Weight: 2.4 pounds (View shipping rates and policies)
• Average Customer Review: 4.4 out of 5 stars See all reviews (26 customer reviews)
• Amazon.com Sales Rank: #107,866 in Books (See Bestsellers in Books)

  Popular in these categories: (What's this?)

  #26 in	Books > Computers & Internet > Computer Science > Software Engineering > Design Tools & Techniques
  #91 in	Books > Computers & Internet > Project Management > PMP Exam

Customer Reviews

Most Helpful Customer Reviews

86 of 92 people found the following review helpful:

5.0 out of 5 stars This book is terrific!, August 28, 2000

By	Tony Stewart (New York, NY United States) - See all my reviews

This review is from: Mastering the Requirements Process (Hardcover)

This is not only the best book on requirements gathering that I've found, it is one of the best books on *any* aspect of software development that I've ever read. It is clear, focussed, well-written, full of extremely powerful concepts, and illustrated with useful examples and formal models of all aspects of the requirements gathering process and requirements-related information. As a result, I not only gained tremendous insight into how to improve the requirements gathering process at our company, I also learned by clear example how to make best use of each of the modeling formalisms the authors recommend.

I've never written an on-line review before, but this book was so superior that I felt I had to take the time and share my enthusiasm. I hope you find it as valuable in your projects as we are finding at our company.

48 of 50 people found the following review helpful:

5.0 out of 5 stars Practical, effective and usable how-to manual!, September 2, 1999

By A Customer

This review is from: Mastering the Requirements Process (Hardcover)

This excellent treatment of the requirements process provides practical, step-by-step guidance. Given the impact of requirements specification on the success or failure of software products, the value of this timely book is tremendous. The generous examples supply the necessary concreteness for individuals and organizations to put the specific process into practice. Essential reading should also include a general requirements text, such as "Exploring Requirements" by Gause and Weinberg, before or in parallel with this book.

39 of 40 people found the following review helpful:

5.0 out of 5 stars I've used for in several projects now., February 17, 2000

By	Dean Waye (Oviedo, FL USA) - See all my reviews

This review is from: Mastering the Requirements Process (Hardcover)

This is the best book on requirements gathering I have ever read. When I finished it, I asked for and received the authors' permission to use the Volere template for a couple of test cases in my job (I specialize in requirements gathering) and have used it for one very large and another very famous client, with excellent results. While it doesn't especially lend itself to Internet projects, it significantly cuts down the time it takes me to gather requirements, and adds a level of consistency to the requirements documents my colleagues and I produce. Definitely worth the money.