TEMPLATE Software Requirements Specification (SRS)

This is a template (outline) for a Modern Software Requirements Specification derived from the book "Managing Software Requirements" (Leffingwell, Wildrig). You can use this page as a template or guide for creating a new SRS.

Introduction
Purpose
Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or subsystem identified, as well as nonfunctional requirements, design constraints, and other factors necessary to provide a complete, comprehensive description of the software requirements.

Scope
This section provides a brief description of the software application that the SRS applies to, the features or other subsystem grouping, what use-case model(s) it is associated with, and anything else that is affected or influenced by this document.

References
Provide a list of project-related references or applicable documents that bear on this project.

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 software described by this SRS may be based.

Use-Case Model Survey

This section provides an overview of the use-case model. The survey is used by people interested in the behavior of the system, such as the customer, users, architects, use case authors, designers, use case designers, testers, managers, reviewers, and writers. This section lists for each use case: The use case name. A brief description explaining the use case's function and role in the system. A list of actors for the use case. The aggregation of these actors is further defined in the accompanying actor survey.

Diagram of the use case model. A diagram of the entire use-case model is included here.

Actor Survey
All of the actors mentioned in the use-case model survey are reported here. For each actor, you should list: The actor's name A brief description of the actor

Requirements
Functional Requirements
This section describes the functional requirements of the system for those requirements that are expressed in the natural-language style. For many applications, this may constitute the bulk of the package, and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods, by user or by subsystem, may also be appropriate. Where application development tools (requirements tools, modeling tools, and so on) are used to capture the functionality, this section of the document will refer to the availability of that data and will indicate the location and name of the tool used to capture the data.

Nonfunctional Requirements
Most nonfunctional requirements are typically recorded in natural language in this section of the specification. However, nonfunctional requirements may also be included with a specific use case specification. Usability This section should include all of those requirements that affect usability. These often include: Specify the required training time for normal users and power users to become productive at particular operations. Specify measurable task times for typical tasks; alternatively, base usability requirements of the new system on other systems that the users know and like. Specify requirements to conform to common usability standards, such as IBM's CUA standards or the GUI standards published by Microsoft for Windows. Refer to the User's Bill of Rights for additional guidelines.

Reliability Requirements for system reliability should be specified here. Availability: Specify percent of time available (xx.xx%), hours of use, maintenance access, degraded-mode operations, and so on. Mean time between failures (MTBF): This is usually specified in hours but could also be specified in terms of days, months, or years. Mean time to repair (MTTR): How long is the system allowed to be out of operation after it has failed? Accuracy: Specify precision (resolution) and accuracy (by some known standard) that is required in the system's output. Maximum bugs or defect rate: Usually expressed in terms of bugs/KLOC (thousands of lines of code) or bugs per function-point. Bugs or defect rate: Categorized in terms of minor, significant, and critical bugs. The requirement(s) must define what is meant by a "critical" bug (such as complete loss of data or complete inability to use certain parts of the functionality of the system).

Performance The performance characteristics of the system should be outlined in this section. Include specific response times. Where applicable, reference related use case by name. Response time for transaction (average, maximum) Throughput (transactions per second) Capacity (the number of customers or transactions the system can accommodate) Degradation modes (the acceptable mode of operation when the system has been degraded) Resource utilization (memory, disk, communications)

Supportability This section indicates any requirements that will enhance the supportability or maintainability of the system being built including coding standards, naming conventions, class libraries, maintenance access, and maintenance utilities.

Online User Documentation and Help System Requirements

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

Design Constraints
This section should indicate 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 development tools, architectural and design constraints, purchased components, and class libraries. It is good practice to provide a brief description for why each given constraint has been mandated.

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. Common Examples: Application server software and version Database software and version J2EE Specification (typically because of app server requirements/supportability) Servlet Specification (typically because of app server requirements/supportability)

Interfaces
This section defines the interfaces that must be supported by the application. This section should contain adequate specificity, protocols, ports, and logical addresses, and so on, so that the software can be developed and verified against the interface requirements. User Interfaces Describe the user interfaces that are to be implemented by the software. Hardware Interfaces Define any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, and expected behavior. Software Interfaces Describe software interfaces to other components of the software system. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the scope of this SRS but with which this software application must interact. Communications Interfaces Describe any communications interfaces to other systems or devices, such as local area networks or remote serial devices.

Licensing Requirements
Define any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software.

Legal, Copyright, and Other Notices

Describe any necessary legal disclaimers, warranties, copyright notices, patent notice, word mark, trademark, or logo compliance issues for the software.

Applicable Standards
Describe by reference any standards (and the specific sections of any such standards) that apply to the system being described. For example, this could be legal, quality, and regulatory standards, as well as industry standards for usability, interoperability, internationalization, operating system compliance, and so on.

Index
The index is provided to assist the reader in locating key concepts and topics that occur throughout the document.

Glossary
Describe any terms that are unique to this application context and any definitions, acronyms, abbreviations, or other project or company-specific shorthand that is necessary for an understanding of this document and the application.

Appendixes
You should insert appendixes here as appropriate. Note that the following template appendix is provided specifically to allow you to record use cases. Feel free to insert as many appendixes as you need. Appendix: Use Case Specifications