
Average Reviews:

(More customer reviews)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...
Click Here to see more reviews about: More About Software Requirements: Thorny Issues and Practical Advice
Have you ever delivered software that satisfied all of the project specifications, but failed to meet any of the customers' expectations? Without formal, verifiable requirements--and a system for managing them--the result is often a gap between what developers think they're supposed to build and what customers think they're going to get. Too often, lessons about software requirements engineering processes are formal or academic, and not of value to real-world, professional development teams. In MORE ABOUT SOFTWARE REQUIREMENTS: THORNY ISSUES AND PRACTICAL ADVICE, the author of Software Requirements, Second Edition, describes even more practical techniques for gathering and managing the software requirements that help you meet project specifications and customer expectations. A leading speaker and consultant in the field of requirements engineering, Karl Wiegers takes questions raised by other professional software developers and analysts as a basis for the practical solutions and best practices offered in this guide. Succinct and immediately useful, this book is a must-have for developers and analysts.
Buy cheap More About Software Requirements: Thorny Issues and Practical Advice now.

I'm inclined to agree with most of Kurt's positions. The ultimate objective of requirements is to communicate (that means disseminate, verify comprehension, rinse and repeat). Communicating with different audiences frequently requires different approaches, and a lot of times you need to adapt your approach to what resonates.
ReplyDeleteI also really really like use cases as the foundation of design, construction and verification. As the Bard said, a rose is a rose. Whether you think of them as behavioral requirements or containers for behavioral requirements, they are the best thing going for being able to communicate and verify what your project is supposed to do.
Ron
www.casecomplete.com