Mastering the Requirements Process 2nd Edition
|New from||Used from|
There is a newer edition of this item:
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Customers who viewed this item also viewed
Customers who bought this item also bought
About 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).
Excerpt. © Reprinted by permission. All rights reserved.
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.
- Item Weight : 2.78 pounds
- Hardcover : 560 pages
- ISBN-10 : 0321419499
- ISBN-13 : 978-0321419491
- Dimensions : 7.75 x 1 x 9.5 inches
- Publisher : Addison-Wesley Professional; 2nd edition (March 17, 2006)
- Language: : English
- Best Sellers Rank: #1,412,303 in Books (See Top 100 in Books)
- Customer Reviews:
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
The main negative to me (as someone who doesn't deal with Software systems) is that even though it tries to be system independent, it has a very clear software flavour to it.
STYLE AND COMMUNICATION
The writing style is fairly light and very readable, and the book clearly communicates to the reader. The layout is good, with good sidebars for references, additional reading and quotes. Diagrams are easy to understand.
ICE BREAKER EXAMPLE
An example of a road de-icing system is introduced early in the book and is used throughout the book to illustrate the points that the authors are making. It was a good example, being a combination of hardware, software and people, and was used effectively.
A DEFINITE SOFTWARE FLAVOUR
Although the book seems to try to be system independent, there are a number of sections that lapse back into talking about software, which is the authors' background. Eg p 161. "The detail of each requirement is intended to be sufficient for the developers to write the correct software from it".
This also does affect the content of the material, so some of the messages do not apply to non software system. Eg p 186 talks about maintainability being about modifying the product to cater for changes in the organisation or environment. This may be applicable for software, but for hardware systems maintainability will be about ease and cost of repair, inspection etc
Because the author's experience is clearly rooted in the software world, there is some doubt in my mind as to whether the process recommended is ideally suited to non-software systems.
A reasonable chunk of the book talked about business uses cases and product use cases, and this was probably one of the best parts of the book for me, being not so familiar with this area. It clearly articulated with examples how to develop scenarios and then business and product use cases, without getting into the detail of UML and other modelling tools.
An interesting concept is the concept of Fit Criteria, which is a way of turning a potentially subjective or unverifiable requirements into objective and testable requirement. I'm not sure I agree with the author's approach of separating the fit criterion from the requirement, but the concept is certainly very useful.
The section on reviewing the specification had some good suggestions on how to check for missing requirements, which is one of the hardest things to do and is probably the most important.
There wasn't much about the actual writing of requirements: this is a book about the requirements process, so maybe it can be excused for not focussing on requirement writing.
However, there is a lot of good information, if you can stay away through the reading.
However, the text is highly repetitive and wandering making it hard to read. One can only read the same thing in so many ways, so many times before wondering "what's the point?"
I think this would make a great introduction to requirements gathering process if it were written more concisely and to the point, with better English.
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.
I've been doing requirements for more than 20 years and I learned things from this book. The notion of the "Blast Off" (hate that term, love the concept) as a key political event reinforced and expanded ideas I had before. The extensive checklist for the "Blast Off" is much more thorough than anything I've ever put together myself. The idea of "Trolling for Requirements" also expanded my horizons. The Volare snow card is an excellent starting point for collecting requirements that emphasizes the point that understanding the rational behind a requirement is as important as understanding the requirement itself.
Over the years I've used this book as the basis for a series of brown bag lunches to help junior analysts better appreciate the nature of the requirements process. It has been generally well received. I've probably purchases over a dozen copies of this book to give to others, some of them with my own money. Along with Exploring Requirements: Quality Before Design this is one of the first two books every business or system analyst should read.
Top reviews from other countries
I like it!