Software Requirements, Second Edition (Paperback)

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.

If you haven't used techniques like this one before, it is definitely a good idea to pick up a solid book like this one on the best practices in requirements engineering. There are several good books in the market on the topic of software requirements and this is one of the best ones out there.

I found three other books that complement this one - Requirements Engineering by Kotonya and Sommerville (used more as a textbook), Managing Software Requirements by Leffingwell and Widrig (part of the Object Technology Series), and Effective Requirements Practices by Ralph R. Young (comes with a CD-ROM).

If you are a project manager, business analyst or anyone that has a lot to lose because of bad requirements, you will benefit tremendously from this current book being reviewed. The book is divided into three parts - What and Why, Development, and Management of Software Requirements. The part names are self explanatory. This book is very readable and is full of best practices that stand true to their name!

The unique things about this book - in chapter 2, the author outlines the Requirements Bill of Rights for Software Customers and the Requirements Bill of Responsibilities for Software Customers. When I first read this, I felt like every customer has to read this before attempting a software project. Chapter 10 has an excellent description of different diagrams useful in requirements documentation - DFD (data flow diagram), ERD (entity-relationship diagram), STD (state transition diagram), dialog map, and class diagrams. I think all books on software requirements should ideally have some variation of these topics.

Important topics like traceability are given an excellent treatment in this book but the only thing lacking is how to manage requirements in software processes involving iterations (the mainstay of the Rational Unified Process and other newer software development methodologies). There are only 13 pages devoted to this topic and even then it is indirect - Chapter 12: Risk Reduction Through Prototyping.

Otherwise, I have no complaints about this book and I believe that it is a basic to intermediate in level (definitely not an advanced book). Overall, I believe it indeed captures the best practices in the field of requirements engineering. It is also a good price, so enjoy!

He covers the issues involved in gathering requirements and keeping them up to date, often offering multiple ways to resolve issues. Wiegers, unlike many academic oriented books, fully acknowledges the political and cultural difficulties that arise when trying to institute a requirements program. Much of his advice is practical and he gives good pointers on the highst ROI practices, so you can inject a little at a time, rather than trying to change culture wholesale.

I'd give a 4.5 out of 5 if I could, due only to the "Next Steps" sections at the end of each chapter. The "Next Steps" are supposedly be small steps you can take to start using the advice Wiegers offers. Unfortunately, most of the steps start with "Take a page/chapter from your current requirements document...." I've worked at few companies that even have a requirements document, so I'm not sure how useful the "Next Steps" really are.

But, that complaint aside, this book is the best combination of reference information for techniques and advice on how to use them on the job.