Product Description
Learn proven, real-world techniques for specifying software requirements with this practical reference. It details 30 requirement “patterns” offering realistic examples for situation-specific guidance for building effective software requirements. Each pattern explains what a requirement needs to convey, offers potential questions to ask, points out potential pitfalls, suggests extra requirements, and other advice. This book also provides guidance on how … More >>
#1 by Diana Q. FRANCO on March 21, 2010 - 7:46 pm
It’s ok if you are starting to have the concepts and everything in a general level. If you are looking for some specifics guides or examples to apply in the reality… mmmhhh… I don’t think this book is the best option to have that. And… it’s expensive. My best advice… don’t buy it.
Rating: 2 / 5
#2 by M. J Malley on March 21, 2010 - 9:34 pm
This book provides a great “kick start” for specifying large system requirements. The patterns provide food for thought along with a very useful standard approach to specifying requirements. It should be in every system analyst’s toolkit.
Rating: 5 / 5
#3 by Rodrigo Silveira on March 21, 2010 - 10:20 pm
I run into this book by pure accident while searching for something else. I could not resist the idea of reading material that offered a discipline way to group software requirements into patterns. What I got was a lot more than that. The author offers a rich and solid argument for his propaosl to approach requirements using a taxonomy of patterns, dishes out his taxonomy spiced up with instructive commentary covering not only requirements but construction, quality, and documentation. I recommend this material to to anyone who cares about the software engineering craft.
Rating: 5 / 5
#4 by Earl Beede on March 21, 2010 - 10:59 pm
Stephen Withall should be congratulated for slugging through about 300 pages of examples of requirements. Many of them are quite good. For that alone, I recommend the book for all those who want to know what a fairly well written requirement might look like. If you want to know what a very well written requirement looks like, then you should go attempt to read Tom Gilb’s book Competitive Engineering. I say attempt because Gilb is not an easy read.
Withall is honest from the beginning in that this is a book of examples using a pattern language. I don’t have much enthusiasm for pattern languages, they seem to confuse me, but that is probably a personal problem. There is little to explain what requirements are or how to get them. This book focus is on writing them down. He does have a really brief (very, very brief) intro to requirements with more promised on the web. I didn’t read the web stuff.
What I did learn, and colored my whole perception of the book, is that the working definition of requirement is focused flat on functional requirements. Yes, there is a nod to not functional requirements but they get a short shift throughout the book. Frankly, functional requirements are not that interesting. Yes, they are needed but they are typically really easy to get. It is the not functional requirements that get teams into trouble. It isn’t that the software doesn’t do what you want, it just does it in a way that you hate.
This is clear in the section on User Function requirements where (even if he told us earlier to specify the problem, not the solution) the examples are full of solution. “The system will refresh itself” and “Whenever a sound is played for the purpose of alerting the user, a visual cue shall also be invoked”. Why I ask you? That is solution talk.
Now to be a bit more fair, problem and solution is a relative area so, without a clear description of the context, I can’t say what those two examples really are, but my money is on solution. A problem UI requirement for the above is more like, “The user will correctly recognize an alert within X seconds 95% of the time” or something like that.
Bottom line, if you want to have a book of lots of examples, not to bad. In those examples are some good questions. But there is much more to do than to write them down.
Rating: 3 / 5
#5 by Karl E. Wiegers on March 21, 2010 - 11:28 pm
Stephen Withall’s “Software Requirement Patterns” can help any analyst write better requirements. The patterns Steve presents can help analysts ask the right questions to properly understand and specify requirements of many types at an appropriate level of detail. This book communicates a wealth of wisdom and insight for writing stellar requirements. The patterns point out the value of using a consistent style when exploring and documenting requirements. Even if you don’t apply the patterns rigorously, Steve provides hundreds of practical tips for specifying better requirements.
This book does not address the entire requirements development and management life cycle. You aren’t going to sit down and read through the whole book, either. Instead, it’s a valuable reference when you have questions about how best to explore and specify certain types of requirements. It will help you discover essential information that you wouldn’t otherwise think to ask about. I used the “Report Requirement Pattern” this morning (literally) to get some new ideas about effectively specifying requirements for reports.
This is the most comprehensive resource I’ve seen on thinking carefully through the information associated with effective functional, data, and quality requirements of many different kinds. I highly recommend it.
Rating: 5 / 5