Software Requirement Patterns (Best Practices) [Englisch] [Taschenbuch]

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.

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.

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.