System Response Document (SRD)

Introduction

This document specifies the content and scope of the System Response Document (SRD). It is one of the most important documents within the project since it is in effect the contract between the supplier and the Project Board. The purpose of the document is twofold:

The SRD is the highest level technical expression of the required functionality of the system. The SRD is a response to the User Requirements Document (URD), and addresses all URD requirements at the top design level. The SRD must contain a compliance matrix, mapped to the URD, demonstrating that all URD requirements have been considered. All documentation at a lower level than the SRD must, in turn, contain a compliance matrix mapped to the SRD. This need to be able to trace compliance of requirements implies that requirements carry a unique numeric reference. Requirements must also be given priorities, and it is recommended that they be labelled ‘mandatory’, ‘preferred’ or ‘optional’.

The SRD should express the system designer’s view of the overall system design, and the emphasis must be on data structures and content. Good system design is driven by data requirements, and the design itself will be simplest, most coherent, most reliable and most maintainable, if the data structures are logical, and if the design revolves around them.

Other documents which may be derived from a SRD, according to project size and complexity, include:

The SRD shall contain the following sections as a minimum.

Specification

Assumptions and Prerequisites

Describes assumptions, and prerequisite conditions, for the overall system design. Assumptions are intended to limit the design of the system, so that no attempt is made to ‘over-design’ at lower levels and cater for situations, which are extremely unlikely to, or cannot, occur. Any over-design of a system has very significant impacts on cost, schedule, quality and maintainability, since it implies increased, unnecessary complexity. Prerequisites are mandatory conditions, which must exist for the system design to be viable and valid.

Functional Description and Performance Requirements

Describes the individual functions, which the system must support, from the designer’s perspective at the highest technical level. The functions must be detailed, discrete and separate, and as non-interdependent as possible. System performance requirements of subsystems comprising the system (e.g. throughput, response times, or implementation language) are specified here. This section must address every URD requirement, and must explain either how each of them is to be implemented, or why the URD requirement is not feasible. It is not mandatory for the SRD to provide the complete functionality required in the URD, since users may have requested mutually exclusive, very expensive, very difficult, or even impossible requirements, which may damage or invalidate the business case for the system. This section identifies and summarises the subsystems, required to provide the functionality, and this decomposition of the system into subsystems must be based upon, and reflect, the nature and handling of the data.

Resources and Schedule Requirements

Specifies the maximum resources that the development and operation of the system may consume, in terms of those resources under the designer’s control. These might include, for example, maximum memory and disk occupancy, communications bandwidth requirements, and processor speed.

Data Requirements

This section is the heart of the SRD, since data structures are the essence of good design, and specifies the content, layout, handling and storage of global system data structures. Data local to subsystems, as opposed to system data, is not included here, but rather in the Detailed Design Documents (DDD) for the subsystems themselves. The system data content requirements are determined by analysis of the set of URD requirements to be satisfied, and the structures specified must be logical, efficient, and extensible. Appropriate access methods for the data must be identified (e.g. database tools). Data structures must be consistent and relational (i.e. no data item may appear more than once in the structure; pointers to other data areas must be used instead).

Maximum volumes of data must be shown here, both in logical form (e.g. records) and in storage required.

Interface Requirements

This section specifies interfaces to other systems. At SRD level, this means the interfaces that the overall system must handle, including user terminals and electronic interfaces to other computer systems (e.g. protocols, e-mails, etc.), and how these interfaces are to be achieved. A consistent, unified mechanism must be defined, for subsystems to access system data, and this mechanism must guarantee appropriate data access and integrity. This means that no system data record may be written from more than one module. Any data field must have a unique ’writer’, but may have multiple ‘readers’.

The interfaces between functional subsystems are also defined here. This means that inter-subsystem communication methods, both via messaging and via global data must be described.

Testing Requirements

This section specifies the requirements placed on system testing, including information on traceability of tests back to requirements. Also included are requirements on testing under stress conditions (maximum loading, or even loading exceeding maximum, as defined in previous sections of this document) and regression testing. Which means re-testing to ensure that no unexpected effects have been introduced as a result of a modification or enhancement, both in the modified modules and in the rest of the system (since no system is absolutely modular, and some cross-correlation always exists between components).

Testing requirements at SRD level specify how tests may be defined to ensure correct handling of global data, and also a structured, unified testing philosophy for subsystems. Testing procedures must be described, to ensure that tests are designed to test all SRD functional requirements, and also how test results may be collected, captured and stored, such that the success or failure of tests is visible, repeatable and retrievable, along with the test script or procedure.