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

1

Requirements Specifications Template

1.0Introduction......

2.0Team Members......

3.0Assumptions, Constraints, Schedule and Design......

3.1Assumptions......

3.2Constraints......

3.3Schedule......

4.0General System Description......

4.1System Context......

4.2System Environments and Modes......

4.3User Characteristics......

4.4Operational Scenarios......

4.5Standards, Procedures, and Processes Used in this Project......

5.0Functional Requirements......

6.0Interface Requirements......

7.0Data Management......

8.0Non-Functional / Operational Requirements......

8.1Security, Availability, Reliability, Recoverability and Business Continuity..

8.2Maintenance and Support......

8.3Performance, Capacity and Scalability......

8.4Technical Reviews, Audits, and Walk-Through......

9.0SQA Requirements......

9.1Quality Plan......

9.2Test Plan......

9.3Testing Schedule:......

9.4Documentation Plan......

9.5Delivery, Installation, and Acceptance......

10.0Appendices......

1

Requirements Specifications Template

1.0Introduction

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.0Team 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.0Assumptions, Constraints, Schedule and Design

3.1Assumptions

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.2Constraints

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.3Schedule
  • 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.0General System Description

4.1System 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.2System 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.3User 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.4Operational 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.5Standards, 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.0Functional 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.0Interface 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.0Data 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.0Non-Functional / Operational Requirements

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

8.1Security, 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.2Maintenance and Support

Describe maintenance and support requirements.

8.3Performance,Capacityand 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.4Technical Reviews, Audits, and Walk-Through

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

9.0SQA Requirements

SQA Requirements vary based on Software Type and target TRL. Before completing this section, the author should review the requirements.

9.1Quality 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.
9.2Test 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.3Testing 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.4Documentation 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.

9.5Delivery, 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.0Appendices

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

1