Seilevel Software Requirements Specification Template

[Project Title]
Software Requirements Specification
Original Date: / 8/21/2012 / Document Version / 0.1
Last Revision Date: / 8/21/2012
Author Information
Author: / Jane Doe
Title: / Senior Business Analyst
E-mail: /
Phone: / 512-123-4567

Table of Contents

1Document Revision History

2Approvers & Reviewers

3Document Purpose

4Assumptions

5Constraints

6Project Stakeholders

7Requirements

7.1Feature 1

7.1.1Feature 1 Models

7.1.2Feature 1 Dependencies

7.1.3Feature 1 Requirements

8Non-Functional Requirements

9UI Design

9.1UI Flows

9.2Screen 1

9.2.1Screen 1 Screen Shots

9.2.2Screen 1 DAR Models

Appendix A – Glossary

1Document Revision History

Capture information about every published version in the table below, including a brief description of the changes in each version.

Date / Version / Section/Page / Update Description / Contact Name
12/1/2011 / 0.1 / All / Initial Draft / Jane Doe

2Approvers & Reviewers

The table below represents a list of all people that are required to review and approve the requirements document.

Name / Role / Responsibility / Approval Date
Jane Doe / Approver / [Insert Description]

3Document Purpose

The Software Requirements Specification describes the functional and nonfunctional requirements for software release that follows from a scope and vision document or a business requirements document. This document is intended for those who are implementing the software, as well as for testing and deployment.

Chapter / Software Requirements Specification (SRS)
1 – Revision History / Y
2 – Approvals / Y
3 – Introduction / Y
4 – Assumptions / Y
5 – Constraints / Y
6 – Stakeholders / Y
7 – Project Overview / M
8 – Product Definition / N
9 – Requirements / Y
10 – Non-Functional Req / Y
11 – UI Design / Y
Appendix A – Glossary / Y

4Assumptions

This section contains the assumptions for a project. An assumption is a statement that is believed to be true in the absence of proof or definitive knowledge.

ID / Assumption / Assumption Owner / Impact if not True

5Constraints

This section contains constraints on the project. A constraint is a restriction that is imposed on the choices available to the developer for the design and construction of a product.

ID / Constraint / Constraint Owner

6Project Overview

The Project Overview section is intended to describe the goals and objectives of the entire project, as well as to introduce the different product concept. The section should identify the business problems, business objectives, success metrics, and product concepts associated with the project.

6.1Business Objectives Model

This section will contain the Business Objectives Models and/or Key Performance Indicator Model. The purpose of the Business Objectives Model is to illustrate the Business Problems and Business Objectives of a project in a manner that can be easily consumed to understand the purpose of the project.

6.2Feature Tree

A feature tree can be provided in the Project Concept discussion in order to provide additional information around the types of features that are associated with the project. These features are typically high-level at this stage.

6.3High-Level L1 Process Flow

This section should contain a high-level L1 process flow which describes the project at a very high level so that the consumer of the document has a little context around the project.

Sometimes, this L1 is written such that each of the steps will become a Product Concept. In other cases, each Product Concept is a variation of this L1 that represents a different user scenario.

7Project Stakeholders

This section should contain org charts around various groups of stakeholders surrounding the project. Stakeholders include business stakeholders, product management, IT, and test. The org chart should include individuals involved in elicitation, review, development, and testing. It is also a good idea to identify those business stakeholders involved in UAT within these org charts.

Additional org charts and other models should be created to describe the various users of the product.

8Requirements

This section should contain additional context around the various features of a project, as well as the Business Requirements for a project. It is important to remember that a Feature is implementation agnostic. Implementation details should be captured in the Technical Design section.

8.1Feature 1

This section contains the entire context around a feature.

8.1.1Feature 1 Models

The detailed models associated with a feature should be located here. Those models could include L3 process flows.

8.1.2Feature 1 Dependencies

This section should list all of the dependencies a particular feature has on other features or other projects.

8.1.3Feature 1 Requirements

These requirements should be presented in a RMM. Acceptance Criteria and the Business Rules should be captured.

9Non-Functional Requirements

This section will contain all non-functional requirements. Usually, non-functional requirements are established for the project as a whole, and not an individual feature. If the non-functional requirements are defined on a feature bases, they can be moved to the previous section. Types of Non-Functional Requirements to consider:

Availability- Desired “up time” during which the system and data are available for use. [The system shall be available between the hours of 6AM and 10PM ship time, inclusive, every day of the week.]
Documentation- Descriptions of any expected supplemental information, including its purpose, desired contents, level of detail, and formatting. [The system shall provide context sensitive help that takes the user to a help topic specific to the screen in focus which describes how to use each control and data field on the screen.]
Emotional- Describe the user’s feelings about the experience with the system, including where and when the emotions should be felt, and how they vary over time. [The system shall elicit a fun feeling for the passenger when they view the physical outputs from the system.]
Flexibility - How much effort is needed to add or change capabilities within the product. [The system shall allow for the addition of new fields of interest with no more than 2 hours of effort.]
Hardware Interfaces - Characteristics of each interface between the software system and the hardware components supported by the system. [The system shall be able to upload digital photographs directly from a digital camera to attach to the passenger profile.]
Legal- System constraints that are required by law. [The system shall not display any information the passenger marked as confidential on the passenger profile.]
Logical Databases - Any information that is required to be placed into a database, including data relationships, field types, frequency of use, integrity constraints and accessing capabilities. [The system shall maintain a history of passenger suggestions.]
Memory Constraints- Constraints on the system based on memory usage. [The client shall run on a system with 500 KB of memory, utilizing no more than 30% of the available system memory resources at anytime.]
Operations- System behaviors necessary for the support and operations of the system. [The system shall notify the administrator users by email and pager if the database server becomes unavailable.]
Performance- The speed with which the system accomplishes specific actions under specified conditions. [The system shall regenerate and display one passenger’s updated suggestions within 5 seconds of receiving the update request.]
Portability- Ability to migrate from one platform to another or one machine to another. [The system shall be designed such that the client runs in Windows XP now and in Windows Vista without code changes when the cruise ship upgrades its systems.]
Reliability - Specified period of time and conditions for which the software must execute without a failure. [The system shall operate without critical failure for a consecutive 72 hour period with 20 users simultaneously performing their common tasks. (See test plan for definitions of “critical failure” and “common tasks.”)]
Reusability - How easily a component of the system can be used by another system. [The system’s components to update the passenger profile shall be usable in the next release of the Passenger Tracking system.]
Robustness - Expected behavior when there is invalid data, defects, or unexpected errors. [The system shall inform the user of the issue and allow the user to continue working offline if the primary database server becomes unavailable.]
Security - Behaviors necessary to protect the software from accidental or malicious access, use, modification, destruction, or disclosure. [The system shall store all passwords using 128 bit encryption.]
Site Adaptation - Behaviors necessary to support customization of the product specific to where it will be installed or used, including details of the customizations, globalization, and localization. [The system shall display all time stamps in the cruise ship’s local time.]
Software Interfaces - Characteristics of each interface between the software system and other software components of the system or other systems. [The system shall support using the Event Schedule system’s data to match passenger interests to available programs.]
Testability - Behaviors of the system necessary to support testing the system. [All user interface components must react to scripted input from the testing tool exactly as if the user input the scripted data or command.]
Usability - Defines the ease with which end user classes can perform specific tasks with the software. [The user interface shall allow users to regenerate the passenger suggestions from within two clicks after updating their profile information.]

10UI Design

Often, a separate design team is used to product the official screen shots or mockups for a product. Those design teams rely on business requirements in order to produce their deliverables. The UI requirements therefore often need to be presented in separate documentation, but can be captured here instead.

10.1UI Flows

The UI Flows are used to document how the screens flow from a user perspective.

10.2Screen 1

This section contains the screen shots and DAR models for a particular screen.

10.2.1Screen 1 Screen Shots

This section contains the shots for a particular screen.

10.2.2Screen 1 DAR Models

This section contains the DAR models for a particular screen. DAR models can often be presented better in a power point; in that case, link to the models from this location.

Appendix A– Glossary

The key business terms and their definitions that are used in this document are documented here.

Term / Definition
[Project Title] / Page 1 of 15