The Overview section consists of five subsections and provides for an executive level overview.
A concise description of the objectives of the document.
A brief description of the scope of the requirements specification.
Identify sources of information used to develop this document, such as IEEE or project documentation.
A list of issues or problems which are known to be outstanding with this revision.
This section consists of four subsections of brief descriptions that provide understanding of the context for the proposed effort.
Relevant information about the organization, mission, locations, numbers, and type of personnel, and relationships or interfaces with other organizations and entities, as they relate to the system task.
A high-level picture of the processes and procedures by which information is currently handled by the owner/user in the area being automated or modified. The timing of critical processes should also be discussed, e.g., if there are any processes dependent on other processes being previously completed, these dependencies should be noted. For example, if time sheets are due on the 15th of the month, and there is an audit step to ensure all time sheets have been keyed prior to running a system job that cuts the checks, the audit step must be run after the 15th and prior to the system job being run.
A brief introduction to the component or system that is covered by the specification. This section should be brief, since it is included only to help the reader quickly understand what is being specified.
A context diagram should be included to assist in positioning the proposed component or system.
This subsection portrays any problems experienced by the owner/user with the current process.
This section consists of twelve subsections. This section states the functions required of the software in quantitative and qualitative terms, and what the system must do to completely fulfill the owner/user’s expectations. The requirements should answer the following questions:
Each paragraph (or group of paragraphs) should contain a reference identifying the source of the requirement. Each requirement (sentence or paragraph) should be numbered, using a numbering scheme that allows for inserting additional requirements later, e.g., FUNC-01, or A-1.1, etc. Only one requirement should be defined per numbered item.
Each requirement should be classified as one of the following:
Provide a clear list of the expectations of a new system or function(s), both in terms of what must be improved and what must be retained from the current processes. All detailed requirements should address one or more of these goals.
Provide a description of all manual and automated input requirements for the software product such as data entry from source documents and data extracts from other applications, as well as all output requirements for the software product such as printed forms, reports, display screens, files and other work products the system will process and produce.
Identify the data elements and logical data groupings that will be stored and processed by the software product. Include archiving data requirements and sensitivity of data. Describe safety requirements.
This section is supported by a data model. An accompanying data dictionary should be included in an appendix.
Delineate, at a detailed level, computer system requirements within the context of the processes they must support. This is supported by a process model, which may be included.
Portray owner/user defined standards for system operations, relating to hours of operations, system response time, volumes, growth, and reliability.
Describe hardware and software interface requirements, as well as the connectivity and data interchange requirements in terms of types and volumes of data, location, and frequency of use.
Describe security and privacy requirements.
Provide details of back up and recovery requirements. If software is identified as mission essential a continuity of operations plan must be developed.
A description of any special or unusual support considerations that this system or component might require e.g., first time a UNIX system will be shipped to the field.
This section should cover the required capabilities of the hardware, e.g., requirement for the hardware to support multiple operating systems, or must support ethernet.
Required characteristics of the hardware. At a minimum this should include any requirements for diagnosis of the hardware.
This section should cover the required capabilities of the software, e.g. databases, operating systems, communications (remote access), diagnostics.
Required characteristics of the software, e.g. reusability of code, packaging.
This section should define the requirements associated with ease of use, including menu structures, screen/window designs, screen colors, screen navigation, maximum input lines per screen, query capabilities, unattended installation, report layouts, online help and other interfaces to users and/or supervisors.
This section consists of three subsections and details the technical requirements.
Document any hardware/software or environment requirements needed to code and test the system, e.g., test bed environment requirements, etc.
Document the technical approach that translates user requirements into specific requirements that can be used by programmers/analysts to create the system design.
Document any design constraints that should be taken into consideration during the system design phase.
A glossary of terms and definitions used in the Requirements Specification that might not be known to the reader or open to misinterpretation. If a standard glossary is available this might be referenced in the reference section and included with the specification to any readers or reviewers of the specification.