The document begins with an introductory description of the desired software system. This introduction provides a high-level executive summary of the system overall.
Except as noted below, the requirements are presented in present tense, third person, active voice. The purpose of using present tense is to render this document historically relevant throughout the lifetime of the system. That is, the requirements specification is a permanent part of the system documentation, before the system is implemented, during implementation, and afterward. In subsections 1.4 and 1.5 only, the system is referred to in future tense in order to distinguish between the state of operations before and after system installation.
The purpose of third person is to avoid inconsistent references to actors involved in the requirements, particularly in the functional requirements scenarios of Section 2. The user is referred to as "the user", or some other third-person identifier. The software system referred to as "the system", or some other third-person identifier. In this way, it is precisely clear what actions the human user performs and what actions the software system performs. As appropriate, users can be referred to with context-specific persona, such as "registered user", "guest user", and "administrator".
The purpose of active voice is to reinforce the clarity of the actors portrayed
in the scenarios. For example, we say "When the user selects X ..." rather
than "After X has been selected ...".
1.1. Problem Statement
The problem statement is a succinct presentation of the specific problem(s) to
be solved and the needs to be met by the system.
1.2. System Personnel
The description of system personnel defines all of the people involved with the system and its development. Personnel categories include some or all of the following:
The operational setting is the environment in which the system is to be used. The discussion includes how operations are conducted in the environment before and after the system is installed. The following questions are addressed in the discussion of the operational setting:
The impact analysis assesses the impacts of the system within its operational
setting. Both positive impacts (e.g., increased productivity, higher product
sales) as well as negative impacts (e.g., job displacement, potential negative
legal impacts) are addressed.
1.5. Related Systems
Related systems are those computer systems in use elsewhere that provide functionality similar or related to the functionality of the system being specified here. Both commercially available and public domain systems are considered and the following issues are addressed:
Evaluation of a related system.
1.5.n. Related System N
1.5.o. Feature Comparison Matrix
1.6. Document Conventions (Optional in CSC 308)
This subsection is an overview of any noteworthy conventions used in the
requirements specification document. If any of the conventions are documented
in detail, the details can be included in appendices or cited in appropriate
2. Functional Requirements
Functional requirements define the specific functions that the software system
performs, along with the data operated on by the functions. The functional
requirements are presented in scenarios that depict an operational system from
the perspective of its end users. Included are one or more examples of all
system features and an enumeration of all the specific requirements associated
with these features.
2.1. User Interface Overview
The user interface overview presents the initial user screen with a brief
description of the top-level functionality. For example, if the system uses a
command menu as the top-level interface, each of the menus is exposed and each
menu item is briefly described.
2.2. System-Specific Requirements
Specific functional requirements for the system are presented in user-oriented scenarios. Scenarios are organized into subsections to an appropriate depth (e.g., 2.2.1, 184.108.40.206.5).
2.n. System-Specific Requirements
3. Non-Functional Requirements
Non-functional requirements address aspects of the system other than the
specific functions it performs. These aspects include system performance,
costs, and such general system characteristics as reliability, security, and
portability. The non-functional requirements also address aspects of the
system development process and operational personnel.
3.1. System-Related Non-Functional Requirements
Non-functional system requirements include some or all of the following:
Non-functional process requirements include some or all of the following:
Non-functional personnel requirements include some or all of the following:
The developer overview is an executive summary oriented towards the system design and implementation team. Included are high-level descriptions of the major objects and operations specified in Section 5 below, specifically:
The formal specification defines all objects and operations of the system,
including formal specification of all quantifiable requirements.
6. Requirements Specification Rationale
The rationale discusses important development decisions that were made and why. The discussion addresses development alternatives that were considered and why they were rejected.
Written transcripts of interviews conducted with clients. These can be extracted from the minutes of customer meetings.
Specific content and wording for online help documentation.
Additional appendices are provided as necessary, such as detailed data formats,
glossary of domain-specific technical terms, details of environment-specific or