Requirements Specifications Template
This document is intended to be a guide to capture the work completed from the Concept
phase through the Requirements phase of the development process following the EPRI
Software Development Process.
Instructions:



Please elaborate on each subject.
If a topic is not applicable to your software, please enter “Not Applicable.”
Submission and review requirements vary from Software Type & Technical
Readiness Level (TRL) – refer to the EPRI Software Development Guidelines for
the appropriate process.
Software Name:
Author:
Date:
Revision History:
Revision #:
Date:
Requirements Specifications 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 ...................................................................................................... 2
3.3 Schedule .......................................................................................................... 2
4.0 General System Description ............................................................................... 2
4.1 System Context ............................................................................................... 2
4.2 System Environments and Modes ................................................................... 2
4.3 User Characteristics ........................................................................................ 2
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 ....................................................................................... 3
7.0 Data Management ............................................................................................... 3
8.0 Non-Functional / Operational Requirements ..................................................... 3
8.1 Security, Availability, Reliability, Recoverability and Business Continuity.. 3
8.2 Maintenance and Support ............................................................................... 4
8.3 Performance, Capacity and Scalability ........................................................... 4
8.4 Technical Reviews, Audits, and Walk-Through ............................................. 4
9.0 SQA Requirements .............................................................................................. 4
9.1 Quality Plan .................................................................................................... 4
9.2 Test Plan.......................................................................................................... 5
9.3 Testing Schedule: ............................................................................................ 5
9.4 Documentation Plan ........................................................................................ 5
9.5 Delivery, Installation, and Acceptance ........................................................... 6
10.0 Appendices ...................................................................................................... 6
ii
Software Requirements Document (SRD)
Sample Template
1.0 Introduction
Product Description:

Describe why the software (or upgrade) is being developed,

List the most important features and capabilities,

What is the software project intended to accomplish (e.g., Discuss Technical
Readiness Level (TRL) assessment, etc.)
This section should also summarize the decision to develop software of a particular type.
For many software types, certain sections are not applicable.
2.0 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.
3.0 Assumptions, Constraints, Schedule and Design
3.1 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:




Availability of a hardware / software platform
Developments in technology
Availability of personnel
Availability of specific equipment
1
Requirements Specifications Template
3.2 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
Handling of Security Requirements (if any)
Potential Risks
Policy and Regulation
3.3 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.
4.0 General System Description
4.1 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
4.2 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.
4.3 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:



Input display and user interface
Operator control requirements
User Operations and Practices
2
Requirements Specifications Template
4.4 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.
4.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.
5.0 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.
6.0 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.
7.0 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.
8.0 Non-Functional / Operational Requirements
Describe the non-functional requirements; do not state how these requirements will be
satisfied.
8.1 Security, Availability, Reliability, Recoverability and Business Continuity
Describe the attributes of each of the topics listed
3
Requirements Specifications Template

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.
8.2 Maintenance and Support
Describe maintenance and support requirements.
8.3 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).
8.4 Technical Reviews, Audits, and Walk-Through
Describe the schedule for review meetings, the description of the reviews, and the
pass/fail criteria.
9.0 SQA Requirements
SQA Requirements vary based on Software Type and target TRL. Before completing this
section, the author should review the requirements.
9.1 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.
4
Requirements Specifications Template

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.
9.2 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.
9.3 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.
9.4 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.
5
Requirements Specifications Template

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.
9.5 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.
10.0 Appendices
As needed and may include Document References, V&V report references, etc.
6