Software Requirement Patterns by Stephen Withall

Software Requirement Patterns by Stephen Withall
My rating: 4 of 5 stars

A very nice book for all software business analysts, product owners, developers and architects. It provides very good guidelines on how different types of requirements should be specified or captured what aspects need to be considered when specifying or capturing the requirements.

The list of patterns with a brief explanation where not clear are as under:

Fundamental Requirement Patterns
a) Inter-System Interface Requirement Pattern - This pattern covers how to capture the details of data to be exchanged between various applications in that will be part of the system.
b) Inter-System Interaction Requirement Pattern - This pattern covers how to capture the details of how data will be passed between the various applications that will part of the system.
c) Technology Requirement Pattern - If there is a requirement of usage of specific technologies this pattern tells how these requirements of technology can be specified.
d) Comply-with-standard Requirement Pattern - This pattern shows how one should specify the regulartory requirements. It may not be sufficient to say adhere to this standards or guidelines. It will be necessary to be specific in many scenarions.
e) Refer-to-Requirements Requirement Pattern - This is reference to other requirements gathered previously.
f) Documentation Requirement Pattern - This specifies the kinds of documenation that need to be prepared as part of the development process.
Information Requirement Patterns
a) Data Type Requirement Pattern - At a fundamental level this indicates what kind of data types need to be support. This becomes important as once can specify how amount or date time fields should be captured, stored and displayed in the application.
b) Data Structure Requirement Pattern - This specifies the functional structures that need to be created in the system using the ID pattern and the Data Type Requirement.
c) ID Requirement Pattern - This pattern indicates the requirements of creation, maintenance and format of ID fields in the system.
d) Calculation Formula Requirement Pattern - This pattern covers on how to specify requirements of various formulae to be used in the application.
e) Data Longevity Requirement Pattern - This pattern covers how the requirements of retention of data in the system needs to be specified.
f) Data Archiving Requirement Pattern - This pattern covers how the requirements how the data in the system needs to be archived is to be specified.
Data Entity Requirements Pattern
a) Living Entity Requirement Pattern - This patterns covers how details of entities which have a life in the system need to be specified. Some examples are customers, accounts etc.
b) Transaction Requirement Pattern - This pattern covers how requirements should be specified for events attached to one or more Living Entity in the system.
c) Configuration Requirement Pattern - This pattern covers how requirements for the different business configuration parameters should be specified.
d) Chronicle Requirement Pattern - This patterns covers how requirements for tracking of changes to the different Living Entity or Transaction should be captured and stored.
e) Information Storage Infrastructure - This pattern specifies
User Function Requirement Patterns
a) Inquiry Requirement Pattern - This pattern gives details of how to specify requirements for inquiries to be made in the system. These are interactive inquiries as opposed to static report requirements which is the next pattern.
b) Report Requirement Pattern - This specifies the reports that need to be generated in the system along with the filter criteria, export requirement, and synchronous and asynchronous requirement.
c) Accessibility Requirement Pattern - This could be regulatory requirement or something specific to the type of users or requirements due to the environmental conditions.
d) User Interface Infrastructure - This pattern covers how to specify the infrastructures on which the User Interface should be supported.
e) Reporting Infrastructure - How configurable reports need to be and how they need to be generated and how they need to be delivered.
Performance Requirement Patterns
a) Response Time Requirement Pattern
b) Throughput Requirement Pattern
c) Dynamic Capacity Requirement Pattern - This pattern covers specification of dynamic load requirement like increased number of users, transactions etc.
d) Static Capacity Requirement Pattern - This pattern covers the specification of static capacity requirements such as storage space.
e) Availability Requirement Pattern - This pattern covers how the availability of the system should be specified and what factors should be considered when specifying this.
Flexibility Requirement Patterns
a) Scalability Requirement Pattern - This pattern covers specifying the requirements of how much data/numbers that needs to be supported by the system.
b) Extendability Requirement Pattern - This pattern covers specifying the requirements of how extendible the system must be to support different ways of doing something particular. E.g. adding different types of payment channels or sending notification to user etc.
c) Unparochialness Requirement Pattern - The system should be able to support working with multiple currencies, or with a flavour local to the geographic location or department of the organization. This applies when the application is installed at different locations.
d) Multiness Requirement Pattern - This is similar to unparochialness, but applicable when all of this has to be achieved in a single installation of the application. It may also mean the way in which the ID values need to be allocated in the system.
e) Multi-Lingual Requirement Pattern -
f) Installability Requirement Pattern - This pattern covers how the installation requirements of the application should be specified if it is necessary.
Access Control Requirement
a) User Registration Requirement Pattern - This pattern addresses how a user should be made known to the system.
b) User Authentication Requirement Pattern - This pattern addresses how a user should be validated by the system.
c) User Authorization Requirement Pattern - This pattern addresses how the privileges of the users in the system be controlled.
d) Specific Authorization Requirement Pattern - This pattern addresses how generic requirements like denial-by-default rule etc. should be specified.
e) Configurable Authorization Requirement Pattern - This pattern addresses how to specify requirements when it is required to let the administrators or other authorized personnel to manage this.
f) Approval Requirement Pattern - This pattern addresses how to specify any approval process required in the system.
Commercial Requirement Patterns
a) Multi-Organization Unit Requirement Pattern - This pattern addresses how requirements of Organizations with Multiple units needs to be specified.
b) Fee/Tax Requirement Pattern - This pattern specifies the fee/tax requirement that the system must calculate, report on, or levy. This requirement pattern can also be used (with only slight variations) to specify a discount on an amount a party is charged.

View all my reviews