0% found this document useful (0 votes)
12 views13 pages

SRS Document

The document outlines the Software Requirement Specification (SRS) for an AI Health Care Bot System designed to provide healthcare advice, appointment booking, and medical information. It details the system's purpose, features, requirements, design, and testing strategies, emphasizing user-centric functionalities and security measures. The system aims to enhance healthcare accessibility and efficiency through AI and natural language processing.

Uploaded by

Deepak Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views13 pages

SRS Document

The document outlines the Software Requirement Specification (SRS) for an AI Health Care Bot System designed to provide healthcare advice, appointment booking, and medical information. It details the system's purpose, features, requirements, design, and testing strategies, emphasizing user-centric functionalities and security measures. The system aims to enhance healthcare accessibility and efficiency through AI and natural language processing.

Uploaded by

Deepak Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Krishna Group of Institutions

Kanpur

Software Requirement
Specification
(SRS Document)
For
AI Health Care Bot System

By
[Link] Kumar
(2103510100017)
[Link] Gautam
(2103510100017)
[Link] Verma
(2103510100017)
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Assumptions and Dependencies
3. System Requirements
3.1 Functional Requirements
3.2 Non-Functional Requirements
3.3 Interface Requirements
3.4 Database Requirements
4. System Design and Architecture
4.1 System Architecture Overview
4.2 Technology Stack
5. Use Case Models
5.1 Use Case Diagram
5.2 Use Case Scenarios
6. Data Flow Diagrams (DFD)
6.1 Context Level DFD
6.2 Level 1 DFD
7. ER Diagram and Database Schema
7.1 Entity-Relationship Diagram
7.2 Database Schema
8. Deployment Plan
8.1 Deployment Environment
8.2 Deployment Diagram
9. Testing Plan
9.1 Testing Strategy
9.2 Sample Test Cases
10. Future Enhancements
11. Appendices

1. Introduction
1.1 Purpose
The purpose of the Health Care Bot System is to provide
an AI-powered platform for users to get basic healthcare
advice, book appointments with doctors, and access
medical information. It aims to improve healthcare
accessibility and efficiency.
1.2 Scope
The chatbot will analyse symptoms, provide potential
disease suggestions, reassure users, offer hospital and
doctor suggestions, set medication reminders and ensure
accessibility with multiple language options, it will also
provide personalized treatment advice based on the
user’s profile and medical history.
The system includes:
 Chatbot: Answers health-related questions using AI
and natural language processing (NLP).
 Symptom Checker: Provides preliminary
diagnostics.
 Appointment Booking: Schedules consultations
with medical professionals.
 Health Tips: Offers lifestyle and health
improvement suggestions.
1.3 Definitions, Acronyms, and Abbreviations
 AI: Artificial Intelligence
 NLP: Natural Language Processing
 UI: User Interface
1.4 References
1. Django Official Documentation.
2. WHO Health Guidelines.
1.5 Overview
This document describes the system's features, design,
and technical details required for successful
implementation.

2. Overall Description
2.1 Product Perspective
The Health Care Bot System integrates with third-party
medical APIs and uses AI models for intelligent decision-
making. It is designed for web and mobile platforms,
offering both patient-centric and admin-facing features.
2.2 Product Features
 Chatbot for health inquiries.
 Symptom-based diagnostics.
 Doctor appointment scheduling.
 Personalized health recommendations.
 Admin dashboard for system management.
2.3 User Classes and Characteristics
1. Patients: Primary users, seeking healthcare advice.
2. Admins: Manages doctor availability, hospital
database, and chatbot language settings.

2.4 Operating Environment


 Backend: Django (Python 3.10+)
 Frontend: [Link]
 Database: MySQL

2.5 Assumptions and Dependencies


 Reliable internet connection.
 Third-party APIs for medical data.

3. System Requirements
3.1 Functional Requirements
• User Registration and Profile Creation:
o Users can create profiles and provide
details such as medical history, current
medications, allergies, age, and gender.
• Symptom Input and Disease Prediction:
o Users input symptoms, and the chatbot
predicts possible diseases using a pre-trained
AI model.
o The chatbot provides a reassuring
message and suggests visiting a doctor for
confirmation.
• Personalized Treatment Suggestions:
o The chatbot offers personalized advice by
referencing the user's medical history and other
profile information (e.g., allergies, age).
o Recommendations are tailored to the user's
medical background, considering potential
allergies or ongoing treatments.
• Multilingual Support:
o The chatbot interface supports multiple
languages (e.g., English, Hindi, Tamil), and
users can choose their preferred language.
o The system provides translations for
medical terms and advice to ensure accurate
communication across languages.
• Nearby Hospital and Doctor Search:
o Users receive a list of nearby hospitals and
real-time doctor availability based on symptoms
and location.
o Users can book appointments with
available doctors through the chatbot.
• Medication Reminders:
o Users can set reminders for taking
medication, and the system will notify them at
the appropriate time.
o The chatbot can handle multiple reminders
and offer flexible scheduling options.
• Security and Privacy:
o User data, including health information, will
be encrypted and stored securely.
o The system will comply with privacy
standards like GDPR, ensuring that user data is
protected.

3.2 Non-Functional Requirements


• Performance:
The chatbot should respond to user
inputs within 2 seconds.
• Scalability:
o The system should handle up to 10,000
concurrent users efficiently.
• Usability:
o The chatbot should have a simple and
intuitive interface, accessible to both tech-savvy
and non-tech users.

• Reliability:
o The system should have 99% uptime,
ensuring continuous availability of services.
• Security:
o Data encryption for all personal and health
related information.
o Multi-factor authentication for users
accessing sensitive features, like appointment
booking.

3.3 Interface Requirements


 Intuitive UI for patients and doctors.
 API integration for real-time data.
3.4 Database Requirements
 Tables: Users, Appointments, Chat History,
Feedback.
 Constraints: Data integrity and relationships.

4. System Design and Architecture


4.1 System Architecture Overview
The system follows a modular, three-tier architecture:
 Presentation Layer: User Interface ([Link]).
 Business Logic Layer: Django-based RESTful
APIs.
 Data Layer: MySQL database.
4.2 Technology Stack
 Backend: Django.
 Frontend: [Link].
 AI Model: TensorFlow for NLP.

5. Use Case Models


5.1 Use Case Diagram
A visual representation of user interactions.
5.2 Use Case Scenarios
Example:
 Actor: Patient
 Action: Ask the chatbot about symptoms.
 System Response: Provides preliminary
diagnostics.

6. Data Flow Diagrams (DFD)


6.1 Context Level DFD

7. ER Diagram and Database Schema


7.1 Entity-Relationship Diagram
Entities:
1. User: Represents the patients or users who book
appointments.
2. Admin: Represents the system administrators who
manage the appointments.
3. Appointment: Represents the scheduled
appointments between users and doctors (or for
administrative purposes).
Relationships:
 User → Appointment: A user can book many
appointments (one-to-many relationship).
 Admin → Appointment: Admin manages and can
update or cancel appointments (one-to-many
relationship).
 Appointment → User: An appointment is linked to
one user, but each user can have multiple
appointments.
 Appointment → Admin: Admin has the authority to
manage appointments, but an appointment is
associated with only one admin.

7.2 Database Schema


 Users Table: Stores user data.
 Appointments Table: Manages schedules.
 Chat History Table: Logs interactions.

8. Deployment Plan
8.1 Deployment Environment
 Hosting: AWS or Azure.
 Containers: Docker for deployment.
8.2 Deployment Diagram
Illustrates the server setup, load balancers, and
database.

9. Testing Plan
9.1 Testing Strategy
 Unit Testing: Individual components.
 Integration Testing: System modules.
9.2 Sample Test Cases
Test Case Expected
Description Status
ID Outcome
Login
TC01 Successful login Pass
functionality

10. Future Enhancements


 Multilingual support.
 Integration with wearable devices for health
tracking.

11. Appendices
 API documentation.
 User manual.

You might also like