<Project Name>
System Requirements Specification
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and must be deleted before publishing the document. A paragraph entered following this style is automatically set to normal (style=Body Text).]
Revision History
Date |
Version |
Description |
Author |
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
3.2 Non-Functional Requirements
3.2.6 Additional Systems Engineering Considerations
3.2.6.2 Environmental Requirements
3.2.6.3 Other Product Assurance Requirements
3.2.6.4 Human-Related Requirements
3.2.6.5 Logistics Requirements
3.2.7 Online User Documentation and Help System Requirements
3.2.9.4 Communications Interfaces
3.2.11 Legal, Copyright, and Other Notices
System Requirements Specification
[The introduction of the System Requirements Specification (SysRS) provides an overview of the entire SysRS. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the SysRS.]
[Note: The SysRS captures the complete system requirements for the system, or a portion of the system. Following is a typical SysRS outline for a project using only traditional natural-language style requirements - with no use-case modeling. It captures all requirements in a single document, with the Supplementary Specifications combined, or equivalent material inserted.]
[Specify the purpose of this SysRS. The SysRS fully describes the functional and behavioral capabilities of the identified system. It also describes nonfunctional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements for the system.]
[A brief description of the system that the SysRS applies to, and anything else affected or influenced by this document.]
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the SysRS. This information can be provided by reference to the project Glossary.]
[This subsection provides a complete list of all documents referenced elsewhere in the SysRS. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information can be provided by reference to an appendix or to another document.]
[This subsection describes what the rest of the SysRS contains and explains how the document is organized.]
[This section of the SysRS describes the general factors that affect the system and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3, and makes them easier to understand. Include items such as the following:
Reference can be made from this section to the Vision artifact, rather than replicating material from that document.]
[This section of the SysRS contains all the system requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.]
[This section describes the required capabilities of the system, expressed in natural-language form. For many systems, this might constitute the bulk of the SysRS Package, and thought must be given to the organization of this section. This section is typically organized by feature, function, or functional group (tracing from the Vision artifact), but alternative organization methods might also be appropriate, for example, organization by user or role.
This section describes the refinement of the feature or function into constituent requirements, itemizing the requirements thus derived. The behavior that the system is required to exhibit in support of these derived requirements are described, along with any associated performance requirements (response time, speed, throughput, rates, frequency, accuracy, precision, capacity, and so on). This behavior description also includes required behavior under error or failure conditions (handling of erroneous input, unexpected conditions, fallback, and so on). It might not be necessary in every case to specify how errors and unexpected events are to be handled. In many cases, this can be left to the system architect to decide.]
[The capability description, and its refinement.]
[Note: If the Supplementary Specifications artifact has been produced, it might simply be included here. It covers the same topics.]
[This section includes all of those requirements that affect usability. Examples follow:
[The requirement description.]
[Specify the requirements for reliability of the system here. Suggestions are as follows:
[The requirement description.]
[Outline the performance characteristics of the system in this section. Include specific response times. Where applicable, reference related Use Cases by name. In general, associate all required capabilities, whether described in use-case form or simply by text, with some performance statement (describing how well the system should provide the capability or function). It is better to keep those statements of performance in proximity to the affected capability (in the "special requirements" part of a use-case description, for example). Here, you can keep statements of requirements that need to be tested, but which are not aligned with specific capability. Some performance characteristics are:
[The requirement description.]
[This section indicates any requirements that enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, and maintenance utilities.]
[The requirement description.]
[This section indicates any design constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, class libraries, and so on.]
[The requirement description.]
[Systems engineering potentially requires other types of requirements to be addressed:]
[For example, weight, size, power, and so on.]
[For example, moisture, contaminant, thermal, electrical, mechanical, and so on.]
[For example, safety, security, other quality factors (for example, survivability).]
[Describe the requirements imposed on the system in support of the people who use and support the system. Examples include training capabilities - equipment and materials to be included for training - maintenance capabilities, and ergonomic considerations not covered by interface descriptions and standards.]
[Describe the requirements imposed on the system because of logistics considerations including maintenance, support, transportation, supply, accommodation of existing systems.]
[Describes the requirements, if any, for online user documentation, help systems, help about notices, and so forth.]
[This section describes any purchased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.]
[This section defines the interfaces that must be supported by the system. It contains adequate specificity, protocols, ports and logical addresses, and so forth, so that the system can be developed and verified against the interface requirements. Also, describe any requirements to be imposed on interfaces internal to the system. These arise, for example, when the system design is constrained to use existing hardware or software components internally.]
[Describe the user interfaces that are to be implemented by the system.]
[This section defines any hardware interfaces that are to be supported by the system, including logical structure, physical addresses, expected behavior, and so on.]
[This section describes software interfaces to be supported by the system, in terms of operations and signals supported (and for which support is required), protocols and data characteristics.]
[Describe any communications interfaces to other systems or devices such as local area networks, and so forth.]
[Defines any licensing enforcement requirements or other usage restriction requirements which are to be exhibited by the system.]
[This section describes any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark or logo compliance issues for the system.]
[This section describes by reference any applicable standards and the specific sections of any such standards that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth.]
[The supporting information makes the SysRS easier to use. It includes:
These might include information about architectural and user-interface prototypes. When appendices are included, the SysRS must explicitly state whether or not the appendices are to be considered part of the requirements.]