I actually read this one before the Software Requirements. This book is a good supplement to that one. But I would suggest starting with the other one by Karl first.

This book is a very good addition to any software library. Chapter 15 (Elements of Requirements style) contains some really good and practical advise and is a perfect example of what makes this book great. It just seems to answer some questions that other books don't address and it does it in a very readable format.
It is not as complete as other books on requirements but it does not pretend to be complete. The title says "More about Software Requirements" and this is exactly what you get.
If you do not have another manual that covers the fundamental of software requirements you might want to get "Software Requirements 2nd Edition". Those two books together will give you a nice complete package.

There are hundreds, if not thousands of books on programming that talk about programming languages, programming techniques, programming aids, testing your programming, and more. Yet there is very little written on telling these programmers just what they should be programming.

This book is the exception. It is on how to specify and then manage the software project. It discusses all of the components of developing a set of requirements that will accurately reflect the real needs of the agency that will use the software. It covers all of the new buzz words like 'extreme programming,' 'cases,' 'scenarios,' and so on. Some of these it accepts, some are not reported to be helpful.

The goal of this book is to give the person or group developing the requirements sufficient tools to produce the documents that can later be used to develop the software that everyone agrees is what is needed.

Karl has done it again-written a highly-readable, practical book. Here he exposes common tough questions surrounding requirements development and management including: how long it takes to "do" requirements, estimating, customer involvement, use case vs. stories or scenarios, writing textual requirements and requirements management. Karl cuts to the chase with real-world wisdom for practitioners, giving you the bottom-line advice you need to succeed with your requirements efforts.

It was with high expectation that I picked up Karl Wiegers latest book on requirements. I had read the previous book, Software Requirements 2nd edition, and liked it. However, one of the people quoted on the back of the book had told me that Karl had rethought the role of use cases. Well, I wanted to see that. Also there was this whole subtitle of "Practical Advice". I wanted some of that too.
You see, I teach a requirements seminar and I almost always get asked the "Thorny Issues" Karl lists: How long does requirements take? How much detail is appropriate? What does a good requirement look like? What should be in the specification? My favorite is, "What should marketing put in their document and what should development put in theirs?" My answer always started with, "It depends..." and I wanted better answers.
The answers I got from the book were things like, "There are no fixed answers to the question. Multiple variables contribute to this issue." Or "There is no simple formulaic approach to software specification." Yep, it depends. Well, at least I agree with him.
Lest I sound a bit harsh, there is a lot of Practical Advice in here. There is a good primer on estimating from requirements and acknowledging the cone of uncertainty, the importance of customer input - even on agile projects, the role of specifications, and the need for text and models for a good specification. It is just that for me, I like to think that I already gave that advice to my clients. In fact, there were several sections in the book were I wondered if he had attended my class! (He hasn't.) Perhaps that is why I like his books, I think on the same wavelength.
Oh, about Karl's rethinking of Use Cases. Well, it turns out that Use Cases are not functional requirements but containers of functional requirements. And there are other, sometimes more appropriate, ways to capture functional requirements. Also, functional requirements should be specified outside of the Use Case. However, Karl still really, really likes Use Cases. So, Karl has done not so much of a rethinking of Use Cases but a clearer statement about the multiple variables that go into capturing requirements.
So, should you buy this book? Well if you are ready to accept that requirements are hard, that there is no one best way, that there are some better ways but it depends on where you are and the problem you are trying to solve, then this book will work for you. It has enough to guide you in the right direction. You still will have questions but those need to be worked out in your environment and culture. For those who want a cookie cutter approach to requirements and no ambiguity, it depends...

This book is for anyone interested in software requirements, which should be everyone involved in developing software. This includes those new to the Wieger's approach as well as those who have practiced his approach. One truly learns concepts when one applies concepts. This book shares Wiegers practical advice learned by him and others applying his concepts. It was a natural this book should be written and finally it is here. Read, learn and enjoy.