<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
1.3 Definitions, Acronyms, and Abbreviations
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 that is 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 such items as:
Reference can be made from this section to the Vision artifact, rather than replicating material from that document.]
[If you are using use-case modeling, this section contains an overview of the use-case model. This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships. Refer to the Use-Case Model Survey Report, which can be used as an enclosure at this point.]
[This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the system described by this SysRS might be based.]
[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.
When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications (either as an artifact itself, or according to the sections under "3.2 Non-Functional Requirements," in this document).]
[This section describes the required capabilities of the system, expressed as use cases. 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 (which broadly characterize a "capability" - tracing from the Vision artifact), but alternative organization methods might also be appropriate, for example, organization by user or role.]
[In use-case modeling, the use cases define the majority of the functional requirements of the system, along with some non-functional (performance-related) requirements. For each use case in the above use-case model, refer to, or enclose, the use-case report in this section. Make sure that each requirement is clearly labeled. Where appropriate, group the use cases by capability - functionally refined if necessary - so that the right level of functional and behavioral description is achieved.]
[This section describes any additional functional requirements of the system (not captured as use cases), expressed in natural-language form.]
[The requirement description.]
[Note: If the Supplementary Specifications artifact has been produced, it can simply be included here. It covers the same topics.]
[This section includes all of those requirements that affect usability. For example:
[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. Performance characteristics include:
[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 forth.]
[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, and accommodation of existing systems.]
[Describes the requirements, if any, for online user documentation, help systems, help about notices, and so on.]
[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 must contain adequate specificity, protocols, ports and logical addresses, and so forth, so that the system can be developed and verified against the interface requirements. Any requirements to be imposed on interfaces internal to the system must also be described. 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 forth.]
[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 on.]
[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.]