Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 1 / 20

Thank-you for downloading the

Software Requirements Specifications
Template!

More templates to download on the:

Templates Repository for Software

Development Process (click here)
Or paste the link below in your browser address bar:
http://blog.cm-dm.com/pages/Software-Development-Process-templates

This work is licensed under the:

Creative Commons Attribution-NonCommercial-NoDerivs 3.0
France License:
http://creativecommons.org/licenses/by-nc-nd/3.0/fr/

Waiver:
You can freely download and fill the templates of blog.cm-dm.com, to
produce technical documentation. The documents produced by filling the
templates are outside the scope of the license. However, the modification
of templates to produce new templates is in the scope of the license and is
not allowed by this license.

To be compliant with the license, I suggest you to keep the

following sentence at least once in the templates you store, or
use, or distribute:
This Template is the property of Cyrille Michaud License terms: see
http://blog.cm-dm.com/post/2011/11/04/License

Who am I? See my linkedin profile:

http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 2 / 20

TABLE OF CONTENTS
1 INTRODUCTION 3
1.1 Document overview 3
1.2 Abbreviations and Glossary 3
1.2.1 Abbreviations 3
1.2.2 Glossary 3
1.3 References 3
1.3.1 Project References 3
1.3.2 Standard and regulatory References 3
1.4 Conventions 3
2 REQUIREMENTS 5
2.1 States 5
2.2 Functionalities and Performance 5
2.3 Security, and privacy protection 6
2.3.1 Security monitoring 7
2.3.2 Personal Data 7
2.4 User maintenance 8
2.5 Usability and human-factors engineering 8
2.5.1 Man machine interface layout 8
2.5.2 Help 10
2.6 Regulatory requirements 10
2.7 System environment 10
2.8 External interfaces 11
2.8.1 Hardware interfaces 12
2.8.2 Network interfaces 12
2.8.3 Data exchange 13
2.9 Resources 13
2.9.1 Hardware resources 13
2.9.2 Software resources 14
2.10 Internal data 14
2.11 Configuration or Adaptation 14
2.12 Verification 14
2.13 Personnel and training 14
2.14 Packaging and installation 15
2.15 Software updates 15
2.16 Decommissioning – uninstallation 16
2.17 Secure operations guidelines 16
3 REQUIREMENTS TRACEABILITY 18
4 CYBERSECURITY CONTROLS TRACEABILITY 19
5 CRITICAL REQUIREMENTS 20

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 3 / 20

1 INTRODUCTION

1.1 Document overview

This document presents the software requirements specifications of XXX software development
project.
It describes:
 Requirements of functionalities, performances, interfaces, environment …
 Tests principles and definitions of validation methods of requirements,
 The compliance of requirements to customer needs,
 The relative importance and precedence of requirements

1.2 Abbreviations and Glossary

1.2.1 Abbreviations
Add here abbreviations

1.2.2 Glossary
Add here words definitions

1.3 References

1.3.1 Project References

# Document Identifier Document Title

[R1] ID Add your documents references.
One line per document
For example a statement of work, a user interface mock-up …

1.3.2 Standard and regulatory References

# Document Identifier Document Title

[STD1 Add your documents references.
] One line per document
For example: ISO 13485, ISO 14971, IEC 62304, and so on

1.4 Conventions
Requirements listed in this document are constructed according to the following structure:

Requirement ID SRS-XXX-000

Title Title of XXX-000 requirement

Description Description of XXX-000 requirement
Version Version of XXX-000 requirement

Example:

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 4 / 20

Requirement ID SRS-GUI-010

Title Main Window Background Color

Description The background color of the main window is grey RGB(192,192,192)
Version V1.0

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 5 / 20

2 REQUIREMENTS
Note : have a look at http://en.wikipedia.org/wiki/Requirement, article in wikipedia. It’s well
written and the links at the bottom are useful.

2.1 States
Optional. This section is more relevant for embedded software. For standalone software (SaMD)
it can be deleted if you think it’s not useful.
FOO software works in three states:
 Starting: the software loads its components;
 In use: all the functionalities of the software are available to the users;
 Stopping: the software is being stopped.
 Maintenance: the software is in maintenance mode
 Updating: the software is being updated
 And so on …
Add a diagram with states and transitions if necessary

2.2 Functionalities and Performance

This is the core of your SRS. It contains the purpose of your software expressed in technical
requirements

You may organize this part in sub-sections like:

 Module 1
o Function 1.1
o Function 1.2
o …
 Module 2
o …
 Module 3
o …
 (and so on)
Or sub-sections like:
 Function 1
o Sub-Function 1.1
o Sub-Function 1.2
o …
 Function 2
o …
 Function 3
o …
 (and so on)
Choose your own structure which best fits your needs.

Requirements shall not be vague. They shall be understandable and testable.

Ask yourself “How am I going to test this?” when you write a requirement
Examples of requirement:
Requirement ID SRS-XXX-010 SAMPLE

Title Sample requirement about a function

Description FOO software shall compute the zzz parameters with the a, , c and d input

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 6 / 20

parameter, with the use of the XXX algorithm.

Version V1.0

Requirement ID SRS-XXX-020 SAMPLE

Title Sample requirement about a function

Description FOO software shall save the result of computations in boo-bar format.
Version V1.0

2.3 Security, and privacy protection

This section is about software features like confidentiality, integrity control, reliability, and
availability. You can add subsections on:
Confidentiality, integrity, availability
Virus, malware protection
Operational security

See CyberSecurity requirements of FDA: https://www.fda.gov/medical-devices/digital-health-

center-excellence/cybersecurity

See also MDS2 document : https://www.nema.org/standards/view/manufacturer-disclosure-

statement-for-medical-device-security This document contains general security requirements,
to be refined to the context of your product.

For paid documentation, see IEC/TR 60601-4-5: This document also contains general security
requirements, to be refined to the context of your product.

See also secure operations guidelines at the end of this document.

Requirement ID SRS-SEC-030 SAMPLE

Title Two factors authentication

XXX connection shall be confirmed with two factor authentication.
Authorized factors are:
Description
 Text message confirmation,
 Authentication app.
Version V1.0

Requirement ID SRS-SEC-030 SAMPLE

Title Patient data

Description XXX stores patient data with a checksum to ensure their integrity.
Version V1.0

Requirement ID SRS-SEC-030 SAMPLE

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 7 / 20

Title Password protected functions

The following functions are protected by password:
 Configuration
Description
 Firmware update

Version V1.0

Requirement ID SRS-SEC-030 SAMPLE

Title Antivirus – antimalware

XXX software shall run with an antivirus / antimalware present on the
Description
target PC.
Version V1.0

2.3.1 Security monitoring

This section is about software features allowing users or administrators the monitoring of
software security.
Requirement ID SRS-SEC-030 SAMPLE

Title Audit logs

XXX software stores in audit logs the following information:
 Failed user login attempts,
 Failed 3rd party software connection attempts,
Description
 Changing user rights,
 Moving file from private to public repository
 …
Version V1.0

Requirement ID SRS-SEC-030 SAMPLE

Title Audit logs aggregation

XXX software shall be able to send audit logs to a SIEM log aggregator
Description
Version V1.0

2.3.2 Personal Data

This section is about management of personal data to be compliant with regulations.
See HIPAA requirements
See also 2016/679 GPDR in Europe, especially articles 15 to 22 and the following article:
https://blog.cm-dm.com/post/2018/04/18/Update-of-SRS-and-SAD-templates-for-GDPR

Requirement ID SRS-SEC-130 SAMPLE

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 8 / 20

Title Right to forget

XXX software has a function to delete all patient data. The deletion is
Description
permanent and not reversible
Version V1.0

2.4 User maintenance

Maintenance functions accessible by users or by administrators. Add sub-sections if there are
different types of users.
Requirement ID SRS-MNT-040 SAMPLE

Title Application logs

XXX generates a log file containing:
 The state of the application and the steps performed to reach that
Description
state,
 The possible error logs, if any.
Version V1.0

Requirement ID SRS-MNT-140 SAMPLE

Title Idle software when cleaning the device

XXX can be put in idle state by the user to clean the touchscreen with
swipes.
Description
Exit of idle state is automatic after TTT seconds
.
Version V1.0

2.5 Usability and human-factors engineering

The requirements here may have traceability with the results of IEC 62366-1 standard
implementation or human factors FDA guidance document.

2.5.1 Man machine interface layout

The layout of XXX is ….
Instead of a dozen of text requirements, diagrams and drawings can me much more convenient:
 A mock-up of the software GUI,
 State-transition GUI diagrams made with tools like Figma.

Add only requirements for which a description of layout/behaviour is necessary and/or

requested by some user feedback or a high level GUI or product specification.
If your software doesn’t contain an GUI (e.g.: only REST APIs), leave this section blank.

Requirement ID SRS-GUI-050 SAMPLE

Title Menu items and other widgets

Description XXX software has the following items:

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 9 / 20

 Menu file ...

 Widgets in the main window (slider, button, radiobutton, textfield).

Version V1.0

You can also specify GUI with the following items (thanks LLM to give me this list):
 Visual Design:
o Color scheme and aesthetics
o Typography and font choices
o Use of whitespace and layout
o Visual hierarchy and emphasis
 Interactivity:
o Hover effects and animations
o Click/tap feedback
o Drag-and-drop functionality
o Gestures (for touch interfaces)
 Accessibility:
o Color contrast for readability
o Screen reader compatibility
o Keyboard navigation support
o Resizable text and scalable interface
 Consistency:
o Uniform design patterns across the interface
o Standardized icons and symbols
o Consistent placement of common elements
 Feedback and Status:
o Loading indicators
o Progress bars
o Tooltips and help text
o Error messages and notifications
 Customization:
o Theming options
o User preferences and settings
o Adaptability to different screen sizes and orientations
 Localization:
o Support for multiple languages
o Culturally appropriate icons and symbols
o Date, time, and number format adaptations
 Performance:
o Responsiveness and load times
o Smooth animations and transitions
o Efficient use of system resources
 Integration:
o Compatibility with operating system conventions
o Integration with other applications or services
o Support for system-wide features (e.g., dark mode)
You can also describe GUI characteristics in a separate document outside SRS (put simply the list
in a new document). That document may be referenced here and in the usability file.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 10 / 20

2.5.2 Help
The user guide is always very important for medical devices. It may be online, in this case add
requirements here about the online help ….
See also e-IFU regulation: https://eur-lex.europa.eu/eli/reg_impl/2021/2226/oj
If your software doesn’t contain an GUI (e.g.: only REST APIs), it may still output some pdf
document with a specific request.

Requirement ID SRS-HLP-060 SAMPLE

Title Online user guide

Description XXX contains an online user guide accessible in the Help/About window
Version V1.0

2.6 Regulatory requirements

Regulations can have an impact on software design. For example, this is the case with the Unique
Device Identification (UDI).
An about window is a good way to identify software version and provide a UDI….
If your software doesn’t contain an GUI (e.g.: only REST APIs), it may still output a text or image
with a specific request.

Requirement ID SRS-REG-070 SAMPLE

Title About XXX

XXX shall display an “About…” window. This window displays:
 The current version of the application,
 The UDI,
Description
 The manufacturer name and address with “black factory”
pictogram,
 …
Version V1.0

In Europe the CE Mark may be somewhere in the GUI:

If your software doesn’t contain an GUI (e.g.: only REST APIs), it may still output an image with a
specific request.

Requirement ID SRS-REG-075 SAMPLE

Title CE Mark
XXX shall display the CE Mark in the “About…” window.
Description
The CE Mark is displayed with the 4-digits number of the notified body
Version V1.0

2.7 System environment

If software is integrated in a specific system, describe briefly the system and add specific
requirements for the integration of your software in this system

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 11 / 20

Warning: for PEMS/Electro-medical Devices with a HW system architecture, a system

architecture document is necessary to describe the system/software architecture.

Example with a system, which is not a medical device:

Requirement ID SRS-ENV-080 SAMPLE

Title Host System

XXX is a module integrated in <MyBigHealthSystem>.
Description
MyBigHealthSystem exposes services used by XXX.
Version V1.0

Note: <MyBigHealthSystem> services are described in <MyBigHealthSystem> architecture

documentation ref XXX.

Example with a mobile platform:

Requirement ID SRS-ENV-080 SAMPLE

Title Mobile platform

XXX is mobile app running on the following platforms:
 ApricotOS
Description
 RobotOS

Version V1.0

Example with cloud-based system:

Requirement ID SRS-ENV-080 SAMPLE

Title Host System

XXX is a cloud-based application on THEFANCYGAFAM.
THEFANCYGAFAM exposes services used by XXX:
 NoSQL Database,
Description
 Web server,
 …

Version V1.0

Note: These services are described in the architecture documentation.

2.8 External interfaces

This section describes hardware and software interfaces of the software in the system.
You can also Use the IRS-IDD document to describe interfaces requirements specifications and
detailed design specifications.

Requirement ID SRS-INT-090 SAMPLE

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 12 / 20

Title REST API

XXX exposes REST APIs for xxxx
Description
Version V1.0

Requirement ID SRS-INT-090 SAMPLE

Title DICOM node

XXX exposes a DICOM node with the following characteristics: xxx
Description
Version V1.0

2.8.1 Hardware interfaces

For PEMS/Electro-medical Devices, add requirements about integration of software and
hardware.
This is less relevant for software running on an OS, which masks the underlying hardware. In
this case, such requirements could be at product level.

Requirement ID SRS-INT-090 SAMPLE

Title Pressure Sensor

XXX receives data from the pressure sensor from serial port #nn
Description
Version V1.0

2.8.2 Network interfaces

Also add here communication and networks items, like wired network, wireless, Bluetooth …
This is less relevant for software running on an OS, which masks the underlying hardware. In
this case, such requirements could be at product level.

Requirement ID SRS-NET-090 SAMPLE

Title Wireless communication

XXX shall be able to communicate over the zigbee channel the following
information:
 Status,
Description
 Battery level,
 …

Version V1.0

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 13 / 20

2.8.3 Data exchange

If XXX software interoperates with other software, describe here the requirements on data
exchange.
Requirement ID SRS-DAT-100 SAMPLE

Title DICOM Protocol

XXX communicates with PACS servers with the use of the DICOM protocol,
Description version xx

Version V1.0

2.9 Resources

2.9.1 Hardware resources

For plain old PC:
Requirement ID SRS-HWR-110 SAMPLE

Title Hardware configuration

XXX shall run with the expected response times on a PC with the following
minimal configuration:
 64 Go RAM
Description  16 CPU cores
 1024 GPU
 ...

Version V1.0

For mobile apps, it can be difficult to be specific, if you want to install your app on any device
Requirement ID SRS-HWR-110 SAMPLE

Title Hardware configuration

XXX shall run with the expected response times on a mobile platform with
the following minimal configuration:
 16 Go RAM
Description
 Aaa x bbb minimal screen resolution
 Aaa x bbb minimal camera resolution

Version V1.0

On the cloud, virtual hardware requirements are possible

Requirement ID SRS-HWR-110 SAMPLE

Title Cloud-based configuration

Description XXX shall run with the expected response times on a virtual machine /
container engine with the following minimal configuration:

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 14 / 20

 2 Go RAM
 ...

Version V1.0

2.9.2 Software resources

Software configuration can be defined precisely for embedded systems, thus it cannot be
changed easily. For PC applications, the versions can be less precise (eg ApertureOS 11 without
more details). On the cloud, versions can change more often.
Thus, is it possible to remain vague in the SW versions at this stage of the design and freeze the
actual version when the software is released.

Requirement ID SRS-SWR-120 SAMPLE

Title Software configuration

XXX runs in the following software environment:
 (describe OS version),
Description  (For cloud-based, describe containerization versions, if possible),
 (database version).

Version V1.0

2.10 Internal data

If specific requirements for internal data, like databases, binary files, json, xml …
For example, it can be necessary to specify internal data if their design mitigates a risk
This section isn’t used often but is left there as a reminder.

2.11 Configuration or Adaptation

If specific requirements adaptability or configuration of software, like configuration files,
configuration parameters in database and/or admin/user GUI to configure the software.

2.12 Verification
Special functions to test the software, if necessary. For example, a hidden function to activate a
log file during beta tests. But not a backdoor or a security hole!!! This shall be stripped form
release
This section isn’t used often but is left there as a reminder.

2.13 Personnel and training

Requirements about the capabilities/knowledge of users, the training they shall have before
using software.
That kind of requirement can already be present at system level document or product level
document. Then, this section may be left blank, unless this is here refined.

Requirement ID SRS-XXX-USR-010 SAMPLE

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 15 / 20

Title E-learning
Description XXX is delivered with e-learning module.
Version V1.0

2.14 Packaging and installation

That kind of requirement can already be present at system level document or product level
document. Then, this section may be left blank, unless this is here refined.

If you deliver on some hardware media:

Requirement ID SRS-XXX-PAK-010 SAMPLE

Title Packaging
Description XXX shall be delivered on zzz media.
Version V1.0

If the installation can be automated:

Requirement ID SRS-XXX-PAK-010 SAMPLE

Title Install-shield
Description XXX shall be installed with the use of an install shield.
Version V1.0

For mobile apps, we remain only at technical level. The way the app is deployed on the store is
not part of this document.
Requirement ID SRS-XXX-PAK-010 SAMPLE

Title APK
XXX shall be installed with the use of an APK accepted by RobotOS based
Description
systems.
Version V1.0

2.15 Software updates

That kind of requirement can already be present at system level document or product level
document. Then, this section may be left blank, unless this is here refined.
It is mostly useful with mobile apps where end-users install and update software.
It may not be so relevant for cloud software, or when software is managed by admins.

Requirement ID SRS-XXX-PAK-010 SAMPLE

Title New version

Description When it starts, XXX software shall be able to detect if a new software
version is available.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 16 / 20

If the version is mandatory, XXX software shall install the new version and
restart. If the version is optional, XXX software shall propose to the user to
install it.

Version V1.0

2.16 Decommissioning – uninstallation

Requirements about the operations to perform to uninstall the software
That kind of requirement can already be present at system level document or product level
document. Then, this section may be left blank, unless this is refined here.

Requirement ID SRS-EOL-010 SAMPLE

Title Uninstall
XXX is delivered with an uninstaller.
The uninstaller allows the user to export personal data prior to
Description
uninstallation.

Version V1.0

Requirement ID SRS-EOL-010 SAMPLE

Title Erasing personal data

XXX shall erase personal data using the DoD 5220.22-M algorithm.
Description
Version V1.0

2.17 Secure operations guidelines

When secure operations cannot be handled by the manufacturer, they shall be present as
guidelines in some accompanying documentation (this is risk transfer, in cyber language). The
requirements below should come from security risk controls.
That kind of requirement can already be present at system level document or product level
document. Then, this section may be removed and documented elsewhere at product/system
level..

Requirement ID SRS-SOG-010 SAMPLE

Title Statement about account management

Secure operations guidelines shall contain a statement about account
Description management by the HCP

Version V1.0

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 17 / 20

Requirement ID SRS-SOG-020 SAMPLE

Title Statement and warning about automatic security updates

Secure operations guidelines shall contain:
 A statement about setting the OS automatic security updates to
“enabled”,
Description
 A warning reminding the reader that disabling OS automatic
security updates may put the device at risk.

Version V1.0

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 18 / 20

3 REQUIREMENTS TRACEABILITY
Add a table with traceability of software requirements of this document with user or system or
product requirements.

Example
SRS Req. Req Title Functional Req. Req. Title
SRS-REQ-001 Reading ECG values FUN-REQ-00A ECG post treatment
SRS-REQ-002 Writing results FUN-REQ-00A ECG post treatment

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 19 / 20

4 CYBERSECURITY CONTROLS TRACEABILITY

OPTIONAL SECTION
The FDA guidance on Cybersecurity in Medical Devices recommends to document a traceability
with a predefined list of types of cybersecurity controls.

You may use this section to document traceability between your SRS and the control types.
Some controls may not be documented in the SRS (e.g. in de dev plan). You can also move or
duplicate this traceability to the security risk assessment report if you have security control
types covered by artifacts that are not SRS.

Types of Cybersecurity controls listed in the FDA guidance on Cybersecurity in Medical Devices
are:
 A) Authentication controls,
 B) Authorization controls,
 C) Cryptography controls,
 D) Code, data, and execution integrity controls,
 E) Confidentiality controls,
 F) Event detection and logging controls,
 G) Resiliency and recovery controls,
 H) Firmware and software update controls.

Example:
SRS ID SRS Title Security Controls
SRS-AUTH-001 User authentication by login Authentication control
and pasword
SRS-DAT-001 Database encryption Confidentiality controls

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Requirements Specifications of XXX software

Doc # Version: 2024 Page 20 / 20

5 CRITICAL REQUIREMENTS
OPTIONAL SECTION
If necessary, add a list of critical requirements, or a list of reference to requirements in previous
sections.
This list may be the result of risk analysis (ISO 14971).

Examples
Requirement ID Requirement Title Origin
REQ-001 Alarm when value out of range Risk Analysis
REQ-002 Do not open file if no patient name Risk Analysis
REQ-003 Display blinking when negative values Human factor engineering

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License