Rating: 
Summary: A very good book
Review: This book is a comprehensive, authoritative review of what good requirements are. I recommend it highly. However, it's not enough by itself. If you study and learn from Wiegers, you will know *what* good software requirements are and how to know if yours are good or not, but not how to get there. He does talk a lot about elicitation and analysis and so on, but in the end I found that I didn't yet have all the tools I needed. I recommend checking out Scott Ambler's excellent "The Object Primer" --- it ended up being what I needed to fill in the gaps.
Rating:
Summary: A very good book
Review: This book is a comprehensive, authoritative review of what good requirements are. I recommend it highly. However, it's not enough by itself. If you study and learn from Wiegers, you will know *what* good software requirements are and how to know if yours are good or not, but not how to get there. He does talk a lot about elicitation and analysis and so on, but in the end I found that I didn't yet have all the tools I needed. I recommend checking out Scott Ambler's excellent "The Object Primer" --- it ended up being what I needed to fill in the gaps.
Rating: 
Summary: Practical, could benefit from more samples
Review: This book is a practical guide to requirements development. The author draws from his own experience but also distills best practices from industry experts. We used this book to put a formal requirements structure in place which we hope will help to clarify what needs to be built before code development begins. The author points out that requirements errors are approximately 60 to 100 times more expensive to correct in code...I have delivered great software that the customer hated more times than I'd like to admit. If you don't bridge the expectations gap early and deliver what the customer wants it won't matter how beautiful your design and engineering is. One thing I appreciated about the author's approach was that it was not dogmatic and rigid, basically use what works in this model, discard the rest. One small criticism: it would have been nice to see a complete, end to end example of the requirements documents from vision and scope to use cases, to finally the functional spec, complete with suggested formatting conventions. If space was a consideration, then maybe a website could have been used to supplement the text.
Rating:
Summary: Very practical book for a relatively mature organization
Review: This book is full of practical details with checklists and next step suggestions. The beginning is rather steep, but the rest of the book a smooth read. If you are currently working in a more chaotic type of environment and suffer under anarchic management, then this book has no help to get started. It assumes a fairly mature of organization. But then it gives plenty of practical guides for all respects of improvement.
Rating: 
Summary: General Book on Requirements
Review: This book is written as an entry level text on Requirements and how they relate to a project. It does a very good job touching most of the important points of the Requirements Engineering and Management processes. It presents more of a managerial view of the process and does not cover many important points in enough detail to be a good "how to" guide. Most of the book presents simple solutions that are often very complicated in the real world. Case in point :
If you are looking for tips how to "arrest creeping requirements and manage change requests" (back cover) This book will give a good 15 page summary (280-296) of the process (big text) but not enough insight to determine if the process is sufficient, or what can be modified to fit specific scenarios. In the section "Controlling Scope Creep," it mentions "The most effective technique for controlling scope creep is the ability to say no." Very true, but how do you tell Sr. Management (your boss) no? The customer negotiating future payment milestones and functionality? This is good advice, but little more than a flowchart, some recommendations for setting up a Change Control Board and suggested Change Request data items. If the book wanted to aim itself at a more experienced audience, some examples or more complete picture of control mechanisms/processes should be included.
(I pick on the above point, but other books on Requirements only indirectly mention controlling requirement creep) Similar limited treatment is given to complex issues like Use Case generation.If I were VP of Projects, and my Project Managers had limited exposure to the requirements processes, I'd buy them all this book. If I were VP of Engineering, I'd expect anyone with 2+ years of project experience to already have a working understanding of 75% of this book. If you have been on one or more projects and have touched the requirements process before, this book is not likely to present new information. If you are looking for in depth treatment of requirements, here is how I would break down some of the other books in this topic :
Wiegers : Good intro text, poor intermediate/advanced text. Good for managers with limited direct exposure.
Jackson : Very good encyclopedia (tho nothing more than an encyclopedia...) of terms, theories, etc. Aimed at an intermediate-advanced level
Kovitz : Very thorough text covering all aspects of requirements process (focused heavily on software) Better treatment of theory and better (more complete) examples than Wiegers. Intro-Intermediate level.
Robertson & Robertson : Same type of book as Wiegers, but better indexed (I like the "rules of thumb" in the margins). In some areas, I'd rate R&R higher (types of requirements, creating & reviewing the specification) and others Wiegers is better (management of the process, elicitation of requirements) Overall I'd give the nod to R&R
Leffingwell & Widrig : Very good presentation of pitfalls and suggestions for overcoming them. Very biased to the Rational model of a project, but a very good text with (in many cases) unique/interesting approaches. Aimed at all levels (one of it's downfalls) A good "other" or second book to have.
Thayer & Dorfman : I refer to this book the most. Excellent collection of articles. Wish they didn't include the IEEE standards tho (they are good standards, but most(?) engineers have access to them somewhere else) This is a good summary of many different aspects of Requirements Engineering & Management. May be tough as an intro text, but an excellent overall reference.
Rating:
Summary: Very good but a little disagree
Review: This book presents a bright view of software requirements elicitation, development, analysis and management. The consequences of developing requirements in three major steps (business, user and functional requirements) are explained in a way that is easy to read and, at the same time, full of insight.
Nevertheless, we must disagree with the author in a very fundamental point. Wiegers clearly states across the book that requirements must not be polluted with design issues or otherwise biased towards a specific solution, but they must just present the needs. This is a widely assumed point that we do not share. From our viewpoint, developing and writing the requirements for a software system is one of the first modeling activities in the project lifecycle, and modeling is nothing but creating a new model or applying an existing one. In any case, models do not live hidden behind users' daily practice, waiting for us developers to uncover them; on the contrary, they are synthesized as needed, confronted with empirical and intuitive experience and given an ok mark if they can explain, with more or less accuracy and efficiency, the observed reality. The very word "development" in "requirements development" strongly suggests the idea of creating a model. We think that requirements development is fundamentally a modeling activity, and therefore it implies a specific solution. Of course, the chosen solution is specified at a very high degree of abstraction, and many more detailing steps will be needed in order to transform it into the final source code. The SRS in Wiegers's book is a model, and therefore it carries plenty of design issues. What must be avoided is to give them too much detail as to make them inflexible for further modeling. Please have a look at the Metis methodology for more information on our concepts of "modeling" and "design". Despite the conceptual argument we have posed, we have liked the book, and we do recommend it.
Rating:
Summary: Not very good for specification and techniques
Review: This book very good reading about human requirements process. This book clearly LIMITED in that it covers requirements process mostly for non-critical business toy software.
Requirements analysis and specification techniques are not covered in sufficient details, especially old classic methods - for that I would recommend "Software Requirements" by Alan M. Davis. Wiegers completely skipped FORMAL METHODS which makes this book only 50% useful. Hey there is things like Z-language and method! Have you heard about them ?! This book is recommended as reading by SWEBOK and IEEE CSDP program so I have to give it one additional point.
Rating:
Summary: This book should become a classic in requirements writing
Review: This is a great book. It provides clear and concise approaches to solving classic requirements problems. It is not just about software, it can be applied to any system or project. It is not written in software terms, it avoids the software worlds attempt to create new terms for everything. This is not a book by an academic but by someone who has worked in industry and solved problems, just like those that you face. The book includes templates, checklists and guidelines that are easy to use. I also liked the clean style of the book and it is very easy to read. You can apply all or part of the suggested process to your own projects. A more detailed review will appear in the Winter Issue of Insight, the magazine of the International Council on Systems Engineering (INCOSE)
Rating:
Summary: Solid Book
Review: This is a solid book covering the requirements gathering process. My only concern is for shops that try to implement the entire process verbatim. In today's web development world, customer expect progress every 30 days (a la XP Programming). If you force every project down the Use Case, FUnctional Specs, UML diagrams path, then there's no way to get incremental projects out the door that quickly. My suggestion is to customize your process and take the best from this book. Use the majority of processes for large projects, but keep in mind that most projects that don't deliver any incremental value with 30-90 days of start, will either be cancelled or fail.
Rating:
Summary: A very Good Book to understand Software Requirements
Review: This is an excellent book to understand Software Requirements, especially if you are new to Software Development. There are many views on "best practices" in the software industry, but Wieger's views are a good start.
If you starting into Software Product/Project Management, new to Software Development, getting into stuff like writing an SRS or a Marketing Requirements Document, this book will give you a good analytical understanding of the multiple issues that you need to understand and keep in mind.
|
