Software Requirements Specification

Version <4.0>
e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

Revision History
Date Version Description Author
<04/13/07> <1.0> SRS 1.0 Group-1
<04/15/07> <2.0> SRS 2.0 Group-1
<04/15/07> <3.0> SRS 3.0 Group-1
<04/16/07> <4.0> SRS 4.0 Group-1

Confidential ©<Company Name>, 2024 Page 2

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

Table of Contents
1. Introduction 5
1.1 Purpose 5
1.2 Scope 5
1.3 Definitions, Acronyms, and Abbreviations 6
1.4 References 6
1.5 Overview 6

2. Overall Description 6

3. Specific Requirements 7
3.1 Functionality 7
3.1.1 Sell Configured to Ordered Products. 7
3.1.2 Provide comprehensive product details. 7
3.1.3 Detailed product Categorizations 7
3.1.4 Provide Search facility. 7
3.1.5 Maintain customer profile. 8
3.1.6 Provide personalized profile 8
3.1.7 Provide Customer Support. 8
3.1.8 Email confirmation. 9
3.1.9 Detailed invoice for customer. 9
3.1.10 Provide shopping cart facility. 9
3.1.11 Provide multiple shipping methods. 9
3.1.12 Online tracking of shipments 9
3.1.13 Provide online Tax Calculations 10
3.1.14 Allow multiple payment methods. 10
3.1.15 Allow online change or cancellation of order. 10
3.1.16 Allow Online Product reviews and ratings 10
3.1.17 Offer financing options. 10
3.1.18 Provide detailed sitemap. 10
3.1.19 Offer online promotions and rewards. 11
3.1.20 Online Purchase of products. 11
3.2 Usability 11
3.2.1 Graphical User Interface 11
3.2.2 Accessibility 11
3.3 Reliability & Availability 11
3.3.1 Back-end Internal Computers 11
3.3.2 Internet Service Provider 11
3.4 Performance 12
3.5 Security 12
3.5.1 Data Transfer 12
3.5.2 Data Storage 12
3.6 Supportability 13
3.6.1 Configuration Management Tool 13
3.7 Design Constraints 13
3.7.1 Standard Development Tools 13
3.7.2 Web Based Product 13
3.8 On-line User Documentation and Help System Requirements 13
3.9 Purchased Components 13
3.10 Interfaces 14

Confidential ©<Company Name>, 2024 Page 3

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

3.10.1 User Interfaces 14

3.10.2 Hardware Interfaces 14
3.10.3 Software Interfaces 14
3.10.4 Communications Interfaces 15
3.11 Licensing Requirements 15
3.12 Legal, Copyright, and Other Notices 15
3.13 Applicable Standards 15

4. Supporting Information 15

Confidential ©<Company Name>, 2024 Page 4

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

Software Requirements Specification

1. Introduction

The introduction of the Software Requirements Specification (SRS) provides an overview of the
entire SRS with purpose, scope, definitions, acronyms, abbreviations, references and overview of
the SRS. The aim of this document is to gather and analyze and give an in-depth insight of the
complete Marvel Electronics and Home Entertainment software system by defining the
problem statement in detail. Nevertheless, it also concentrates on the capabilities required by
stakeholders and their needs while defining high-level product features. The detailed
requirements of the Marvel Electronics and Home Entertainment are provided in this
document.

1.1 Purpose

The purpose of the document is to collect and analyze all assorted ideas that have come up to
define the system, its requirements with respect to consumers. Also, we shall predict and sort out
how we hope this product will be used in order to gain a better understanding of the project,
outline concepts that may be developed later, and document ideas that are being considered, but
may be discarded as the product develops.

In short, the purpose of this SRS document is to provide a detailed overview of our software
product, its parameters and goals. This document describes the project's target audience and its
user interface, hardware and software requirements. It defines how our client, team and audience
see the product and its functionality. Nonetheless, it helps any designer and developer to assist in
software delivery lifecycle (SDLC) processes.

1.2 Scope

Primarily, the scope pertains to the E-Store product features for making Marvel Electronics and
Home Entertainment project live. It focuses on the company, the stakeholders and applications,
which allow for online sales, distribution and marketing of electronics.

This SRS is also aimed at specifying requirements of software to be developed but it can also be
applied to assist in the selection of in-house and commercial software products. The standard can
be used to create software requirements specifications directly or can be used as a model for
defining a organization or project specific standard. It does not identify any specific method,
nomenclature or tool for preparing an SRS.

Confidential ©<Company Name>, 2024 Page 5

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

1.3 Definitions, Acronyms, and Abbreviations

Configuration It means a product which is available / Selected from a catalogue can be customized.
FAQ Frequently Asked Questions
CRM Customer Relationship Management
RAID 5 Redundant Array of Inexpensive Disk/Drives

1.4 References
The references are:

✓ E-Store Structural Model

✓ E-Store Behavioral Model
✓ E-Store NFR Model
✓ Vision Draft 5

1.5 Overview

The remaining sections of this document provide a general description, including characteristics
of the users of this project, the product's hardware, and the functional and data requirements of
the product. General description of the project is discussed in section 2 of this
document. Section 3 gives the functional requirements, data requirements and constraints and
assumptions made while designing the E-Store. It also gives the user viewpoint of
product. Section 3 also gives the specific requirements of the product. Section 3 also discusses
the external interface requirements and gives detailed description of functional requirements.
Section 4 is for supporting information.

2. Overall Description

This document contains the problem statement that the current system is facing which is
hampering the growth opportunities of the company. It further contains a list of the stakeholders
and users of the proposed solution. It also illustrates the needs and wants of the stakeholders that
were identified in the brainstorming exercise as part of the requirements workshop. It further lists
and briefly describes the major features and a brief description of each of the proposed system.

The following SRS contains the detail product perspective from different stakeholders. It
provides the detail product functions of E-Store with user characteristics permitted constraints,
assumptions and dependencies and requirements subsets.

Confidential ©<Company Name>, 2024 Page 6

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

3. Specific Requirements

The specific requirements are –

3.1 Functionality

Introduction –

This subsection contains the requirements for the e-store. These requirements are organized by
the features discussed in the vision document. Features from vision documents are then refined
into use case diagrams and to sequence diagram to best capture the functional requirements of
the system. All these functional requirements can be traced using tractability matrix .

3.1.1 Sell Configured to Ordered Products.

3.1.1.1 The system shall display all the products that can be configured.
3.1.1.2 The system shall allow user to select the product to configure.
3.1.1.3 The system shall display all the available components of the product to configure
3.1.1.4 The system shall enable user to add one or more component to the configuration.
3.1.1.5 The system shall notify the user about any conflict in the current configuration.
3.1.1.6 The system shall allow user to update the configuration to resolve conflict in the current
configuration.
3.1.1.7 The system shall allow user to confirm the completion of current configuration

3.1.2 Provide comprehensive product details.

3.1.2.1 The system shall display detailed information of the selected products.
3.1.2.2 The system shall provide browsing options to see product details.

3.1.3 Detailed product Categorizations

The system shall display detailed product categorization to the user.

3.1.4 Provide Search facility.

The system shall enable user to enter the search text on the screen.

Confidential ©<Company Name>, 2024 Page 7

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

The system shall enable user to select multiple options on the screen to search.

The system shall display all the matching products based on the search

The system shall display only 10 matching result on the current screen.

The system shall enable user to navigate between the search results.

The system shall notify the user when no matching product is found on the search.

3.1.5 Maintain customer profile.

The system shall allow user to create profile and set his credential.

The system shall authenticate user credentials to view the profile.

The system shall allow user to update the profile information.

3.1.6 Provide personalized profile

.
The system shall display both the active and completed order history in the customer profile.

The system shall allow user to select the order from the order history.

The system shall display the detailed information about the selected order.

The system shall display the most frequently searched items by the user in the profile.

The system shall allow user to register for newsletters and surveys in the profile.

3.1.7 Provide Customer Support.

The system shall provide online help, FAQ’s customer support, and sitemap options for customer
support.

The system shall allow user to select the support type he wants.

The system shall allow user to enter the customer and product information for the support.

The system shall display the customer support contact numbers on the screen.

The system shall allow user to enter the contact number for support personnel to call.

Confidential ©<Company Name>, 2024 Page 8

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

The system shall display the online help upon request.

The system shall display the FAQ’s upon request.

3.1.8 Email confirmation.

The system shall maintain customer email information as a required part of customer profile.

The system shall send an order confirmation to the user through email.

3.1.9 Detailed invoice for customer.

The system shall display detailed invoice for current order once it is confirmed.

The system shall optionally allow user to print the invoice.

3.1.10 Provide shopping cart facility.

The system shall provide shopping cart during online purchase.

The system shall allow user to add/remove products in the shopping cart.

3.1.11 Provide multiple shipping methods.

The system shall display different shipping options provided by shipping department.

The system shall enable user to select the shipping method during payment process.

The system shall display the shipping charges.

The system shall display tentative duration for shipping.

3.1.12 Online tracking of shipments

The system shall allow user to enter the order information for tracking.

The system shall display the current tracking information about the order.

3.1.13 Provide online Tax Calculations

The system shall calculate tax for the order.

Confidential ©<Company Name>, 2024 Page 9

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

The system shall display tax information for the order.

3.1.14 Allow multiple payment methods.

.
The system shall display available payment methods for payment.

The system shall allow user to select the payment method for order.

3.1.15 Allow online change or cancellation of order.

The system shall display the orders that are eligible to change.

The system shall allow user to select the order to be changed.

The system shall allow user to cancel the order

The system shall allow user to change shipping, payment method.

The system shall notify the user about any changes made to the order.

3.1.16 Allow Online Product reviews and ratings

The system shall display the reviews and ratings of each product, when it is selected.

The system shall enable the user to enter their reviews and ratings.

3.1.17 Offer financing options.

The system shall display all the available financing options.

The system shall allow user to select the financing option.

The system shall notify the use about the financing request.

3.1.18 Provide detailed sitemap.

The system shall allow user to view detailed sitemap.

3.1.19 Offer online promotions and rewards.

The system shall display all the available promotions to the user.

Confidential ©<Company Name>, 2024 Page 10

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

The system shall allow user to select available promotion.

3.1.20 Online Purchase of products.

The system shall allow user to confirm the purchase.

The system shall enable user to enter the payment information.

3.2 Usability

3.2.1 Graphical User Interface

The system shall provide a uniform look and feel between all the web pages.

The system shall provide a digital image for each product in the product catalog.

The system shall provide use of icons and toolbars.

3.2.2 Accessibility

The system shall provide handicap access.

The system shall provide multi language support.

3.3 Reliability & Availability

3.3.1 Back-end Internal Computers

The system shall provide storage of all databases on redundant computers with automatic
switchover.

The system shall provide for replication of databases to off-site storage locations.

The system shall provide RAID V Disk Stripping on all database storage disks.

3.3.2 Internet Service Provider

The system shall provide a contractual agreement with an internet service provider for T3 access
with 99.9999% availability.

The system shall provide a contractual agreement with an internet service provider who can
provide 99.999% availability through their network facilities onto the internet.

Confidential ©<Company Name>, 2024 Page 11

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

3.4 Performance

The product shall be based on web and has to be run from a web server.

The product shall take initial load time depending on internet connection strength which also
depends on the media from which the product is run.

The performance shall depend upon hardware components of the client/customer.

3.5 Security

3.5.1 Data Transfer

The system shall use secure sockets in all transactions that include any confidential customer
information.

The system shall automatically log out all customers after a period of inactivity.

The system shall confirm all transactions with the customer’s web browser.

The system shall not leave any cookies on the customer’s computer containing the user’s
password.

The system shall not leave any cookies on the customer’s computer containing any of the user’s
confidential information.

3.5.2 Data Storage

The customer’s web browser shall never display a customer’s password. It shall always be
echoed with special characters representing typed characters.

The customer’s web browser shall never display a customer’s credit card number after retrieving
from the database. It shall always be shown with just the last 4 digits of the credit card number.

The system’s back-end servers shall never display a customer’s password. The customer’s
password may be reset but never shown.

The system’s back-end servers shall only be accessible to authenticated administrators.

The system’s back-end databases shall be encrypted.

3.6 Supportability

3.6.1 Configuration Management Tool

Confidential ©<Company Name>, 2024 Page 12

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

The source code developed for this system shall be maintained in configuration management
tool.

3.7 Design Constraints

3.7.1 Standard Development Tools

The system shall be built using a standard web page development tool that conforms to either
IBM’s CUA standards or Microsoft’s GUI standards.

3.7.2 Web Based Product

There are no memory requirements

The computers must be equipped with web browsers such as Internet explorer.
The product must be stored in such a way that allows the client easy access to it.
Response time for loading the product should take no longer than five minutes.
A general knowledge of basic computer skills is required to use the product

3.8 On-line User Documentation and Help System Requirements

As the product is E-store, On-line help system becomes a critical component of the
system which shall provide –

It shall provide specific guidelines to a user for using the E-Store system and within the
system.

To implement online user help, link and search fields shall be provided.

3.9 Purchased Components

Not Applicable

3.10 Interfaces

There are many types of interfaces as such supported by the E-Store software system namely;
User Interface, Software Interface and Hardware Interface.
The protocol used shall be HTTP.
The Port number used will be 80.

Confidential ©<Company Name>, 2024 Page 13

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

There shall be logical address of the system in IPv4 format.

3.10.1 User Interfaces

The user interface for the software shall be compatible to any browser such as Internet
Explorer, Mozilla or Netscape Navigator by which user can access to the system.
The user interface shall be implemented using any tool or software package like Java
Applet, MS Front Page, EJB etc.

3.10.2 Hardware Interfaces

Since the application must run over the internet, all the hardware shall require to connect
internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN,
Ethernet Cross-Cable.

3.10.3 Software Interfaces

1. The e-store system shall communicate with the Configurator to identify all the
available components to configure the product.
2. The e-store shall communicate with the content manager to get the product
specifications, offerings and promotions.
3. The e-store system shall communicate with billPay system to identify available
payment methods , validate the payments and process payment.
4. The e-store system shall communicate to credit management system for handling
financing options.
5. The e-store system shall communicate with CRM system to provide support.
6. The e-store system shall communicate with Sales system for order management.
7. The e-store system shall communicate with shipping system for tracking orders and
updating of shipping methods.
8. The e-store system shall communicate with external Tax system to calculate tax.
9. The e-store system shall communicate with export regulation system to validate
export regulations.
10. The system shall be verisign like software which shall allow the users to complete
secured transaction. This usually shall be the third party software system which is widely
used for internet transaction.

3.10.4 Communications Interfaces

The e-store system shall use the HTTP protocol for communication over the internet and

Confidential ©<Company Name>, 2024 Page 14

 e-Store Project Version: <3.0>
Software Requirements Specification Date: <04/15//07>
<document identifier>

for the intranet communication will be through TCP/IP protocol suite.

3.11 Licensing Requirements

Not Applicable

3.12 Legal, Copyright, and Other Notices

E-store should display the disclaimers, copyright, word mark, trademark and product
warranties of the Marvel electronics and home entertainment.

3.13 Applicable Standards

It shall be as per the industry standard.

4. Supporting Information

Please refer the following document:

1. Vision document for E-store.
2. Use case analysis.
3. Structural models.
4. Behavioral models.
5. Non functional requirements model.
6. Traceability Matrix.
7. Project Plan

Confidential ©<Company Name>, 2024 Page 15

 <Enter Project Name Here>

Requirements Specification Document

<Month><Year>
Version <#.#>
 Revision History
Date Version Description Author

Note: The revision history cycle begins once changes or enhancements are requested after the
Requirements Specification Document has been baselined.
Artifact Rationale
The Requirements Specification Document (RSD) records the results of the specification
gathering processes carried out during the Requirements phase. The RSD is generally written by
the functional analyst(s) and should provide the bulk of the information used to create the test
plan and test scripts. It should be updated for each increment.
The level of detail contained in this RSD should be consistent with the size and scope of the
project. It is not necessary to fill out any sections of this document that do not apply to the
project. The resources necessary to create and maintain this document during the life cycle of a
large project should be acknowledged and clearly reflected in project schedules. Do not duplicate
data that is already defined in another document or a section in this document; note in the section
where the information can be found.

<Project Name>
Requirements Specification Document ii <Month> <Year>
 Instructions
This template contains a style named Instructional Text. Text using this style is only to provide
guidance in completing the document – the final document should not contain Instructional Text.
Text in paragraphs added after Instructional Text is automatically set to the appropriate body
text style. For best results and to maintain formatting consistency:
• Use the provided paragraph styles
• Delete all Instructional Text before finalizing the document, including these instructions
The following project types are required to complete this artifact. Exceptions are outlined where
needed throughout the document.
Activity New Capability (1) Feature Enhancement (2)

Field Deployment
Yes Yes
(A)

Cloud/Web
Yes Yes
Deployment (B)

Mobile Application
Yes Yes
(C)

<Project Name>
Requirements Specification Document iii <Month> <Year>
 Table of Contents
Introduction ....................................................................................................................... 1
Purpose ...................................................................................................................................... 1
Scope…...................................................................................................................................... 1
References ................................................................................................................................. 1
Overall Description........................................................................................................... 1
Accessibility Specifications ........................................................................................................ 1
Business Rules Specification ..................................................................................................... 2
Design Constraints Specification ............................................................................................... 2
Disaster Recovery Specification ................................................................................................ 2
Documentation Specifications ................................................................................................... 2
Functional Specifications ........................................................................................................... 2
Graphical User Interface (GUI) Specifications .......................................................................... 3
Multi-divisional Specifications .................................................................................................... 3
Performance Specifications ....................................................................................................... 3
Quality Attributes Specification .................................................................................................. 4
Reliability Specifications ............................................................................................................ 4
Scope Integration ....................................................................................................................... 4
Security Specifications ............................................................................................................... 5
System Features ........................................................................................................................ 5
Usability Specifications .............................................................................................................. 5
Purchased Components .................................................................................................. 5
Estimation.......................................................................................................................... 5
Approval Signatures ........................................................................................................ 7
Appendix A: Non-Functional Requirements ................................................................. 8
System Performance Reporting Requirements ......................................................................... 8

<Project Name>
Requirements Specification Document iv <Month> <Year>
Introduction
Provide an introductory statement that gives a brief overview of the RSD’s purpose, scope, and
references.
Note: Users of IBM® Rational RequisitePro® should exercise caution in using the word "shall"
in this document. When documents are imported into RequisitePro, statements containing the
word "shall" are recorded as specifications.>
Purpose
This section should accomplish the following:
• Delineate the purpose of the particular RSD
• Specify the intended audience for RSD.
Scope…
Provide reference or link to Project Management Plan (PMP) and/or Business Requirements
Document (BRD) where this information is located.
References
Provide reference or link to Project Management Plan (PMP) and/or Business Requirements
Document (BRD) where this information is located.

Overall Description
The non-functional requirements in Appendix A should be reviewed and assessed while
developing the requirements for the project.
For teams utilizing the Rational Tools to manage their requirements, the following reports may
be attached in lieu of Section 2:
• Requirements Specification
• Use Cases
• Interface report
Teams not using Rational should follow the following template
Describe the general factors that affect the product and its specifications. Use the subsections
below this section to make the specifications easier to understand by providing a background
and details for those that are defined.
Accessibility Specifications
Detail the necessary 508 Compliance and Clinical Context Object Workgroup (CCOW)
standards required for accessibility to the software product(s) involved.

<Project Name>
Requirements Specification Document 1 <Month> <Year>
Business Rules Specification
A business rule defines or constrains some aspect of the business. Business rules can apply to
people, processes, corporate behavior, and computing systems in an organization and are put in
place to help the organization achieve its goals.
Examples of Business Rules:
• Schedule Types Rule
o The medication tab uses four “standard” schedule types from Inpatient
Medications V. 5.0. They are: 1) Continuous, 2) PRN, 3) On-Call, and 4) One-
Time.
Design Constraints Specification
Indicate any design constraints on the system being developed. Design constraints represent
mandated design decisions.
Examples of design constraints include CCOW compliance, software languages, software
process requirements, prescribed use of developmental tools, architectural and design
constraints, purchased components, and class libraries.
Disaster Recovery Specification
Outline what the Disaster Recovery requirements are. Reference the relevant section of the
Project Management Plan (PMP) if these have already been defined in a separate Contingency
or Disaster Recovery Plan.
For example:
• This system needs 24x7 hot failover capability.
or
• It shall take no more than 24 hours to recover from a catastrophic failure.
or
• The system needs to be decentralized to prevent impact of single system due to a
geographic event.
Documentation Specifications
Describe requirements for user documentation, help systems, help about notices, installation
guide, security guide, implementation guide, and any other forms of documentation.
Functional Specifications
Describe the functional specifications of the system in natural language style. For many
applications, this may constitute the bulk of the RSD Package.
Thought should be given to the organization of this section. It is typically organized by feature,
but alternative organization methods (e.g., organization by user or subsystem) may also be
appropriate. Functional specifications can include feature sets, capabilities, and security. These
are generally listed, as “shall” statements starting with “The system shall...”

<Project Name>
Requirements Specification Document 2 <Month> <Year>
Where requirements tools, modeling tools, and similar are employed to capture the functionality,
this section of the document will refer to the availability of that data, indicating the location and
name of the tool used.
This section of the RSD should also identify requirements that may be delayed until future
versions of the system. A broad statement of functionality that will be included in a future version
of the product is all that is necessary. Do not commit to the version in which the functionality
shall appear in case the functionality is delayed indefinitely due to unforeseen events.
Graphical User Interface (GUI) Specifications
Document the GUI specifications.
Multi-divisional Specifications
Use this section to document the multi-divisional specifications to ensure that all applications
will operate in a multi-divisional or multi-site environment while fully supporting local health
care delivery.
Examples: A single HeV-VistA instance is one code base (e.g., Java 2 Platform, Enterprise
Edition (J2EE) routines, database definitions, etc.) that runs all HeV products. One instance
needs to support the following:
• Allow multiple VA health care facilities to perform all business and patient care functions
• Capture the source where the event occurred (e.g., where the patient received a
medication, where the clinic appointment took place, where the vitals were recorded,
where the patient funds were distributed, etc.)
• Allow a user to view data across location domains according to the user’s permissions
(e.g., view data for multiple sites, wards, pharmacies, clinics, etc.)
• Filter data according to a user’s permissions (e.g., display only data for a site, ward,
pharmacy, agent cashier, etc.)
• Support multi-site operations where VA may be sharing the instance with a non-VA entity
such as Department of Defense (DoD) or the Indian Health Service (IHS)
• Not bind the allowable health care entities to be only VA (remember, HealtheVet will be
used by other entities).
Performance Specifications
This section should identify dynamic numeric specifications placed on the software or on human
interaction with the software as a whole. Numerical specifications may include:
• The number of simultaneous users to be supported
• Dynamic numeric specifications should include the numbers of transactions and tasks
and the amount of data to be processed within certain time periods for both normal and
peak workload conditions.
All of these specifications should be stated in measurable terms. For example:
• The system shall process a transaction in less than 1 second 95% of the time.
not
• An operator shall not have to wait for the transaction to complete.

<Project Name>
Requirements Specification Document 3 <Month> <Year>
Quality Attributes Specification
Indicate any specifications that enhance the supportability, maintainability, portability,
testability, or reusability of the system/project being developed. Include coding standards,
naming conventions, class libraries, maintenance access, and maintenance utilities that are not
already documented in the project’s Quality Assurance Plan.
Reliability Specifications
Specify the level of reliability required of the system. The following list contains suggestions for
specifications.
• Availability – Specify percentage of time available (xx.xx%), hours of use, maintenance
access, degraded mode operations, and similar.
• Mean Time Between Failures (MTBF) – This is usually specified in hours, but it could
also be specified in terms of days, months or years.
• Mean Time To Repair (MTTR) – How long the system is allowed to be out of operation
after it has failed.
• Accuracy – Specify precision (resolution) and accuracy (by a known standard) that is
required in the systems output.
• Maximum bugs or defect rate – This is usually expressed in terms of bugs/KLOC
(thousands of lines of code), or bugs/function point.
• Bugs – This is categorized in terms of minor, significant, and critical bugs: the
specification(s) must define what is meant by a “critical” bug. For example, complete
loss of data or complete inability to use certain parts of the functionality of the system.
Scope Integration
This section of the RSD should put the product into perspective with other related products. If
the product is independent and completely self-contained, it should be so stated here. If the RSD
defines a product that is a component of a larger system, as frequently occurs, then this section
should relate the specifications of that larger system to functionality of the software and should
identify interfaces between that system and the software.
This section should also specify the use of other required software products (for example,
MUMPS Kernel, FileMan, Windows NT); and interfaces with other applications or other systems
such as commercial off-the-shelf (COTS) or national databases. Specify the application
interfaces (e.g., the linkage between an accounts receivable system and a general ledger system
or a COTS device that will be interfaced using an existing interface). For each required software
product, the following should be provided:
• Integration Agreement (IA) number as appropriate
• Product name
• Version number
• Discussion of the purpose of the interfacing software as related to this software product
• Definition of the interface in terms of message content and format (HL7, Electronic Data
Interchange, etc.)
A block diagram showing the software interfaces and major components of the larger system,
interconnections, and external interfaces can be helpful.

<Project Name>
Requirements Specification Document 4 <Month> <Year>
Security Specifications
Document the security specifications to ensure that the planned or existing specifications and
controls are fully documented and understood. Use the business requirements provided by the
business owner and the enterprise-level Requirements Project Allocation Report (PAR) to
document the security specifications.
System Features
Each feature description should include a sequence of inputs and outputs. It is also highly
recommended that system and functional specification names be selected with an eye to the
consistency of their use in subsequent documents such as the Systems Design Document (SDD).
Usability Specifications
Include specifications that affect usability. The following list contains examples of usability
specifications:
• Training – Specify time required for a normal users and power users to become
productive
• Performance measures – Specify task times for typical tasks
• Specifications to conform to common usability standards – Specify standards such as
those for IBM Common User Access (CUA) or Microsoft® GUI

Purchased Components
Describe any components purchased for use in the system/project, any applicable licensing or
usage restrictions, and any associated compatibility/interoperability or interface standards.

Estimation
Detail the estimation approach for the project.
If the project chooses to use function point estimation, the Function Point Estimate Workbook
must be completed to support the summary information in this section. After the workbook has
been completed, the data in the Application Estimate sheets must be entered in this section.
For projects that require development in multiple products, the total estimated function points
are calculated as the sum of each product’s estimated function points.
Instructions
• Contact The VA Office of Information and Technology (OIT) Product Development (PD)
Process, Performance, and Oversight (PPO) Project Estimation Support to request an
RSD-based Function Point Estimate
• Request to have a results summary returned in the format of the following table.

<Project Name>
Requirements Specification Document 5 <Month> <Year>
 Project Software Functional Size and Size-Based Effort and Duration Estimate
Application
Item A B C D E Total
Counted Function
Points
Estimated Scope
Growth
Estimated Size at
Release

Size-Based Effort Estimates Labor Hours Probability

Low-Effort Estimate – With indicated probability, project will consume
no more than:
High-Effort Estimate – With indicated probability, project will consume
no more than:

Size-Based Duration Estimates Work Days Probability

Low-Duration Estimate – With indicated probability, project will
consume no more than:
High-Duration Estimate -- With indicated probability, project will
consume no more than:

Figure 1: Cumulative Probability (“S-curve”) Chart

[Insert Cumulative Probability (“S-curve”) Charts here]

<Artifact name> 6 <Month> <Year>

Approval Signatures
This section is used to document the approval of the RSD during the Formal Review. The review
should be ideally conducted face to face where signatures can be obtained ‘live’ during the
review, however the following forms of approval are acceptable:
Physical signatures obtained face to face or via fax
Physical signature obtained in person or via fax
Digital signature tied cryptographically to the signer
/es/ in the signature block, provided that a separate digitally signed e-mail indicating the
signer’s approval is provided and kept with the document
The Chair of the governing Integrated Project Team (IPT), Business Sponsor, IT Program
Manager, and the Project Manager are required to sign. Please annotate signature blocks
accordingly.>

REVIEW DATE: <date>

SCRIBE: <name>

Signed:

Integrated Project Team (IPT) Chair Date

Business Sponsor Date

IT Program Manager Date Date

Project Manager Date

Project Name>
Requirements Specification Document 7 <Month> <Year>
Appendix A: Non-Functional Requirements
The following non-functional requirements should be reviewed and assessed while developing
the requirements for the project.
System Performance Reporting Requirements
(Note: Each system developed by the Department of Veterans Affairs (VA) Office of
Information and Technology (OIT) must comply with the following mandatory requirements.)
1. Include instrumentation to measure all performance metrics specified in the Non-
Functional Requirements section of the Requirements Traceability Matrix (RTM). At a
minimum, systems will have the ability to measure reporting requirements for
Responsiveness, Capacity, and Availability as defined in the non-functional requirements
section of the RTM.
2. Make the performance measurements available to the Information Technology (IT)
Performance Dashboard to enable display of “actual” system metrics to customers and IT
staff.
Operational Environment Requirements
1. System response times and page load times shall be consistent with ___________
standards (for example, My HealtheVet or HealtheVet). (Comment: There may be
different expectations for an external display vs. a query. Need to address these different
uses. Also indicate if this information is unknown).
2. Maintenance, including maintenance of externally developed software incorporated into
the _____________application(s), shall be scheduled during off peak hours or in
conjunction with relevant maintenance schedules. The business owner should provide
specific requirements for establishing system maintenance windows when planned
service disruptions can occur in support of periodic maintenance.
3. Information about response time degradation resulting from unscheduled system outages
and other events that degrade system functionality and/or performance shall be
disseminated to the user community within 30 minutes of the occurrence. The
notification shall include the information described in the current Automated Notification
Reporting (ANR) template maintained by the VA Service Desk. The specific business
impact must be noted in order for OIT to provide accurate data in the service impact
notice of the ANR.
4. Provide a real-time monitoring solution to report agreed/identified critical system
performance parameters.
5. Critical business performance parameters shall be identified e.g., transaction speed,
response time for screen display/refresh, data retrieval, etc. in a manner that data capture
can occur to support metric reporting and support the OIT performance dashboard
display. If no such performance metrics are required or provided there will be no program
specific Service Level Agreements (SLA) created, nor shall there be any active/real time
monitoring through OIT Performance Dashboard to provide the business owners any
performance metrics.

Project Name>
Requirements Specification Document 8 <Month> <Year>
 6. Notification of scheduled maintenance periods that require the service to be offline or
that may degrade system performance shall be disseminated to the business user
community a minimum of 48 hours prior to the scheduled event.
Documentation Requirements
1. The training curriculum shall state the expected training time for primary users and
secondary users to become proficient at using the ____________ application(s).
2. All training curricula, user manuals and other training tools shall be developed/updated
by ______ <<insert name of Program Office>> and delivered to all levels of users
________________. If known, insert how much time in advance the training tools will be
delivered and via what mechanism(s); for example, 2-4 weeks in advance of the release
of the enhancement through nationwide conference calls and PowerPoint presentations).
The curricula shall include all aspects of the enhanced ________ application(s) and all
changes to processes and procedures.
3. The training curriculum developed by the Program Office shall state the expected task
completion time for primary and secondary users.
4. User manuals and training tools shall be developed. If they already exist, updates shall be
made, as necessary, to them and they shall be delivered to all levels of users.
5. IT will provide the level of documentation required to support the system and maintain
operations and continuity. Documentation shall represent minimal programmatic and
lifecycle operations support documentation artifacts as defined by VA standards in the
PAL and as required by the VA Enterprise System Engineering Lifecycle and Release
Management office for sustained operations, maintenance, and support
(http://vaww.eie.va.gov/lifecycle/default.aspx) prior to approval by any VA change
control board and release into production.
Implementation Requirements
1. Technical Help Desk support for the application shall be provided for users to obtain
assistance with ___________.
2. The IT solution shall be designed to comply with the applicable approved Enterprise
SLA.
3. The implementation must be complete by __________. (Enter date - dd-mm-yyyy)
Data Protection/Back-up/Archive Requirements
1. Based upon the criticality of the system, provide a back-up and data recovery process for
when the system is brought off-line for maintenance or technical issues/problems.
2. Data protection measures, such as back-up intervals and redundancy shall be consistent
with systems categorized as routine (30 day restoration), mission essential (72 hour
restoration), or mission critical (12 hour restoration).
Business owners are required to state the mission criticality of the IT services required in
order to assist the planners and developers in determining best strategies for engineering
an IT solution to meet their business objectives/needs. The business owner needs to state
the criticality of the data and the impact to the business during a service disruption so
appropriate technologies can be considered.

Project Name>
Requirements Specification Document 9 <Month> <Year>
Levels for Disaster Recovery
Classification Recovery Time Objective Recovery Point
Objective Routine 30 day restoration TBD
Mission Essential 72 hour restoration 24 hours
Mission Critical 12 hour restoration 2 hours

Recovery Time Objective (RTO) – RTO defines the maximum amount of time that a system
resource can remain unavailable before there is an unacceptable impact on other system
resources, supported mission/business processes, and the MTD.
Maximum Tolerable Downtime (MTD) - The MTD represents the total amount of time the
system owner/authorizing official is willing to accept for a mission/business process outage or
disruption and includes all impact considerations.
Recovery Point Objective (RPO) - The RPO represents the point in time, prior to a disruption or
system outage, to which mission/business process data can be recovered (given the most recent
backup copy of the data) after an outage.
Data Quality/Assurance Requirements
A monitoring process shall be provided to ensure that data is accurate and up-to-date and
provides accurate alerts for malfunctions while minimizing false alarms.
User Access/Security Requirements
Ensure the proposed solution meets all Veterans Health Administration (VHA) Security, Privacy,
and Identity Management requirements including VA Handbook 6500 (see the Enterprise
Requirements section of the RTM).
Usability/User Interface Requirements
Adhere to good User Interface/User Centered Design (UI/UCD) principles as outlined in the
Usability Appendix of the BRD.
Conceptual Integrity
Provide standards based messaging and middleware infrastructure needed to support both
Legacy Veterans Health Information Systems Technology Architecture (VistA) and future VistA
4 deployments.
Availability
1. Maintenance window, including maintenance of externally developed software
incorporated into the VistA 4 application(s), will be by mutual agreement between OIT
and the VHA Point of Contact (POC) for the affected facility(ies). VHA will provide
POCs for each facility.
2. VistA application unavailability due to an unplanned outage or planned outages that
exceed the defined maintenance window will not exceed 8.76 hours per year and will not
exceed 43.8 minutes per month (99.9% availability).
3. The application shall be available 24 hours a day, seven days a week, with an uptime of
99.9%.
Project Name>
Requirements Specification Document 10 <Month> <Year>
 4. All system updates and scheduled maintenance should occur between the hours of 1800
and 0600 (per local time zone), when clinical usage would be lightest.
Interoperability
1. The system shall support all recognized health system standards i.e., Health Level 7
(HL7), Fast Healthcare Interoperability Resources (FHIR).
2. Systems must be heterogeneous and agnostic for operating systems and code bases.
3. Provide the ability to securely transfer large files (of 4-8 gigabyte) from an external
source to VA systems.
4. Provide access to the system over a remote access solution.
Manageability
Provide Service Desk/Incident and Problem Management tracking related to maintenance events
of patient care systems with priority over non-patient care systems.
1. Provide data related to maintenance events, both routine and exceptional, including key
metadata:
• Predicted routine work
• Occurrences where maintenance is completed, including restart from down time
• Identity of the organization performing maintenance
• User performing maintenance (if available)
• Identity of the system
• Date/time, physical location
• Systems impacted
• Does it affect patient care
• Non-urgent or emergent
2. Provide audit capabilities for system access and usage with settings that are configurable
to support internal and external audits based on federal and VHA mandates.
3. The system must comply with VA Directive 6300 Records and Information Management
and with VHA Records Control Schedule (RCS) 10-1, in general and specifically with
Electronic Final Version of Health Record: Destroy/Delete 75 years after last episode of
patient care, or longer (if specified).
Performance
1. Provide an Infobutton Query Responder on all platforms with a response time of less than
.5 seconds.
2. The system shall recognize, report, and retransmit data lost, with less than 0-1% chance
of incomplete patient records.
3. Provide patient data (for data within the system) transactions (e.g., capture, search,
request for data) within .5 seconds.

Project Name>
Requirements Specification Document 11 <Month> <Year>
 4. Mouse or key-based UI controls, e.g., menus, checkboxes shall provide instantaneous
responsiveness (<90ms).
5. Part-screen refreshes after user action shall complete within a pro-rated interval between
200 ms and 1200 ms times a percentage of the screen area being refreshed. For example,
a component 10% of the screen area would refresh in (1200 – 200) * 0.10 + 200 = 300
ms.
Reliability
1. Provide system reliability:
• Threshold = 99.9%
• Objective = 99.99% system and application
2. Provide system reliability:
• Level 1 severity =<1 failure per month
• Level 2 severity =<2 failures per month
• Level 3 severity =<3 failures per month
Security
Provide management of electronic attestation of information including the retention of the
signature of attestation (or certificate of authenticity) associated with incoming or outgoing
information.
Supportability
1. Provide alerts (that extend beyond system messages to external systems like mobile
devices) for malfunctions, while preventing false alarms for local, regional, and national
evaluations in real time.
2. Provide reports on performance metrics as specified in the VistA 4 Effectiveness and
Value / Benefits Framework on a bi-weekly basis.
3. Provide national, regional, and local reports on performance metrics as specified in the
VistA 4 Effectiveness and Value / Benefits Framework.
4. Provide performance metrics (from request for information to receipt of information on
the screen) monitored by the system and system administrators so they know what the
user experience is like without users having to call them and tell them the system is
running very slow.
5. Provide the ability for VHA and IT staff to create standard and ad-hoc reports of usage,
bandwidth, response time, login time, and other variables with a verification process for
measuring the capabilities of the system.
6. Provide end-user training on how to generate the various system performance reports
(e.g., in standard file formats such as Comma Separated Values [CSV], Portable
Document Format [PDF], or Excel) depending on the user's needs.
7. Provide the ability to view system statistics (e.g., information on the specific network
environment) and identify areas that are having issues or are beyond capacity, in near-
real-time (to be quantified at a later time).
Project Name>
Requirements Specification Document 12 <Month> <Year>
 8. Technical Help Desk support for the application via instant message, on-line, phone, and
remote desktop access support, shall be provided for users to obtain assistance 24/7.
9. The IT solution shall be designed to comply with the applicable approved Enterprise
SLAs.
10. Data protection measures, such as back-up intervals and redundancy shall be consistent
with systems categorized as mission critical (1hr restoration, 2hrs backup recovery).
Impact of system failure must be monitored on a near real time basis.
11. Provide the ability to set thresholds and notification type (e.g., email or text alerts) when
alerting the user about response time degradation and unscheduled outages.
12. Disaster Recovery Plans (DRP) and Continuity of Operations Plan (COOP) will be
updated and tested semi-annually to address the VistA 4 product (see National Security
and Homeland Security Presidential Directive: National Continuity Policy. NSPD-
51/HSPD-20, May 9, 2007.
Usability
1. Provide viewability/usability of VistA 4 applications on mobile devices.
2. User prompts and screen help shall be embedded into the system to guide use of the
solution.
Documentation
1. The training curriculum shall be provided in two hours or more of training time for
primary users and secondary users to become proficient at using the VistA 4
application(s).
2. All training curricula, user manuals and other training tools shall be developed/updated
by the VE Program Office and delivered to all levels of users 4 weeks in advance of the
release of the enhancement through mediums that will best support the sharing of
information to all affected staff.
3. Provide follow-up training classes tailored to VHA workflow 4 weeks after the users
have begun to use the system.
The Template Revision History Page should be deleted when creating the RSD.
Template Revision History
Date Version Description Author
February 2023 1.9 Replaced all references to ProPath with Quality Continuous
PAL Improvement
Organization (QCIO)
November 2015 1.8 Corrected instructions in Appendix A Process
Management
September 2015 1.7 Updated Headings and spacing to Process
conform with latest OIT Documentation Management
Standards guidelines

Project Name>
Requirements Specification Document 13 <Month> <Year>
 Date Version Description Author
June 2015 1.6 Updated to conform with latest Section Process
508 guidelines and remediated with Management
Common Look Office tool
May 2015 1.5 Revised by the PMAS Process PMAS Process
Improvement Lockdown Team Improvement
Lockdown Team
December 2014 1.4 Updated to conform with latest Section Process
508 guidelines and remediated with Management
Common Look Office tool
May 2014 1.3 Reordered cover page to enhance Process
search capabilities Management
May 2013 1.2 Add Appendix for acronyms and Process
glossary Management
March 2013 1.1 Formatted to current ProPath Process
documentation standards and edited to Management
conform with latest Alternative Text
(Section 508) guidelines
January 2013 1.0 Initial Version PMAS Business
Office

Place latest revisions at top of table.

The Template Revision History pertains only to the format of the template. It does not apply to
the content of the document or any changes or updates to the content of the document after
distribution.
The Template Revision History can be removed at the discretion of the author of the document.
Remove blank rows.

Project Name>
Requirements Specification Document 14 <Month> <Year>