Software Requirements Specification

Digital Speech Therapy

Sourabh Dubey
 Table of Contents

Table of Contents i
List of Figures ii
1.0. Introduction 1
1.1. Purpose 1
1.2. Scope of Project 1
1.3. Notations/Abbreviations 2
1.4. References2
1.5. Overview of Document 2
2.0. Overall Description 3
3.1 System Environment 3
4
3.2 Functional Requirements Specification
4
2.2.1 Patient Use Case
Use case: Course Hub 4
2.2.2 Therapist Use Case 4
Use case: Patient course designer 5
2.2.3 Admin Use Case 5
3.3 Functional Characteristics 6
3.4 Non-Functional Requirements 6
3.0. Requirements Specification 7
3.1 External Interface Requirements 7
3.2 Functional Requirements 7
3.2.1 Reports
3.2.2 Therapist
3.2.3 Patient
3.2.4 Application
3.2.5 Games
3.2.6 Course
3.3 Detailed Non functional Requirements

b.1 Logical Structure of Data 9

1
b.1 Security 0
 i

List of Figures

Figure 1 - System Environment........................................................................................................................4 Figure 2 -

Article Submission Process.............................................................................................................6 Figure 3 - Editor Use
Cases..............................................................................................................................8 Figure 4 - Logical Structure of
the Article Manager Data.............................................................................23

1.0. Introduction

1.1. Purpose

The objectives of this document are to detail the system’s requirements, both

functional and non-functional, and to provide a clear guide for development teams,

stakeholders, and project managers involved in the project. This document aims to ensure

that the platform meets the needs of both therapists and patients, promoting a more

effective therapeutic experience.

1.2. Scope of Project

 Development of the digital therapy management platform.

 Features including automated case assignment, therapy planning, digital activities, voice analysis,
and progress reporting.
 Development of mobile and web-based applications.
 Integration with cloud infrastructure for scalability.

1.3. Notations / Abbreviations

Abbreviation Term
OS Operating System
API Application programming Interface
MB/GB MegaByte/ GegaByte
AI Artificial Intelligence

ii
EHR Electronic Health Record
ML Machine Learning

1.4. References

 [Link]
 [Link]
 [Link]
 [Link]
 [Link]
 [Link]
 [Link]
 "The Future of Speech Therapy: Integrating Technology for Improved Outcomes," National Institute
of Health, 2022.
 E. C. H. M. Robinson, "The Impact of Gamification in Speech Therapy: A Systematic Review,"
Journal of Medical Internet Research, vol. 21, no. 5, 2019.
 L. J. Barrett et al., "Using Technology to Enhance Speech Therapy: A Review of Current
Applications," American Journal of Speech-Language Pathology, vol. 29, no. 4, pp. 1465-1479,
2020.

1.5. Overview of Document

The proposed solution is a digital therapy management and delivery platform designed to enhance the
efficiency, effectiveness, and engagement of speech and language therapy for both therapists and
patients.
 Automated Case Assignment.

Digital Therapy Planning and Customization:

Engaging Digital Activities and Gamification:

Voice Analysis Tool:

Progress Monitoring and Reporting:

Scalable Infrastructure and Therapist Engagement:

iii
2.0. Overall
Description
2.1 System Environment

User

Patient Login

Courses

Therapist Admin

Digital Therapy System

 Recept.
Figure 1 - System Environment

The Digital Therapy System has four active actors and one cooperating system.

The User, Therapist, or Patient accesses the application through the Internet. Any patient

or Therapist communication with the system is through application. The Admin accesses

the entire system directly. There is a link to the (existing) Historical Society.
 2.2 Functional Requirements Specification

This section outlines the use cases for each of the active users separately. The

Patient, the therapist and the receptionsist have only one use case apiece while the admin

is main actor in this system.

b.1 Patient Use Case

Use case: Course Hub

Diagram:

Course Hub

Patient

Brief Description
The patient access the courses and exercises told by Therapist to perform.
Initial Step-By-Step Description
Before this use case can be initiated, the patient has already accessed the Online Therapy website.

1. The Patient fills all the old medical history.

2. The system displays all the possible therapists available.
3. The patient selects the Therapist.
4. The system presents the abstract of the Patient to the Therapist.
5. The Patient do all the courses which has been given by Therapist.
6. The system provides the requested Courses.

b.1 Therapist Use Case

In case of multiple Therapist, this term refers to the principal Therapist, with whom all
communication is made.

Use case: patient course designer

Diagram:

Course designer

Therapist
Brief Description
The Therapist designs courses for patient to follow.

Initial Step-By-Step Description

Before this use case can be initiated, the Therapist has already connected to the Online Therapy
Website.

1. The Therapist gets patient assigned.

2. The Therapist designs courses according to patient’s need.
3. The Therapist tracks patients records.
4. The Therapist gives feedback to patient.

2.2.3 Admin Use Cases

The Admin has the following sets of use cases:

Update Info

Doctor info

Status

Admin

Patient info

Reception

Figure 2 – Admin Use Cases

Brief Description
The Admin is the one that adds doctors to the projecft

Initial Step-By-Step Description

Before this use case can be initiated, the Admin has already accessed the main page of the Doctor.

1. The Admin selects to Add/Update Doctor.

2. The system presents a choice of adding or updating.
3. The Admin chooses to add or to update.
 4 If the Admin is updating an Doctor, the system presents a list of Doctors to choose from
. and presents a grid filling in with the information; else the system presents a blank grid.

5. The Admin fills in the information and submits the form.

6. The system verifies the information and returns the Admin to the Patient main page.

3.1 Functional Requirements

Automated Case Assignment: Match patients with therapists using an intelligent

algorithm.

Digital Therapy Planning: Create and modify therapy plans easily within the platform.

Engaging Digital Activities: Offer interactive exercises and gamification elements.

Voice Analysis Tool: Provide immediate feedback on patients’ speech during therapy.

Progress Monitoring and Reporting: Generate insightful reports on patient progress..

3.2 Non-Functional Requirements

Performance: The system should handle up to 1000 simultaneous users without

degradation.

Security: Implement encryption, access controls, and regular security audits.

Scalability: The platform should easily handle user growth through cloud-based

solutions.

External Interface Requirements

APIs for integration with Electronic Health Records (EHR) and other healthcare

platforms.

Access to data analytics tools for in-depth reporting and insights.

 3.0. Requirements
Specification

3.1 External Interface Requirements

SOFTWARE REQUIREMENT :-
Web Browser (for Web Application Access):-
Browsers: Google Chrome, Mozilla Firefox, Safari, or Microsoft Edge (latest versions).
 OS Compatibility: Windows 10+, macOS 10.12+, Linux, or ChromeOS.
 Browser Features: Should support WebRTC (for audio capture) and Web Audio API.
 Mobile Application (for Mobile Access) Operating Systems:-
 iOS 12+ for iPhones and iPads.
 Android 9+ for Android smartphones and tablets.
 Storage Space: Approximately 100MB of free space for app installation.
 Bandwidth: Minimum of 2 Mbps for smooth interaction.
 Latency: Low latency (< 100 ms) for real-time audio processing.

HARDWARE REQUIREMENTS:-
 Client Device (User Side)

 Laptop/Desktop:

 Smartphone/Tablet:

Processor: Quad-core (e.g., Snapdragon 400 series or equivalent).

Memory: 2GB RAM.
Storage: At least 500MB of free space for app storage.

3.2 Functional Requirements

The Logical Structure of the Data is contained in Section 3.3.1.

3.2. Reports
1
Entity Name Reports
Attributes New Plan, Updation, Analysis, Feedback, Medical History
Relations Gets Report, Updates
Precondition The Web is displayed with grids
Basic Path 1. The Report gets created by analysing the scores.
1. The Report are sent to doctor.
2. The Report is displayed in the form of Grid.
 b.1 Therapist
Entity Name Therapist
Attributes T_Name, Address, Therapist_Id, Login Credentials, T_Age, T_DOB,
Patient Id
Relations Updates, Gets Feedback from, Updates Plan On
Basic Path 1. The Therapist is the one on whom patients gets assigned.
1. The therapist desings courses for patients.
1. The Therapist is the one that gives feedback to the patients.
b.1 Patient
Entity Patient
Name
Attributes Medical Requirements, Patient_id, medical history, P_name, P_address, P_age,
P_DOB
Relations Gets Report, Uses Application
Basic Path 1. Patient will provide all the medical history to the system.
1. The system will analyse the Medical requirements of the patient.
2. It will display list of therapists .
3. Patient has to choose one of the therapist.
b.2 A
p
p
li
c
at
i
o
n
Entity Application
Name
Relations Uses application, updates on
Basic Path 1. The application is the one that connects patients with
therapists.
2. It provides multiple features such as
games, chatbot, course.
3.2.5 Games
Entity Games
Name
Realtions has
Attributes Bubble exercise, minimal pair, articulation practices, story telling.

Basic Path 1. Games gets pick by therapist through application.

2. Patient has to perform them in order
to generate score.
1. Upon that score the therapist will give feedback to user.
3.2.6
Course
Entity Course
Name
 Attributes Memory game, tongue twisters, picture flashcard, word speak search.

Relations Has
Basic Path 1. Cousrses gets pick by therapist through application.
2. Patient has to perform them in
order to generate score.
3. Upon that score the therapist will
give feedback to user.
3.3

Detailed Non-Functional Requirements

3.3.
Logical Structure of the Data
1

The logical structure of the data to be stored in the internal Speech Therapy

database is given below.

Figure 3 - Logical Structure of the Speech TherapyData

The data descriptions of each of these data entities is as follows:

Doctor Data Entity

Data Item Type Description Comment
Name Text Name of Doctor
Email Address Text Internet address

Patient Data Entity

Data Item Type Description Comment
Name Text Name of patient
ID Integer ID number of patient Used as key in therapy
Database
Email Address Text Internet address
History Text Comments on past
Report Data Entity
Data Item Type Description Comment
New plan Text New course
analysis Pointer Ml algo will work
feedaback Text Date sent to Patient Doctor feedback to patient
Contents Text Text of review

3. Security
3.
2

The server on which the Online Speech Therapy resides will have its own security

to prevent unauthorized write/delete access. There is no restriction on read access. The use of email
by an Doctor or Patient is on the client systems and thus is external to the

system.

The PC on which the Speech Therapy admin resides will have its own security.

Only the Admin will have physical access to the machine and the program on it. There is

no special protection built into this system other than to provide the admin with write

access to the Online Speech Therapy database.