10 of 11 people found the following review helpful:
5.0 out of 5 stars
An important but often dull subject made accessible and interesting, October 8, 2007
This review is from: Software Requirement Patterns (Best Practices) (Paperback)
The purpose of this book is to help you decide and define what a new software system needs to do and to suggest what extra features to add to make it a very good system. It saves you effort and enables you to be more precise, by providing detailed guidance on how to specify individual requirements.
Requirement patterns are encapsulated expertise, conveniently prepackaged for reuse. The book contains 37 requirement patterns, each of which describes an approach to tackling a particular type of situation that comes up repeatedly in all kinds of systems, but focusing on commercial business software. Only a fraction of any system is specific to its business area; the bulk occurs over and over again no matter what your system is for. These patterns cover more than half of all requirements in some systems, and even more if you add the extra requirements the patterns suggest. Each pattern conveys not only the basic information that a requirement needs to convey, it also offers guidance on supplemental information that you need in your requirements in order to make them complete, comprehensible, and properly cross-referenced. This book contains over 400 example requirements, many of which are suitable for applying unchanged to any system and others that are a useful starting point for a requirement to suit the reader's needs. These examples are the heart of the book. Currently, the product description does not show the table of contents, so I do that next:
Part I: Setting the Scene
Chapter 1. Synopsis of "Crash Course in Specifying Requirements"
Section 1.1. What Are Requirements?
Section 1.2. Where Do Requirements Fit in the Grand Scheme?
Section 1.3. A Few General Principles
Section 1.4. A Traditional Requirements Process
Section 1.5. Agile Requirements Processes
Chapter 2. Synopsis of "The Contents of a Requirements Specification"
Section 2.1. Introduction Section
Section 2.2. Context Section
Section 2.3. Functional Area Sections
Section 2.4. Major Nonfunctional Capabilities Section
Chapter 3. Requirement Pattern Concepts
Section 3.1. Introduction to Requirement Patterns
Section 3.2. The Anatomy of a Requirement Pattern
Section 3.3. Domains
Section 3.4. Requirement Pattern Groups
Section 3.5. Relationships Between Requirement Patterns
Chapter 4. Using and Producing Requirement Patterns
Section 4.1. When and How to Use Requirement Patterns
Section 4.2. Tailoring Requirement Patterns
Section 4.3. Writing New Requirement Patterns
Part II: Requirement Pattern Catalog
Chapter 5. Fundamental Requirement Patterns
Section 5.1. Inter-System Interface Requirement Pattern
Section 5.2. Inter-System Interaction Requirement Pattern
Section 5.3. Technology Requirement Pattern
Section 5.4. Comply-with-Standard Requirement Pattern
Section 5.5. Refer-to-Requirements Requirement Pattern
Section 5.6. Documentation Requirement Pattern
Chapter 6. Information Requirement Patterns
Section 6.1. Data Type Requirement Pattern
Section 6.2. Data Structure Requirement Pattern
Section 6.3. ID Requirement Pattern
Section 6.4. Calculation Formula Requirement Pattern
Section 6.5. Data Longevity Requirement Pattern
Section 6.6. Data Archiving Requirement Pattern
Chapter 7. Data Entity Requirement Patterns
Section 7.1. Living Entity Requirement Pattern
Section 7.2. Transaction Requirement Pattern
Section 7.3. Configuration Requirement Pattern
Section 7.4. Chronicle Requirement Pattern
Section 7.5. Information Storage Infrastructure
Chapter 8. User Function Requirement Patterns
Section 8.1. Inquiry Requirement Pattern
Section 8.2. Report Requirement Pattern
Section 8.3. Accessibility Requirement Pattern
Section 8.4. User Interface Infrastructure
Section 8.5. Reporting Infrastructure
Chapter 9. Performance Requirement Patterns
Section 9.1. Response Time Requirement Pattern
Section 9.2. Throughput Requirement Pattern
Section 9.3. Dynamic Capacity Requirement Pattern
Section 9.4. Static Capacity Requirement Pattern
Section 9.5. Availability Requirement Pattern
Chapter 10. Flexibility Requirement Patterns
Section 10.1. Scalability Requirement Pattern
Section 10.2. Extendability Requirement Pattern
Section 10.3. Unparochialness Requirement Pattern
Section 10.4. Multiness Requirement Pattern
Section 10.5. Multi-Lingual Requirement Pattern
Section 10.6. Installability Requirement Pattern
Chapter 11. Access Control Requirement Patterns
Section 11.1. User Registration Requirement Pattern
Section 11.2. User Authentication Requirement Pattern
Section 11.3. User Authorization Requirement Patterns
Section 11.4. Specific Authorization Requirement Pattern
Section 11.5. Configurable Authorization Requirement Pattern
Section 11.6. Approval Requirement Pattern
Chapter 12. Commercial Requirement Patterns
Section 12.1. Multi-Organization Unit Requirement Pattern
Section 12.2. Fee/Tax Requirement Pattern
This book is very good at taking a dull subject - software requirements and their specification - and making it interesting and accessible. Highly recommended.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
20 of 25 people found the following review helpful:
3.0 out of 5 stars
Many examples of better requirements, October 18, 2007
This review is from: Software Requirement Patterns (Best Practices) (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
