<System Name>

System Requirements Specification (SRS)

Version <TBD>

<Working Draft / Review Draft / Approved>

Produced for:

<Customer Name>

<Customer Address>

Produced by:

<Development Organization>

<Development Organization Address>

Revision History

Date

Version

Description

Author

TBD

0.1

Initial Draft

TBD

Table of Contents

Table of Figures

Figure 1: <System Name> Context Diagram 7

Figure 2: <System Name> Summary Use Case Diagram 8

Figure 3: <Actor Name> Use Case Diagram 8

Figure 4: <Path Name> Sequence Diagram 9

Figure 5: <External Data Repository Name> Use Case Diagram 10

Figure 6: <Path Name> Sequence Diagram 11

Figure 7: <External Hardware Name> Use Case Diagram 12

Figure 8: <Path Name> Sequence Diagram 13

Figure 9: <Network Name> Use Case Diagram 13

Figure 10: <Path Name> Sequence Diagram 14

Figure 11: <External Software Name> Use Case Diagram 15

Figure 12: <Path Name> Sequence Diagram 16

Figure 13: <External System Name> Use Case Diagram 17

Figure 14: <Path Name> Sequence Diagram 18

1Introduction

The section introduces the system requirements specification (SRS) to its reader.

1.1Definition

This system requirements specification is the requirements work product that formally specifies the requirements of the <System Name>.

1.2Specification Objectives

This system requirements specification has the following objectives:

  • To provide an overview of the application’s context and capabilities.

  • To formally specify the associated:

  • Operational requirements.

  • Informational requirements.

  • Quality requirements.

  • Architecture and Design constraints.

  • To document any future planned enhancements.

  • To document any open issues, major things to be completed, and assumptions.”

1.3Intended Audiences

This system requirements specification has the following intended audiences:

  • Architecture Team, which uses it to drive and validate the system architectures.

  • Customer Organization, which uses it to understand the scope of the application to be delivered.

  • Hardware Development Team, which uses it to drive the design of the hardware components.

  • Independent Test Team, which uses it to generate system and launch tests.

  • Metrics Team, which uses the requirements in it to estimate the size and scope of the endeavor.

  • Management Team, which uses it to manage project scope and schedule project activities.

  • Software Development Team, which uses it to drive the design of the software components.

  • Subcontractor Organizations, which use it to drive their work.

  • User Experience Team, which uses it to drive and validate the human interface prototype.

  • User Support Team, which uses its operational requirements as input to the users manual and user support materials.

1.4References

This SRS references or must be consistent with the following documents:

  • Customer Documents:

  • TBD

  • Endeavor Documents:

  • Application Vision Statement

  • Project Glossary

  • Development Organization Documents:

  • System Requirements Specification Content and Format Specification

  • System Requirements Specification Template

  • System Requirements Specification Inspection Checklist

1.5Specification Overview

This SRS is organized into the following sections:

  • Introduction, which introduces the system requirements specification (SRS) for <System Name> to its readers.

  • System Overview, which provides a high level description of the <System Name> system including its definition, functions, context, and typical usage.

  • System Operational Requirements, which specifies the system’s operational (a.k.a., functional) requirements in terms of a use case model consisting of each external’s use cases and use case paths.

  • System Quality Requirements, which specifies the required system’s quality factors that are not related to the specific operational requirements.

  • Architecture and Design Constraints, which specifies required architecture and design constraints to be treated as requirements.

  • Appendices, which defines ancillary information including open issues and TBDs, etc.

2System Overview

This provides a high level description of system including its usage and context.

2.1System Definition

<System Name> is TBD.

2.2Primary System Usage

<System Name> is typically used as follows. TBD

  • TBD

2.3<System Name> Context

The subsection uses context diagrams to document the context of the <System Name> system in terms of the external actors, data repositories, hardware, networks, software, and systems with which it interacts.

TBD

Figure 1: <System Name> Context Diagram

2.3.1Human Actors

<System Name> system interacts, either directly or indirectly, with the following significant human actors (roles, teams, and organizations):

  • TBD

2.3.2External Data Repositories

<System Name> system interacts, either directly or indirectly, with the following significant external data repositories:

  • TBD

2.3.3External Hardware

<System Name> system interacts, either directly or indirectly, with the following significant external hardware:

  • TBD

2.3.4External Networks

<System Name> system interacts, either directly or indirectly, with the following significant external networks:

  • TBD

2.3.5External Software

<System Name> system interacts, either directly or indirectly, with the following significant external software:

  • TBD

2.3.6External Systems

<System Name> system interacts, either directly or indirectly, with the following significant external systems:

  • TBD

3System Operational Requirements

The section of the SRS specifies the system’s operational requirements in terms of a use case model consisting of use cases and use case paths.

TBD

Figure 2: <System Name> Summary Use Case Diagram

3.1External Actors

This subsection describes and specifies external actors (human actors, teams, and organizations), the associated externals, and all use cases primarily driven by these externals.

3.1.1<External Actor Name>

The subsection specifies the operational requirements primarily concerning <External Actor Name>.

Definition

<A brief narrative English definition of the actor>

Responsibilities

<Actor Name> has the following responsibilities:

  • TBD

Required Capabilities

<Actor Name> needs the following required technical expertise, experience, and training to effectively interact with <System Name>:

  • TBD

Use Case Diagram

TBD

Figure 3: <Actor Name> Use Case Diagram

Use Cases

  • <Use Case 1 Name>

  • <Use Case 2 Name>

3.1.1.1Essential Use Case: <Use Case Name>

Use Case Requirement

The system shall TBD.

Business Justification

  • TBD

Preconditions
  • TBD

Use Case Paths
  • Normal:

  • <Normal Path Name>

  • Exceptional:

  • <Exceptional Path Name>

3.1.1.1.1<Normal/Exceptional> Path: <Path Name>

Path Requirement

The system shall TBD.

Externals

  • Clients:

  • TBD

  • Peers:

  • TBD

  • Servers:

  • TBD

Preconditions
  • TBD

Interactions
  1. <External Name> sends a <interaction name> [request | query] containing the following information to the <System Name>:

  • TBD

  1. <System Name> shall send a <interaction name> response containing the following information to the <External Name>:

  • TBD

  1. <System Name> shall send a <interaction name> event notification containing the following information to the <External Name>:

  • TBD

Blackbox Sequence Diagram

TBD

Figure 4: <Path Name> Sequence Diagram

Postconditions

  • TBD

Requirements Trace
  • TBD

Risk Factors
  • Volatility: [High | Medium | Low]

  • Frequency: [High | Medium | Low] <Average/maximum number of times a day/second>

  • Criticality: [High | Medium | Low]

  • Probability of Defects: [High | Medium | Low]

  • Risk: [High | Medium | Low]

3.2External Data Repositories

The subsection specifies the operational requirements primarily concerning <External Application Name>.

3.2.1<External Data Repository Name>

The subsection specifies the operational requirements primarily concerning <External Data Repository Name>.

Definition

<A brief narrative English definition of the external data repository>

Responsibilities

<External Data Repository Name> has the following responsibilities:

  • TBD

Use Case Diagram

TBD

Figure 5: <External Data Repository Name> Use Case Diagram

Use Cases

  • <Use Case 1 Name>

  • <Use Case 2 Name>

3.2.1.1Essential Use Case: <Use Case Name>

Use Case Requirement

The system shall TBD.

Business Justification

  • TBD

Preconditions
  • TBD

Use Case Paths
  • Normal:

  • <Normal Path Name>

  • Exceptional:

  • <Exceptional Path Name>

3.2.1.1.1<Normal/Exceptional> Path: <Path Name>

Path Requirement

The system shall TBD.

Externals

  • Clients:

  • TBD

  • Peers:

  • TBD

  • Servers:

  • TBD

Preconditions
  • TBD

Interactions
  1. <External Name> sends a <interaction name> [request | query] containing the following information to the <System Name>:

  • TBD

  1. <System Name> shall send a <interaction name> response containing the following information to the <External Name>:

  • TBD

  1. <System Name> shall send a <interaction name> event notification containing the following information to the <External Name>:

  • TBD

Blackbox Sequence Diagram

TBD

Figure 6: <Path Name> Sequence Diagram

Postconditions

  • TBD

Requirements Trace
  • TBD

Risk Factors
  • Volatility: [High | Medium | Low]

  • Frequency: [High | Medium | Low] <Average/maximum number of times a day/second>

  • Criticality: [High | Medium | Low]

  • Probability of Defects: [High | Medium | Low]

  • Risk: [High | Medium | Low]

3.3External Hardware

The subsection specifies the operational requirements primarily concerning <External Hardware Name>.

3.3.1<External Hardware Name>

The subsection specifies the operational requirements primarily concerning <External Hardware Name>.

Definition

<A brief narrative English definition of the external hardware>

Responsibilities

<External Hardware Name> has the following responsibilities:

  • TBD

Use Case Diagram

TBD

Figure 7: <External Hardware Name> Use Case Diagram

Use Cases

  • <Use Case 1 Name>

  • <Use Case 2 Name>

3.3.1.1Essential Use Case: <Use Case Name>

Use Case Requirement

The system shall TBD.

Business Justification

  • TBD

Preconditions
  • TBD

Use Case Paths
  • Normal:

  • <Normal Path Name>

  • Exceptional:

  • <Exceptional Path Name>

3.3.1.1.1<Normal/Exceptional> Path: <Path Name>

Path Requirement

The system shall TBD.

Externals

  • Clients:

  • TBD

  • Peers:

  • TBD

  • Servers:

  • TBD

Preconditions
  • TBD

Interactions
  1. <External Name> sends a <interaction name> [request | query] containing the following information to the <System Name>:

  • TBD

  1. <System Name> shall send a <interaction name> response containing the following information to the <External Name>:

  • TBD

  1. <System Name> shall send a <interaction name> event notification containing the following information to the <External Name>:

  • TBD

Blackbox Sequence Diagram

TBD

Figure 8: <Path Name> Sequence Diagram

Postconditions

  • TBD

Requirements Trace
  • TBD

Risk Factors
  • Volatility: [High | Medium | Low]

  • Frequency: [High | Medium | Low] <Average/maximum number of times a day/second>

  • Criticality: [High | Medium | Low]

  • Probability of Defects: [High | Medium | Low]

  • Risk: [High | Medium | Low]

3.4External Networks

This subsection describes and specifies external networks and all use cases primarily driven by these externals.

3.4.1<External Network Name>

The subsection specifies the operational requirements primarily concerning <External Network Name>.

Definition

<A brief narrative English definition of the network>

Responsibilities

<Network Name> has the following responsibilities:

  • TBD

Use Case Diagram

TBD

Figure 9: <Network Name> Use Case Diagram

Use Cases

  • <Use Case 1 Name>

  • <Use Case 2 Name>

3.4.1.1Essential Use Case: <Use Case Name>

Use Case Requirement

The system shall TBD.

Business Justification

  • TBD

Preconditions
  • TBD

Use Case Paths
  • Normal:

  • <Normal Path Name>

  • Exceptional:

  • <Exceptional Path Name>

3.4.1.1.1<Normal/Exceptional> Path: <Path Name>

Path Requirement

The system shall TBD.

Externals

  • Clients:

  • TBD

  • Peers:

  • TBD

  • Servers:

  • TBD

Preconditions
  • TBD

Interactions
  1. <External Name> sends a <interaction name> [request | query] containing the following information to the <System Name>:

  • TBD

  1. <System Name> shall send a <interaction name> response containing the following information to the <External Name>:

  • TBD

  1. <System Name> shall send a <interaction name> event notification containing the following information to the <External Name>:

  • TBD

Blackbox Sequence Diagram

TBD

Figure 10: <Path Name> Sequence Diagram

Postconditions

  • TBD

Requirements Trace
  • TBD

Risk Factors
  • Volatility: [High | Medium | Low]

  • Frequency: [High | Medium | Low] <Average/maximum number of times a day/second>

  • Criticality: [High | Medium | Low]

  • Probability of Defects: [High | Medium | Low]

  • Risk: [High | Medium | Low]

3.5External Software

The subsection specifies the operational requirements primarily concerning external software.

3.5.1<External Application Name>

The subsection specifies the operational requirements primarily concerning <External Software Name>.

Definition

<A brief narrative English definition of the external software>

Responsibilities

<External Software Name> has the following responsibilities:

  • TBD

Use Case Diagram

TBD

Figure 11: <External Software Name> Use Case Diagram

Use Cases

  • <Use Case 1 Name>

  • <Use Case 2 Name>

3.5.1.1Essential Use Case: <Use Case Name>

Use Case Requirement

The system shall TBD.

Business Justification

  • TBD

Preconditions
  • TBD

Use Case Paths
  • Normal:

  • <Normal Path Name>

  • Exceptional:

  • <Exceptional Path Name>

3.5.1.1.1<Normal/Exceptional> Path: <Path Name>

Path Requirement

The system shall TBD.

Externals

  • Clients:

  • TBD

  • Peers:

  • TBD

  • Servers:

  • TBD

Preconditions
  • TBD

Interactions
  1. <External Name> sends a <interaction name> [request | query] containing the following information to the <System Name>:

  • TBD

  1. <System Name> shall send a <interaction name> response containing the following information to the <External Name>:

  • TBD

  1. <System Name> shall send a <interaction name> event notification containing the following information to the <External Name>:

  • TBD

Blackbox Sequence Diagram

TBD

Figure 12: <Path Name> Sequence Diagram

Postconditions

  • TBD

Requirements Trace
  • TBD

Risk Factors
  • Volatility: [High | Medium | Low]

  • Frequency: [High | Medium | Low] <Average/maximum number of times a day/second>

  • Criticality: [High | Medium | Low]

  • Probability of Defects: [High | Medium | Low]

  • Risk: [High | Medium | Low]

3.6External Systems

The subsection specifies the operational requirements primarily concerning external systems.

3.6.1<External System Name>

The subsection specifies the operational requirements primarily concerning <External System Name>.

Definition

<A brief narrative English definition of the external system>

Responsibilities

<External Organization Name> has the following responsibilities:

  • TBD

Use Case Diagram

TBD

Figure 13: <External System Name> Use Case Diagram

Use Cases

  • <Use Case 1 Name>

  • <Use Case 2 Name>

3.6.1.1Essential Use Case: <Use Case Name>

Use Case Requirement

The system shall TBD.

Business Justification

  • TBD

Preconditions
  • TBD

Use Case Paths
  • Normal:

  • <Normal Path Name>

  • Exceptional:

  • <Exceptional Path Name>

3.6.1.1.1<Normal/Exceptional> Path: <Path Name>

Path Requirement

The system shall TBD.

Externals

  • Clients:

  • TBD

  • Peers:

  • TBD

  • Servers:

  • TBD

Preconditions
  • TBD

Interactions
  1. <External Name> sends a <interaction name> [request | query] containing the following information to the <System Name>:

  • TBD

  1. <System Name> shall send a <interaction name> response containing the following information to the <External Name>:

  • TBD

  1. <System Name> shall send a <interaction name> event notification containing the following information to the <External Name>:

  • TBD

Blackbox Sequence Diagram

TBD

Figure 14: <Path Name> Sequence Diagram

Postconditions

  • TBD

Requirements Trace
  • TBD

Risk Factors
  • Volatility: [High | Medium | Low]

  • Frequency: [High | Medium | Low] <Average/maximum number of times a day/second>

  • Criticality: [High | Medium | Low]

  • Probability of Defects: [High | Medium | Low]

  • Risk: [High | Medium | Low]

4System Quality Requirements

This section specifies the required system quality factors that are not related to the specific operational requirements documented in the use case model.

4.1Developer-Oriented Quality Requirements

This subsection specifies all developer-oriented quality requirements:

4.1.1Installability

This subsection specifies the following requirements concerning the installability of the application:

  1. TBD

4.1.2Maintainability

This subsection specifies the following requirements concerning the maintainability of the application:

4.1.2.1Correctability

This subsection specifies the following requirements concerning the correctability of the application:

  1. TBD

4.1.2.2Extensibility

This subsection specifies the following requirements concerning the extensibility of the application:

  1. TBD

4.1.3Portability

This subsection specifies the following requirements concerning the portability of the application:

  1. TBD

4.1.4Reusability

This subsection specifies the following requirements concerning the reusability of the application:

  1. TBD

4.1.5Scalability

This subsection specifies the following requirements concerning the scalability of the application:

  1. TBD

4.1.6Testability

This subsection specifies the following requirements concerning the testability of the application:

  1. TBD

4.2User-Oriented Quality Requirements

This subsection specifies all user-oriented quality requirements:

4.2.1Accessibility

This subsection specifies the following requirements concerning the degree to which the system must be accessible to use by people with disabilities:

  • SYSQR-ACC-1) TBD

4.2.2Auditability

This subsection specifies the following requirements concerning the degree to which the system must support independent audits of its financials and transactions:

  • SYSQR-AUD-1) TBD

4.2.3Configurability

This subsection specifies the following requirements concerning the degree to which the system must be configurable into multiple variants.

4.2.3.1Functional Variants

This subsection specifies the following requirements concerning the need for the system to exist in multiple variants that provide different sets of capabilities:

  • SYSQR-CON-1) TBD

4.2.3.2Internationalization

This subsection specifies the following requirements concerning the degree to which the system must function in a global marketplace:

  1. The application shall be internationalized for the following countries: TBD.

  2. The application shall be internationalized for the following native languages and dialects of the target countries: TBD.

  3. The application shall properly handle multibyte character sets (MBCS) for the official languages of the target countries (e.g., using Unicode ISO-10646).

  4. The application shall use target country and language conventions for:

  • Calendars (e.g., Japan, Korea, and Islamic countries), date formatting (e.g., Europe vs. USA), and time formatting (e.g., 12 hour vs. 24 hour clock).

  • Currency formatting (e.g., currency symbol, fractional currency, and number of digits).

  • Cultural norms (e.g., avoidance of specific colors, numbers, graphics, and words).

  • Line breaks and hyphenation.

  • Names (e.g., number, order, honorifics, and suffixes).

  • Numbers:

  • Chinese ideographic characters for numbers in financial documents.

  • National identity numbers (e.g., social security number).

  • Sorting of lists.

  • Legal issues such as:

  • Import/export laws.

  • Tariff and sales tax calculations.

  • Customs documentation.

  • Trademarks.

  • Privacy laws.

  • Text directions (e.g., left to right, right to left, top to bottom).

  1. Internationalization shall not require changes to executable software component including user interfaces.

4.2.3.3Personalization

This subsection specifies the following requirements concerning degree to which the system configures itself to provide a tailored experience (i.e., look and feel) to different individual users:

  • SYSQR-CON-TBD) TBD

4.2.4Correctness

This subsection specifies the following requirements concerning the degree to which the system must ensure that its information is correct.

4.2.4.1Allowable Latent Defects

This subsection specifies the following requirements concerning the maximum number of allowable latent defects of each severity in released work products:

  • SYSQR-COR-1) TBD

4.2.4.2Accuracy

This subsection specifies the following requirements concerning with degree of correctness of the system’s outputs:

  • SYSQR-COR-TBD) TBD

4.2.4.3Precision

This subsection specifies the following requirements concerning the resolution of the system’s numerical outputs:

  • SYSQR-COR-TBD) TBD

4.2.4.4Timeliness

This subsection specifies the following requirements concerning the degree to which the system must ensure that its persistent information is current (i.e., up-to-date):

  • SYSQR- COR-TBD) TBD

4.2.5Efficiency

This subsection specifies the following requirements concerning the degree to which the system effectively uses its resources (e.g., processor, RAM, and memory):

  • SYSQR-EFF-1) TBD

4.2.6Interoperability

This subsection specifies all requirements and goals concerning the degree to (or ease with which) the system can be integrated with other system (e.g., legacy applications and required databases):

  • SYSQR-IOP-1) TBD

4.2.7Operational Availability

This subsection specifies the following requirements concerning the percent of time that the system must function without planned or unplanned downtime from the viewpoints of different user types or client applications:

  • SYSQR-OA-1) TBD

4.2.8Performance

This subsection specifies the following requirements concerning the performance of the system:

4.2.8.1Capacity

This subsection specifies the following requirements concerning the minimum number of objects that the system can support:

  • SYSQR-PER-1) TBD

4.2.8.2Latency

This subsection specifies the following requirements concerning the maximum time that is permitted for the system to execute specific tasks (i.e., system operations) or use case paths end to end:

  • SYSQR-PER-TBD) TBD

4.2.8.3Response Time

This subsection specifies the following requirements concerning the maximum time that is permitted for the system to respond to specific requests:

  • SYSQR-PER-TBD) TBD

4.2.8.4Throughput

This subsection specifies the following requirements concerning how many executions of a given system operation or use case path must the system be able execute in a unit of time:

  • SYSQR-PER-TBD) TBD

4.2.9Reliability

This subsection specifies the following requirements concerning the reliability (e.g., mean time between failures, number of failures per unit time) of the system:

  • SYSQR-REL-1) TBD

4.2.10Robustness

This subsection specifies the following requirements concerning the degree to which the system continues to properly function under abnormal circumstances (e.g., invalid inputs, failure of software or hardware components, and failure of applications on which it depends):

  • SYSQR-ROB-1) TBD

4.2.11Safety

This subsection specifies the following requirements concerning the degree to which the system does not directly or indirectly (e.g., via inactivity) cause accidental harm to life or property (e.g., loss of money or data):

  • SYSQR-SAF-1) TBD

4.2.12Security

This subsection specifies the following requirements (not already captured in the use case model) that are concerning the degree to which system protects itself from unauthorized access or modification:

4.2.12.1Identification

  • SYSQR-SEC-1) TBD

4.2.12.2Authentication

  • SYSQR-SEC-TBD) TBD

4.2.12.3Authorization

  • SYSQR-SEC-TBD) TBD

4.2.12.4Immunity

  • SYSQR-SEC-TBD) TBD

4.2.12.5Privacy

  • SYSQR-SEC-TBD) TBD

4.2.12.6Integrity

  • SYSQR-SEC-TBD) TBD

4.2.12.7Intrusion Detection

  • SYSQR-SEC-TBD) TBD

4.2.12.8Nonrepudiation

  • SYSQR-SEC-TBD) TBD

4.2.12.9System Maintenance Security

  • SYSQR-SEC-TBD) TBD

4.2.13Usability

This subsection specifies the following requirements concerning the ease with which the system can be used.

  • SYSQR-USE-1) TBD

5Architecture and Design Constraints

The section documents the major architecture and design constraints on the system.

5.1Business Rules

The subsection documents all relevant business rules.

5.2Data and Content Constraints

The subsection documents all required data (i.e., content) constraints.

5.2.1Databases

The subsection documents all required design constraints concerning the use of databases:

  • SYSDC-DB-1) TBD

5.3Software Constraints

The subsection documents all required software constraints.

5.3.1Components

The subsection documents all required design constraints concerning the use of components:

  • SYSDC-COM-1) TBD

5.3.2High-Level Languages

The subsection documents all required design constraints concerning the use of high-level programming languages:

  • SYSDC-HLL-1) TBD

5.4Hardware Constraints

The subsection documents all required design constraints concerning minimum or actual hardware.

TBD

5.5Industry Standards

The subsection documents all required design constraints concerning compliance with industry standards:

DC-STD-1) The system shall conform to ISO 10646 (Unicode UTF-8) and ISO 10646-1 (Unicode UTF-16) standards for character set encoding.

DC-STD-2) The system shall conform to ISO 4217, codes for the representation of currencies. DC-STD-3) The system shall conform to ISO 31, codes for units of measure. DC-STD-4) The system shall conform to ISO639-1 Languages, codes for the representation of languages. DC-STD-5) The system shall conform to ISO 3166-1, codes for the representation of names of countries. DC-STD-6) The system shall conform to ISO 8601, representation of dates and times.

5.6Legal and Regulatory Constraints

The subsection documents all required design constraints concerning compliance with legal and regulatory constraints:

  1. Envisioned Future Enhancements

The section documents the following envisioned future enhancements:

Appendices

The section documents the following appendices:

  • Open Issues

  • Major Things To Be Done

  • Assumptions

A. Open Issues

This appendix documents the following open issues to be resolved:

  • TBD

B. Major Things To Be Done

This appendix documents the following major things that have not yet been completed:

  • TBD

C. Assumptions

This appendix documents the following assumptions behind the requirements:

  • TBD

Topic revision: r1 - 2011-09-13 - JimSkon
 
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback