<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.       Introduction         

1.1     Purpose     

1.2     Scope     

1.3     Definitions, Acronyms, and Abbreviations     

1.4     References     

1.5     Overview     

2.       Overall Description    

2.1 Use-Case Model Survey 

2.2 Assumptions and Dependencies

3.       Specific Requirements

3.1     System Capabilities

3.1.1 Use-Case Reports 

3.1.2 Additional Functionality

3.2     Non-Functional Requirements

3.2.1 Usability 

3.2.2 Reliability 

3.2.3 Performance 

3.2.4 Supportability 

3.2.5 Design Constraints 

3.2.6 Additional Systems Engineering Considerations 

3.2.6.1 Physical Requirements 

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.8 Purchased Components 

3.2.9 Interfaces 

3.2.9.1 User Interfaces 

3.2.9.2 Hardware Interfaces 

3.2.9.3 Software Interfaces 

3.2.9.4 Communications Interfaces 

3.2.10 Licensing Requirements 

3.2.11 Legal, Copyright,and Other Notices 

3.2.12 Applicable Standards

4.       Supporting Information    


System Requirements Specification

1.                  Introduction

[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.]

1.1     Purpose

[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.]

1.2     Scope

[A brief description of the system that the SysRS applies to, and anything else that is affected or influenced by this document.]

1.3     Definitions, Acronyms, and Abbreviations

[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.]

1.4     References

[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.]

1.5     Overview

[This subsection describes what the rest of the SysRS contains and explains how the document is organized.]

2.                  Overall Description

[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.]

2.1               Use-Case Model Survey

 [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.]

2.2               Assumptions and Dependencies

[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.]

3.                  Specific Requirements

[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).]

3.1               System Capabilities

[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.]

3.1.1           Use-Case Reports

[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.]

3.1.2           Additional Functionality

[This section describes any additional functional requirements of the system (not captured as use cases), expressed in natural-language form.]

3.1.2.1     <Functional Requirement One>

[The requirement description.]

3.2                 Non-Functional Requirements

[Note: If the Supplementary Specifications artifact has been produced, it can simply be included here. It covers the same topics.]

3.2.1          Usability

[This section includes all of those requirements that affect usability. For example:

3.2.1.1     <Usability Requirement One>

[The requirement description.]

3.2.2          Reliability

[Specify the requirements for reliability of the system here. Suggestions are as follows:

3.2.2.1     <Reliability Requirement One>

[The requirement description.]

3.2.3          Performance

[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:

3.2.3.1      <Performance Requirement One>

[The requirement description.]

3.2.4          Supportability

[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.]

3.2.4.1    <Supportability Requirement One>

[The requirement description.]

3.2.5          Design Constraints

[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.]

3.2.5.1     <Design Constraint One>

[The requirement description.]

3.2.6     Additional Systems Engineering Considerations

[Systems engineering potentially requires other types of requirements to be addressed:]

3.2.6.1  Physical Requirements

[For example, weight, size, power, and so forth.]

3.2.6.2  Environmental Requirements

[For example, moisture, contaminant, thermal, electrical, mechanical, and so on.]

3.2.6.3  Other Product Assurance Requirements

3.2.6.3.x     <Category>

[For example, safety, security, other quality factors (for example, survivability).]

3.2.6.4   Human-Related Requirements

[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.]

3.2.6.5   Logistics Requirements

[Describe the requirements imposed on the system because of logistics considerations including maintenance, support, transportation, supply, and accommodation of existing systems.]

3.2.7          Online User Documentation and Help System Requirements

[Describes the requirements, if any, for online user documentation, help systems, help about notices, and so on.]

3.2.8          Purchased Components

[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.]

3.2.9          Interfaces

[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.]

3.2.9.1     User Interfaces

[Describe the user interfaces that are to be implemented by the system.]

3.2.9.2      Hardware Interfaces

[This section defines any hardware interfaces that are to be supported by the system, including logical structure, physical addresses, expected behavior, and so forth.]

3.2.9.3       Software Interfaces

[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.]

3.2.9.4       Communications Interfaces

[Describe any communications interfaces to other systems or devices such as local area networks, and so on.]

3.2.10        Licensing Requirements

[Defines any licensing enforcement requirements or other usage restriction requirements which are to be exhibited by the system.]

3.2.11        Legal, Copyright, and Other Notices

[This section describes any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark or logo compliance issues for the system.]

3.2.12        Applicable Standards

[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.]

4.                  Supporting Information

[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.]