EPRI

Planning Document
Software Requirements Document (SRD)

Sample Template

Instructions:
Please elaborate on each subject. You may use your own document(s) instead of
this sample template.
If a topic is not applicable to your software, please enter Not Applicable.
Please submit this document with the Beta software submittal at the latest.

Software Name:
Author:
Date:
Revision History:

Revision #:
Date:

Software Requirements Document (SRD)

Sample Template
1.0
Introduction......................................................................................................1
2.0
Team Members................................................................................................1
3.0
Assumptions, Constraints, Schedule and Design............................................1
3.1 Assumptions....................................................................................................1
3.2 Constraints.......................................................................................................1
3.3 Schedule...........................................................................................................2
3.4 Design..............................................................................................................2
4.0
General System Description............................................................................2
4.1 System Context................................................................................................3
4.2 System Environments and Modes...................................................................3
4.3 User Characteristics.........................................................................................3
4.4 Operational Scenarios......................................................................................3
4.5 Standards, Procedures, and Processes Used in this Project.............................3
5.0
Functional Requirements.................................................................................3
6.0
Interface Requirements....................................................................................4
7.0
Data Management............................................................................................4
8.0
Non-Functional / Operational Requirements...................................................4
8.1 Security, Availability, Reliability, Recoverability and Businees Continuity. . .4
8.2 Maintenance and Support................................................................................4
8.3 Performance, Capacity, and Scalability...........................................................4
8.4 Technical Reviews, Audits, and Walk-Throughs.............................................5
9.0
Training............................................................................................................5
10.0 SQA Requirements..........................................................................................5
10.1 Quality Plan.................................................................................................5
10.2 Test Plan.......................................................................................................5
10.3 Testing Schedule:.........................................................................................6
10.4 Documentation Plan.....................................................................................6
10.5 Delivery, Installation, and Acceptance........................................................6
11.0 Appendices......................................................................................................6

ii

Software Requirements Document (SRD)

Sample Template

1.1.1

Introduction

Product Description: Describes why the software (or upgrade) is being developed, lists
the most important features and capabilities, and what it is intended to accomplish.
1.1.2

Team Members

List the names, titles, and roles of the project team members.

Performing Organizations and their Responsibilities: Describes the

participating organizations, and who will do what throughout the project. Includes
groups within EPRI, contractor personnel, technical experts, and plant or utility
personnel. Contact information for individuals may be included here.

Technical Management and Control: Describes the management approach that

will be used to guide the project and ensure that cost, delivery, and schedule are
met. Includes a description of rules and regulations that the project team will
follow, and procedures for tracking progress and managing variances to plan.
1.1.3

1.2

Assumptions, Constraints, Schedule and Design

Assumptions

Assumptions are statements about future situations, beyond the control of the project,
whose outcome influence the success of a project. Identify basic assumptions upon which
the specific software requirements depend such that if the assumptions change, the
requirements also change. Assumptions include:

1.3

Availability of a hardware / software platform

Developments in technology
Availability of personnel
Availability of specific equipment
Constraints

Constraints are conditions outside the control of the project that limit the design
alternatives. Describe any high level items that limit the developer's options for designing
the software such as:

Standards (including hardware and software) Imposed on the Solution

Schedule
Budget
Preferred Software Programming Language(s)
Required Development Tools
1

Software Requirements Document (SRD)

Sample Template

1.4

1.5

Handling of Security Requirements (if any)

Potential Risks
Policy and Regulation
Schedule
Tasks: Schedule of Tasks for Developing each Deliverable Item. Additional
schedule items may be needed to manage the project as work progresses.
Milestones and Deliverables: Schedule with dates of major milestones and
deliverables that result from completion of the project tasks.
Design

Typical sections for design are:

A. Introduction
B. Architecture Overview
Description
Module Decomposition Chart
Module 1 Functional Description
...
Module n Functional Description
C. Component Design
Component or Module 1
D. Name and Description
E. Function
F. Process (algorithm)
G. Interfaces
H. Data
I. Verification and Validation (V&V)
J. Quality Assurance
Test Plans and Procedures
Test Cases
K. Acceptance Plan
Installation
Acceptance Testing
Acceptance Criteria
L. Appendices
The Complete Design in Program Design Language (PDL)
Formulas and Algorithms Not Documented in the Software
Requirements Document

1.5.1

General System Description

Software Requirements Document (SRD)

Sample Template
1.6

System Context
Specify whether the software is totally self-contained or is a component of a larger
software package. Describe the functions of each component and identify the
respective interfaces

1.7

System Environments and Modes

Describe the environments the proposed system requires; such as: test, development,
production, etc. Modes could consist of recovery, standby, outage, debug, etc.
1.8

User Characteristics

Describe those characteristics of the end users that have an effect on the specific
requirements of the software. Some items to consider include:

1.9

Input display and user interface

Operator control requirements
User Operations and Practices
Operational Scenarios

Provide a descriptive example of how the system may be used as operational scenarios
(i.e., normal, operation, disaster mode, etc.) without describing how it would be designed.
5.5

Standards, Procedures, and Processes Used in this Project

This section includes documentation procedures, software coding standards or practices

to be used, reports, and review standards.
1.9.1

Functional Requirements

These requirements should describe high-level business functions performed by the

system. Each requirement should be uniquely numbered and identified for traceability.

Describe engineering algorithms and business rules to be used in general terms

Describe sources of inputs (manual data entry, read files, etc.)
Describe the range of validity of input and validation
Describe any processing requirements: such as validity checks, sequence of
operations, error handling, or responses to abnormal situations and degraded
operations
Describe the outputs required: such as report formats, plotting, etc.
Requirements Traceability Matrix: A Requirements Traceability Matrix (RTM)
helps track the requirements and features of the software throughout the software
process.

Software Requirements Document (SRD)

Sample Template
1.9.2

Interface Requirements

Specify major interfaces between system and users.

Specify descriptions of each interface, if any, between the application system and
external hardware devices as well as interfaces to other application systems.
1.9.3

Data Management

Describe the data management requirements for the system, including the primary data
sources and repositories. Also describe the data retention, archival, and warehousing.
1.9.4

Non-Functional / Operational Requirements

Describe the non-functional requirements; do not state how these requirements will be
satisfied.
1.10

Security, Availability, Reliability, Recoverability and Business Continuity

Describe the attributes of each of the topics listed

Security - describe the requirements for application system security controls; such
as authentication and authorization

Availability - System availability is the time when the application must be

available for use and times that are most acceptable for maintenance.
Reliability - Reliability is the probability that the system will be able to process
work correctly and completely without being aborted.
Recoverability - Recoverability is the ability to restore function and data in the
event of a failure and amount of time to restore functions after failure.
Business Continuity - Business continuity requirements capture the features and
actions pertaining to resumption of normal service, critical functions and
protection of data in the event of a catastrophic event.

1.11

Maintenance and Support

Describe maintenance and support requirements.

1.12

Performance, Capacity and Scalability

Describe the Static and Dynamic numerical requirements (i.e. number of
simultaneous users, size of tables, number of task/transactions to be completed
per unit time).
List the required capacities and expected volumes of major business transactions.
Estimate for at least 3-5 years. Expected volumes and capacities should be stated
in terms of current and future growth in business transactions. This input is used
to estimate the application's ability to either handle growing amounts of work or
to be readily enlarged (scalability).
4

Software Requirements Document (SRD)

Sample Template
1.13

Technical Reviews, Audits, and Walk-Through

Describe the schedule for review meetings, the description of the reviews, and the
pass/fail criteria.
1.13.1

Training

Describe training requirements for support personnel and business users.

1.13.2

SQA Requirements

1.14 Quality Plan

Software development organizations should have well-defined and documented
procedures in this area that can be referenced. Otherwise, the processes to be used are
described.

Change Control: Describes how changes to the project scope are controlled, and
who approves these.

Configuration Management: Describes how multiple development builds of the

software are tracked to avoid confusion.
Release Control: Describes pass/fail criteria for releasing software. Includes a
description of how the developer ensures that the software works properly
(verification), and that the product meets the requirements (validation).
Testing Description: Describes how the developer plans for and executes testing,
both incrementally during development and for the entire product before delivery
to EPRI. Test objectives and responsibilities are given for all testing levels, such
as testing of modules, unit testing, and integration testing.
Defect Tracking: Describes how the developer tracks and resolves software
defects.

1.15

Test Plan
Description: If the developer's approach to testing is already documented in the
Quality Plan, that description is referenced here. Otherwise, the processes to be
used are described. The following Test Plan sections contain a project-specific
description of testing for this project.
Testing Approach: A general overview of the plan for testing the entire system is
given here. Included are how each major group of software features will be tested,
major testing activities, techniques, and testing tools to be used.
Testing Tasks to be Performed: This list enables management to make decisions
on the resources and time needed for testing. Also includes the responsible
individuals or organizations.

Software Requirements Document (SRD)

Sample Template
1.16

Testing Schedule:

Includes tasks and major milestones. Milestone examples are start and end of module or
system tests, system builds, test script creation, and regression testing. These dates are
integrated into the master project schedule.
1.17

Documentation Plan

Planned Documentation: List and description of items such as user manual

(including installation instructions and solved example problems), on-line help,
programmer's manual, administrator's manual, specifications, and design
documents. For each document, the plan provides an outline or table of contents
with enough detail to support an accurate estimate of the effort required to
produce it.

Documentation Schedule: Milestones for developing and testing the

documentation, including the names of people and resources to be used. These are
integrated into the master project schedule.

1.18

Delivery, Installation, and Acceptance

Describes how the software product and associated deliverables will be accepted by EPRI
and specific end-users, and how the software will be placed into full operation. See the
EPRI software product requirements for additional required usability elements.

Installation: Describes the planned method for installation: done by the user
independently, done by customer company internal IT services, done by an
external contractor. Specifies the handling of such items as data transfer from
prior releases, and the presence of software elements from prior releases.

Usability: Describes items that will ensure the user-friendliness of the software.
Acceptance: Describe the acceptance criterion for the system to be deployed into
the production environment.
1.18.1

Appendices

As needed and may include Document References, V&V report references, etc.