Software Requirements Document Sample Template

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: Revision #:Author:Date:Revision History: Date:

Software Requirements Document (SRD)Sample Template

1.0 Introduction......................................................................................................12.0 Team Members................................................................................................13.0 Assumptions, Constraints, Schedule and Design............................................1

3.1 Assumptions....................................................................................................13.2 Constraints.......................................................................................................13.3 Schedule...........................................................................................................23.4 Design..............................................................................................................2

4.0 General System Description............................................................................24.1 System Context................................................................................................34.2 System Environments and Modes...................................................................34.3 User Characteristics.........................................................................................34.4 Operational Scenarios......................................................................................34.5 Standards, Procedures, and Processes Used in this Project.............................3

5.0 Functional Requirements.................................................................................36.0 Interface Requirements....................................................................................47.0 Data Management............................................................................................48.0 Non-Functional / Operational Requirements...................................................4

8.1 Security, Availability, Reliability, Recoverability and Businees Continuity. .48.2 Maintenance and Support................................................................................48.3 Performance, Capacity, and Scalability...........................................................48.4 Technical Reviews, Audits, and Walk-Throughs............................................5

9.0 Training............................................................................................................510.0 SQA Requirements..........................................................................................5

10.1 Quality Plan.................................................................................................510.2 Test Plan......................................................................................................510.3 Testing Schedule:.........................................................................................610.4 Documentation Plan.....................................................................................610.5 Delivery, Installation, and Acceptance........................................................6

11.0 Appendices......................................................................................................6

ii


1.0 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.

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

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

1


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.

3.4 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

4.0 General System Description

2


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

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.

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.

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.

3


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

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

4


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 Training

Describe training requirements for support personnel and business users.

10.0 SQA Requirements

10.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.

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.

10.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.

5


10.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.

10.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.

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.

10.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.

11.0 Appendices

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

6

Documents

Software Requirements Document Sample Template