More About Software Requirements: Thorny Issues and Practical Advice [Paperback]

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 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.

Karl Wiegers is the person I recommend all my employees to read. This book is even better than 'Software Requirements, 2nd Edition' by Karl. He gives practical advises together with theory and important references. This book could be used as a tutorial for requirements engineers. One of the best books in this subject area.

› Go to Amazon.com to see all 16 reviews  4.7 out of 5 stars