1. Introduction

The document begins with an introductory description of the desired system. Except as noted below, the system is described 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.

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:

1. system end users
2. paying customers
3. project managers
4. domain experts
5. system analysts
6. system developers

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:

1. What computer-based support is in use prior to installation of the new system?
2. Does the new system need to interface with existing system(s) or are the existing system(s) to be replaced entirely?

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:

1. What is good about the related system, i.e., what features it has that should be included in the system being proposed here.
2. What is bad about the related system, i.e., what features should not be included in the proposed system, or what features should be included but done in a different or better way.
3. What is missing, i.e., what new features should be included in the proposed system that are not found in the related system
4. Any other noteworthy features.

Evaluation of a related system.

...

1.5.n. Related System N

Ibid.

1.5.o. Feature Comparison Matrix (Optional)

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, 2.2.3.4.5).

...

2.n. System-Specific Requirements

Ibid.

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:

1. performance
   1. time
   2. space
2. operational environment
   1. hardware platform
   2. software platform
   3. external software interoperability
3. standards conformance
4. general characteristics
   1. reliability
   2. robustness
   3. accuracy of data
   4. correctness
   5. security
   6. privacy
   7. safety
   8. portability
   9. modifiability and extensibility
   10. simplicity versus power

Non-functional process requirements include some or all of the following:

1. development time
2. development cost
3. software life cycle constraints
4. system delivery
   1. extent of deliverables
   2. deliverable formats
5. installation
   1. developer access to installed environment
   2. phase-in procedures to replace existing system
6. standards conformance
7. reporting
8. marketing
   1. pricing
   2. target customer base
9. contractual requirements and other legal issues

Non-functional personnel requirements include some or all of the following:

1. for developers:
   1. credentials
   2. applicable licensing, certification
2. for users:
   1. skill levels
   2. special accessibility needs
   3. training

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:

1. an executive summary of the major objects and operations defined in the formal specification;
2. data and operation dictionaries;
3. high-level diagrams, such as UML and dataflow.

The rationale discusses important development decisions that were made and why. The discussion addresses development alternatives that we considered and why they were rejected.

6. Acceptance Tests

Acceptance tests are high-level tests that the customer uses to determine if the system is acceptable. Acceptance tests are organized into subsections to an appropriate depth (e.g. 6.2.1). Acceptance tests should consider both functional and non-functional requirements, however, there does not necessarily need to be one acceptance test for every functional and non-functional requirement.

Appendix A: User Interview Transcripts (Optional)

Recorded transcripts of interviews conducted with users.

Appendix B: Help Content (Optional)

Specific content and wording for online help documentation.

Appendix C: ...

...

Additional appendices are provided as necessary, such as detailed data formats, glossary of domain-specific technical terms, details of environment-specific or platform-specific requirements.