- Software Requirement Patterns
- A Note Regarding Supplemental Files
- Foreword
- Preface
- I. Setting the Scene
- 1. Synopsis of "Crash Course in Specifying Requirements"
- 2. Synopsis of "The Contents of a Requirements Specification"
- 3. Requirement Pattern Concepts
- 3.1 Introduction to Requirement Patterns
- 3.2 The Anatomy of a Requirement Pattern
- 3.3 Domains
- 3.4 Requirement Pattern Groups
- 3.5 Relationships Between Requirement Patterns
- 4. Using and Producing Requirement Patterns
- II. Requirement Pattern Catalog
- 5. Fundamental Requirement Patterns
- 5.1 Inter-System Interface Requirement Pattern
- Basic Details
- Applicability
- Discussion
- Content
- Template(s)
- Example(s)
- Extra Requirements
- Resilience and Availability Requirements
- Traffic Verification and Recording Requirements
- Upgrade Requirements
- Security Requirements
- Documentation and Third-Party Interface Development Requirements
- Considerations for Development
- Considerations for Testing
- 5.2 Inter-System Interaction Requirement Pattern
- 5.3 Technology Requirement Pattern
- 5.4 Comply-with-Standard Requirement Pattern
- 5.5 Refer-to-Requirements Requirement Pattern
- 5.6 Documentation Requirement Pattern
- 5.1 Inter-System Interface Requirement Pattern
- 6. Information Requirement Patterns
- 7. Data Entity Requirement Patterns
- 8. User Function Requirement Patterns
- 9. Performance Requirement Patterns
- 10. Flexibility Requirement Patterns
- 11. Access Control Requirement Patterns
- 12. Commercial Requirement Patterns
- 5. Fundamental Requirement Patterns
- Glossary
- A. References
- Index
- Copyright
Part II presents a total of 37 requirement patterns for topics that recur repeatedly across all kinds of commercial systems. They are divided into eight domains, as shown here. For readability, this diagram shows only the most significant relationships between patterns in different domains (rather than all of them).
Each of the following eight chapters deals with one of these domains and contains its requirement patterns. The domains are shown in a top-to-bottom ordering so that those domains common to the most types of systems tend to come first, with the rarer or more exotic ones last.
When you're writing a requirements specification, it's useful to have a summary list of all the requirement patterns that might be used for the kind of system you're specifying, to make it easy to find the one you want. Not all patterns are applicable to all kinds of systems, so it can be worthwhile to draw up a list containing only those relevant to your system.
-
No Comment