Template for Software Requirement Specification Document

Dr. Ron Rymon

IDC Herzliya

Date: October 31, 2001

Overview

This section, which should not exceed one or two paragraphs, describes the project motivation, the product which is about to be developed, and the general goals that it will achieve. Choose your words carefully so that anyone that reads this section understands what you do, why you do it, and what to expect if s/he were to be present in your final presentation of the developed product.

The Problem

This section describes the problem addressed, or the need that your product will solve. It may describe a business process that your solution will improve. It should also describe related processes, and the current situation with your customer. The motivation and economic (or other) justification for the development of your solution shall be emphasized here

The Customer

This section describes the current customer for the project, if any, as well as other potential customers.

Alternative Solutions to the Problem

This section describes direct and indirect competition for your solution. Direct competition includes other software packages that are currently available and may be unavailable, inadequate, too expensive, or otherwise inferior to what you are about to propose. Indirect competition may include changes in the business processes, manual operation, etc.

The Proposed Product

This is the main section of the SRS document. It will outline the product that you propose. It is broken into several subsections as follows.

The Users

Who are the users, what skills they typically have, how many users, in what capacity or role they are using the proposed solution, how much of their time is spent with this solution, are they currently part of the organization, are they currently using other tools, etc.

The Environment

Describe the physical environment. Describe processes that are related to the inputs or outputs of the proposed solution, or that may otherwise interact or interfere with its operation. Describe the technological environment, including but not limited to hardware, operating systems, applications, etc.

The Requirements

In some SRS documents, this is a detailed list of all requirements that the product has to satisfy. I prefer a higher-level description of such requirements, at least in this phase (the SRS document may later be updated as the project progresses). It is also important that the requirements are grouped based on some logical decomposition. Such decomposition can be based on the eventual software components, broken by the different types of users, by the external interfaces, etc. Importantly, requirements shall be classified by their importance and urgency, e.g. into three classes (A, B, and C)

Use Cases

In this section, you ought to outline examples of the use of the product, including general description of each case, how it arises, and then flow (data and otherwise) from start to end.

The Challenges

Some projects have a certain element that represents technological risk. For example, an algorithm that was not yet developed, a performance challenge, etc. In this section, you ought to explore these challenges so that they can be discussed before the team dives into the project. These challenges shall also be closely monitored in subsequent phases of the project

Other Constraints

Usually, these include interfaces with other applications, a preferred or dictated technological environment, as well as certain requirements that may impose a constraint on the design of the project.

Criteria for Success

In this section, you ought to outline certain parameters for measuring the success of the project. These criteria can be based on the type and number of requirements that are covered. Other criteria may include feasibility and run times for certain sized problems. In some case, usability tests can confirm productivity of workers using your solution. Of course, the schedule and cost of the project are also significant criteria for success.

Initial Plan

In this section, describe the team’s plan until the end of the design phase.

Terms and Acronyms

References

To other documents, including WWW.