What do you think?
Rate this book
Mastering the Requirements Process
"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 situations964 pages, Kindle Edition
First published August 12, 1999
61 people are currently reading
448 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 13 of 13 reviews
November 25, 2015
there is nothing groundbreaking about this book and it wins in its simplicity. With that said, it's a great beginner book, it's also a terrible beginner book.
The over simplification and sometimes just plain wrong explanations of concepts like UML, Functional point counting can leave a beginner in bad shape. If this book is heavily supplemented by the additional readings supplied in the margins, I'd be less skeptical.
The main reason I rated this book so low is because of the authors absolute transparent attempt to reinvent the wheel in their model and thus profit from it through their consultancy. A user story is called a snow card. They invented terms like product use cases, atomic requirements, and so on. It's not the end of the world, but I found it adding more terminology to items that have been thoroughly defined through the public domain.
Finally the authors have a ton of filler. In a typical paragraph only a half a sentence is valuable. I'm use to some filler but this book takes the cake.
I read this book cover to cover and took a ton of notes. I found gems in it and you will to. Just be aware of the oversimplification, and be prepared to heavily supplement.
The over simplification and sometimes just plain wrong explanations of concepts like UML, Functional point counting can leave a beginner in bad shape. If this book is heavily supplemented by the additional readings supplied in the margins, I'd be less skeptical.
The main reason I rated this book so low is because of the authors absolute transparent attempt to reinvent the wheel in their model and thus profit from it through their consultancy. A user story is called a snow card. They invented terms like product use cases, atomic requirements, and so on. It's not the end of the world, but I found it adding more terminology to items that have been thoroughly defined through the public domain.
Finally the authors have a ton of filler. In a typical paragraph only a half a sentence is valuable. I'm use to some filler but this book takes the cake.
I read this book cover to cover and took a ton of notes. I found gems in it and you will to. Just be aware of the oversimplification, and be prepared to heavily supplement.
March 9, 2017
Used for both an assignment in final year and then for my dissertation. The approach is simplified which is good for students starting out on their process journey, however it is seriously lacking in some areas that need further explanation.
Most useful aspect is the requirement template given, which is similar to many other templates out there (IEEE Recommended Practice standard for example. The SNOW card approach is also useful, though way too time consuming for most university modules. I decided to give a couple of SNOW cards as an example and then focus more on how they emphasise key requirement characteristics (the -ility words).
Overall worth reviewing if you are studying the Requirements Process, however also make sure to consider the other approaches out there.
Most useful aspect is the requirement template given, which is similar to many other templates out there (IEEE Recommended Practice standard for example. The SNOW card approach is also useful, though way too time consuming for most university modules. I decided to give a couple of SNOW cards as an example and then focus more on how they emphasise key requirement characteristics (the -ility words).
Overall worth reviewing if you are studying the Requirements Process, however also make sure to consider the other approaches out there.
February 17, 2016
After mislaying this book for months, I finally rediscovered it, and I'm glad I did. By far the best book on Requirements that I've read, as you might expect from the developers of the Volere requirements template.
Covers the processes of project inception and requirement gathering as well as the mechanics of recording & managing requirements.
If there's a minor caveat, the references to Agile processes feel like they've been crow-barred in a bit to justify retaining a heavy-duty requirements process, though this is tempered by guidance on scaling each section to different styles of project (though here, the use of animal metaphors got very wearing).
Strongly recommended
Covers the processes of project inception and requirement gathering as well as the mechanics of recording & managing requirements.
If there's a minor caveat, the references to Agile processes feel like they've been crow-barred in a bit to justify retaining a heavy-duty requirements process, though this is tempered by guidance on scaling each section to different styles of project (though here, the use of animal metaphors got very wearing).
Strongly recommended
July 1, 2025
A classic, introductory textbook on Requirements Engineering, which focuses on eliciting business process requirements, engineering and reviewing the software product’s functional and nonfunctional requirements.
I have read the second and the fourth editions of this book. Both editions cover requirements engineering for agile, plan-driven, and hybrid software development models.
I agree with other reviewers that, in the second edition, the material on requirements for agile and hybrid software development models appears to be an afterthought and has a forced, shoe-horned feel. I also agree with other reviewers that the use of animal metaphors for the development models (rabbit, horse, and elephant) gets tiresome and repetitive very quickly and doesn’t add any deep -or intermediate level- understanding to the topics. In the fourth edition, the names of the development models are changed to agile, regular commercial, and milspec -which is a somewhat better nomenclature -except for the use of "regular commercial" software development models, which is not very helpful, since there are regular commercial software which lends itself well to agile development for example, and thers are large-scale commercial efforts which may very well benefit from a milspec approach. I prefer Gary Spurrier and Heikki Topi' Systems Analysis & Design in an Age of Options taxonomy of Agile, Plan driven, Big Requirements Up Front (BRUF), and Big Design Up Front (BDUF) software development models. Both editions cover topics such as project kickoff -called project blastoff in the book-, and defining the purpose, scope, stakeholders, constraints, glossary of terms, relevant facts and assumptions, estimated (first-cut) costs, risks, business use cases, product use cases, and requirements for the project. The sections on costs, risks, domain analysis, and the use of low-fidelity prototypes to help uncover requirements are perfunctory. The authors rely heavily on user cases -unnecessarily renamed snow cards in both editions- which include for each requirement, the interested/affected stakeholder(s), a rationale (preferably its business benefit), and fit criteria (to make the requirement measurable, or in agile INVEST terms, testable). The arguments and examples of fit criteria rely heavily on Tom Gilb’s Planguage work. In the fourth edition, INVEST criteria for requirements are briefly explained.
The book is an easy read, if somewhat repetitive at times, and is most noteworthy for its many valuable and succinct tips scattered throughout its text. For example, in chapter 5 of the second edition (Trawling for requirements the authors mention that stakeholders may have
I found the most interesting chapters in the second edition to be:
The latest edition of this book is the fourth 2024 edition, which claims to have been extensively rewritten and updated. The fifteen chapters of the second edition splinter into forty-five much shorter, tweet-like chapters -I strongly prefer the more leisurely fifteen-chapter organization. In the fourth edition, the authors have replaced many of the examples, which, by 2024, sound aged or obsolete. In 2006, they briefly jumped on the bandwagon of neurolinguistics; in 2024 they devote a brief, sensible but superficial chapter on the use of Artificial Intelligence in Business Analysis, brushing past the use of AI components in software products. Unfortunately, the chapter's referenced resources are already dated and merely include a few pre-ChatGPT gung ho articles on AI.
In my opinion, somewhat surprisingly, most of the second edition of this book still works as part of an undergraduate-level introduction to requirements engineering for business analysis, information systems, or software engineering students. The, to me simplified, fourth edition of this book appears to be satisfactory only for introductory undergraduate courses in business analysis for software development -although I must admit an important and necessary effort has been made to replace some older examples with more current material.
I have read the second and the fourth editions of this book. Both editions cover requirements engineering for agile, plan-driven, and hybrid software development models.
I agree with other reviewers that, in the second edition, the material on requirements for agile and hybrid software development models appears to be an afterthought and has a forced, shoe-horned feel. I also agree with other reviewers that the use of animal metaphors for the development models (rabbit, horse, and elephant) gets tiresome and repetitive very quickly and doesn’t add any deep -or intermediate level- understanding to the topics. In the fourth edition, the names of the development models are changed to agile, regular commercial, and milspec -which is a somewhat better nomenclature -except for the use of "regular commercial" software development models, which is not very helpful, since there are regular commercial software which lends itself well to agile development for example, and thers are large-scale commercial efforts which may very well benefit from a milspec approach. I prefer Gary Spurrier and Heikki Topi' Systems Analysis & Design in an Age of Options taxonomy of Agile, Plan driven, Big Requirements Up Front (BRUF), and Big Design Up Front (BDUF) software development models. Both editions cover topics such as project kickoff -called project blastoff in the book-, and defining the purpose, scope, stakeholders, constraints, glossary of terms, relevant facts and assumptions, estimated (first-cut) costs, risks, business use cases, product use cases, and requirements for the project. The sections on costs, risks, domain analysis, and the use of low-fidelity prototypes to help uncover requirements are perfunctory. The authors rely heavily on user cases -unnecessarily renamed snow cards in both editions- which include for each requirement, the interested/affected stakeholder(s), a rationale (preferably its business benefit), and fit criteria (to make the requirement measurable, or in agile INVEST terms, testable). The arguments and examples of fit criteria rely heavily on Tom Gilb’s Planguage work. In the fourth edition, INVEST criteria for requirements are briefly explained.
The book is an easy read, if somewhat repetitive at times, and is most noteworthy for its many valuable and succinct tips scattered throughout its text. For example, in chapter 5 of the second edition (Trawling for requirements the authors mention that stakeholders may have
- Conscious requirements -which are the ones which are at the top of a stakeholder’s mind,In the same chapter they suggest applying some simple and effective neurolinguistic programming techniques to analyze and improve preliminary statements to turn them into more effective requirements. Sadly, these two topics are omitted from the fourth edition.
- Unconscious requirements, which can be thought of as embedded within implicit stakeholder knowledge, and
- Undreamed-of requirements, which are requirements that are possible but that stakeholders don’t realize are possible.
I found the most interesting chapters in the second edition to be:
- Trawling for requirements (chapter 5) -except for the very poor section on Peter Checkland’s soft systems methodology;The authors use an interesting, and unusual, running example as a case study throughout the text -a software system to help plan, organize and supervise de-icing for winter roads. The example is, unfortunately, not very interesting for most tropical and subtropical countries in the world. In such countries, a far more serious, and somewhat related, problem de-icing roads is preparing drain-off waterways for the wet season when the dry season. At the end of the dry season, gullies, streams, and other runoff water channels may be clogged with leaves, trunks, and debris and require cleaning and dredging to prevent such channels from overflowing and flooding extensive rural and urban areas. Domains for such a problem include waterways, weather, scheduling, trucking, as well as dredging, draining, and water-bank maintenance teamwork. Unfortunately, in the fourth edition, the de-icing problem is downplayed, losing much of its charm and completeness, and a second running case study based on a (classic) and elementary library service disappears entirely.
- Scenarios and requirements (chapter 6), particularly its introductory coverage of negative and misuse scenarios.
- Functional requirements (chapter 7) and Nonfunctional requirements (chapter 8), which cover the essentials of these important topics and provide pointed and simple examples. In my opinion, the sections on social and political requirements are far too skimpy and completely miss the importance of coming up with value-driven, ethical nonfunctional requirements.
- Reviewing the specification (chapter 14). The authors define the project’s specification as its business and product use cases as well as its requirements, assumptions, and constraints. This chapter provides ideas on checking and analyzing the specification for completeness, consistency, and feasibility (and stakeholder value?). I particularly liked how the chapter shows how Fagan inspection techniques can be applied to the specification review -another topic which disappears from the fourth edition.
- Whither requirements? (chapter 15), which, among other things, convincingly argues for carrying out retrospectives on the requirements process.
The latest edition of this book is the fourth 2024 edition, which claims to have been extensively rewritten and updated. The fifteen chapters of the second edition splinter into forty-five much shorter, tweet-like chapters -I strongly prefer the more leisurely fifteen-chapter organization. In the fourth edition, the authors have replaced many of the examples, which, by 2024, sound aged or obsolete. In 2006, they briefly jumped on the bandwagon of neurolinguistics; in 2024 they devote a brief, sensible but superficial chapter on the use of Artificial Intelligence in Business Analysis, brushing past the use of AI components in software products. Unfortunately, the chapter's referenced resources are already dated and merely include a few pre-ChatGPT gung ho articles on AI.
In my opinion, somewhat surprisingly, most of the second edition of this book still works as part of an undergraduate-level introduction to requirements engineering for business analysis, information systems, or software engineering students. The, to me simplified, fourth edition of this book appears to be satisfactory only for introductory undergraduate courses in business analysis for software development -although I must admit an important and necessary effort has been made to replace some older examples with more current material.
May 28, 2014
Interesting, if a little repetitive in places. A big subject covered well enough. Definitely worthy as a point of reference, though by no means definitive. Valuable cross referencing, and rightly highlights the shortcomings of a book in a changing world.
February 28, 2015
Not a ton of new techniques but the book gave me new language to use when helping to explain the BA process- especially to help ppl realize that the initial thought might not be solving the right problem
July 18, 2015
Very good but needs an update to include new means of handling sprint and agile requirement-building.
January 13, 2015
If you need to gather requirements for your projects this book will be a great help. It not only explains what requirements gathering is but explains a useful process in a lot of details. Even when you have no other experience you will be able to start and collect the different expectations and needs much faster and better. You will learn how to measure things that seams unmeasurable and how important it is to write down a reason for every feature request.
To put those ideas in practice you can use the Volere template that is part of appendix A. With that template as a starting place you are reminded of all the different things you should think about. The template alone will not make your project a success, but with the structure it offers the chances are really good that you will have all the important points in your requirements document. And from there it’s much simpler to build the right thing.
If you don’t like the Volere process you still get a lot of good advice on the gathering of requirements. You may need to fill in some gaps to your process but that should not be too hard.
September 13, 2012
The best book I've ever read about requirements engineering. the authors discuss more than requirements - they discusses also buisness analyses as well. The book comes with a template and an example project. With the template you will never lost any aspect of buisness analysis.
March 11, 2009
Landmark in requirements. Popular internationally.
March 30, 2013
A must-read book on product management for knowledge workers and entrepreneurs.
March 30, 2013
A must-read book on product management for knowledge workers and entrepreneurs.
Displaying 1 - 13 of 13 reviews