Specification Requirements Document Template

CS 325, Software Engineering Concepts, Spring 2000

This template for a software requirements document (SRD) is adopted from the one used by the European Space Agency, which, in turn, was adopted from the 1994 edition of the IEEE Software Engineering Standards Collection, IEEE Press.

You need not use this template for your specification requirements document, but, whatever format you use, you should make sure your SRD covers enough of the details listed here or in Section 3.3 of your text to serve as a reasonable guide to further development. Details below marked with an asterisk (*) are less important than details not marked with an asterisk; your work should emphasize the unmarked details in preference to the marked details.

1. Introduction

   1. Purpose - define the purpose of this SRD and specify intended readership.

   2. Scope - identify the software products to be produced by name; explain what the proposed software will do (and not do, if necessary); and describe the relevant benefits, objectives and goals as precisely as possible.

   3. * Definitions, Acronyms, and Abbreviations - provide definitions of all terms, acronyms and abbreviations needed for the SRD.

   4. Overview - describe what the rest of the SRD contains and explain how the SRD is organized.

2. General Description - should describe the general factors that affect the product and requirements. Do not state specific requirements, but make those requirements easier to understand.

   1. Function and purpose - discuss the purpose of the product.

   2. * Environmental considerations - summarize the physical environment of the system, the hardware environment of the system, the operating environment of the system, the hardware environment of the development system, and the operating environment of the development system.

   3. Relation to other systems - describe the system's relationship to other systems (e.g., is it an independent system, a subsystem of a larger system, replacing an existing system).

   4. General constraints - limits to the system developers' options.

   5. * Model description - a top-down description of the logical model.

3. Specific Requirements - Instructions to the software designer.

   1. Functional requirements - defines the system's input-output transformations.

   2. * Performance requirements - specifies numerical values for measurable variables used to define the system.

   3. Interface requirements - specifies the hardware, software, and communications interfaces the system must interact or communicate with.

   4. Operational requirements - specifies how the system will run.

   5. Resource requirements - specifies the upper limits on physical resources such as processing power, main memory, disk space, etc.

   6. Verification requirements - specifies system features that facilitate system verification; indicates how the system is to be verified.

   7. Acceptance testing requirements - specifies what the client considers as acceptable system function.

   8. Documentation requirements - states system-specific requirements for documentation.

   9. * Security requirements - specifies the requirements for securing the system against threats to confidentiality, integrity, and availability.

   10. Portability requirements - specifies how easy it should be to move the system from one environment to another.

   11. * Quality requirements - specifies the attributes of the software that make it fit for its purpose.

   12. * Reliability requirements - specifies the ability of the system to perform its required functions under stated conditions for a specified period of time.

   13. Maintainability requirements - specifies the ease with which a software system can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment.

   14. * Safety requirements - specifies any requirements to reduce the possibility of damage that can follow from system failure.

Here are some things to keep in mind when creating the requirements specification:

• Everything in the requirements specification should be in terms of the problem; there should be nothing about the system design or implementation. The only way to break this rule is if the customer has specific requirements related to system design or implementation (for example, the system must run on special-purpose hardware).

• Do not name the system; if you name the system there's a tendency to talk about the system and not the problem. If you've named the system already, go through the requirements specification and replace all occurrences of the system name with "the problem" and rewrite the effected parts of the specification.

• Adjectives (the system must have a friendly user interface) and adverbs (the system must quickly respond to queries) should be avoided because they lead to imprecise specifications. Try to eliminate as many adjectives and adverbs as possible from the specification, and make sure all surviving adjectives and adverbs cannot be replaced by more specific sentences (the system under 20% load must respond to a query within five seconds; the user should be able to request help information on any feature visible in the interface by placing the mouse cursor over the feature and pressing the help button).

• It's useful to have a checklist of properties to help review and validate a requirements specification.

• An example SRD describing a project to modify CERN's computerized Maintenance Management System. The format for this SRD is an expanded version of the template given above. This SRD is interesting because it's essentially an index into a huge number of other requirements specs. It is not, however, on its own a good SRD for a number of reasons. First, while it is highly organized, it is not well organized; for example, try figuring out how objects are used used in the system. Second, the specifications themselves are vague and ill-defined; for example "The system shall have some of its functions externally accessible to other applications." Which functions? Accessible how? To which applications? Under what conditions? In general, this SRD concentrates too much on the system to solve the problem and not enough on the problem itself.

This page last modified on 28 January 2000.