- Series: Developer Best Practices
- Paperback: 384 pages
- Publisher: Microsoft Press; 1 edition (June 23, 2007)
- Language: English
- ISBN-10: 0735623988
- ISBN-13: 978-0735623989
- Product Dimensions: 7.3 x 1 x 9 inches
- Shipping Weight: 1.7 pounds (View shipping rates and policies)
- Average Customer Review: 7 customer reviews
- Amazon Best Sellers Rank: #1,371,120 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Software Requirement Patterns (Developer Best Practices) 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
All Books, All the Time
Read author interviews, book reviews, editors picks, and more at the Amazon Book Review. Read it now
Frequently bought together
Customers who bought this item also bought
From the Publisher
Key Book Benefits:
-Provides a reference to solutions that have worked in the past, with guidance about how to modify patterns to fit individual needs
-Features an emphasis on determining what a software system needs to do--the necessary precursor to development
About the Author
Stephen J. Withall has been developing and specifying software systems for more than 26 years in a variety of roles: programmer, analyst/programmer, team leader, systems analyst, business analyst, project manager, systems architect, and chief technical officer. He has worked in diverse environments in companies big and small, in 17 countries across four continents. He has used object-oriented design approaches and technology for more than 16 years, and actively maintains his hands-on software development skills.
Top customer reviews
Beyond requirements gathering, the patterns in the book can be used by developers to help clarify requirements and ensure that they are developing the right thing.
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.
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.