100% found this document useful (1 vote)
639 views14 pages

SRS Document

The document outlines the requirements for developing a machine learning-based doctor recommender system. It discusses collecting doctor and patient data, preprocessing the data, creating a dataset, developing a classification model to predict recommended doctors, training the model, and creating a recommendation system and interface. It describes functional requirements for admins to collect, preprocess, and train the model and for users to provide preferences and receive recommendations. Non-functional requirements around performance, security, and evolvability are also included. Work will be tracked using a Gantt chart.

Uploaded by

sy.anjamnoor
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
639 views14 pages

SRS Document

The document outlines the requirements for developing a machine learning-based doctor recommender system. It discusses collecting doctor and patient data, preprocessing the data, creating a dataset, developing a classification model to predict recommended doctors, training the model, and creating a recommendation system and interface. It describes functional requirements for admins to collect, preprocess, and train the model and for users to provide preferences and receive recommendations. Non-functional requirements around performance, security, and evolvability are also included. Work will be tracked using a Gantt chart.

Uploaded by

sy.anjamnoor
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 14

MACHINE LEARNING-BASED DOCTOR

RECOMMENDER SYSTEM

SOFTWARE

Requirements Specification

Version 1.0

GROUP ID: F23022836B

BS170403164 - BC200205135

Supervisor Name: Komal Khawer

1
SEMESTER Spring: 2023
REVISION HISTORY

Date (DD/MM/YYYY): 06-10-2023

Version: 1.0

Description:
SRS document includes Scope of the project, Functional requirements, Use Case
diagram, Usage Scenarios, Adopted Methodology, and Work Plan/Gantt Chart.

Author: F23022836B

2
Table of Contents
Scope (of the project) ------------------------------------------------------------- 04

Functional Requirements --------------------------------------------------------- 05

Non-Functional requirements ---------------------------------------------------- 06

Use Case Diagram ----------------------------------------------------------------- 08

Usage Scenarios -------------------------------------------------------------------- 09

Adopted Methodology ------------------------------------------------------------- 12

Work Plan (Work Plan) ----------------------------------------------------------- 14

3
SRS DOCUMENT

Scope of Project:

Recommender systems use machine-learning techniques to make predictions about


resources. The medical field is one where much research is currently being conducted on
recommender system utility. In the last few years, the amount of information available
online that relates to health care has increased tremendously. Patients now a days are
more aware and look for answers to healthcare problems online. This has resulted in a
dire need of an effective reliable online system to recommend the doctor that is best
suited to a particular patient in a limited time. In this project, a hybrid doctor-
recommender system is proposed, by combining different recommendation approaches:
content base, collaborative and demographic filtering to effectively tackle the issue of
doctor recommendation. The proposed system addresses the issue of personalization
through analyzing patient's interest towards selecting a doctor. It uses a novel adoptive
algorithm to construct a doctor's ranking function. Moreover, this ranking function is
used to translate patients’ criteria for selecting a doctor into a numerical base rating,
which will eventually be used in the recommendation of doctors. The system has been
evaluated thoroughly, and result show that recommendations are reasonable and can fulfil
patient's demand for reliable doctor's selection effectively.
Developing a Machine Learning-based Doctor Recommender System can be an impactful
project with a broad scope. Here's an outline of the primary components and
considerations.
1. Data Collection and Preparation:

 Medical Datasets: Gather information on doctors (specializations, experience,

and reviews), patient feedback, medical history, hospital/clinic details, etc.

 Data Cleaning: Process and clean the data to handle missing values,

inconsistencies, and outliers.

2. Feature Engineering:

4
 Doctor Features: Extract relevant features such as specialty, location, years of

experience, patient ratings, hospital/clinic ratings, etc.

 Patient Features: Gather patient preferences, medical history, location, etc.

 Feature Selection: Identify the most influential features for the recommendation

model.

 Conclusion: Developing a Machine Learning-based Doctor Recommender

System involves various stages, from data collection and model development to

deployment and continuous improvement. It's essential to consider ethical,

privacy, and scalability aspects while ensuring the system's accuracy and user-

friendliness.

Functional Requirements:

1. Data Collection: Implement a web scraping mechanism using Beautiful


Soup in Python to extract relevant data from oladoc.com, including the
specified attributes.
2. Data Preprocessing: Clean, normalize, and transform the collected data to
create a high-quality data set. Handle missing values, encode categorical
variables, and prepare the data for machine learning.
3. Data-set Creation: Build a data set with a minimum of 100 records for
each specialty, ensuring diversity and accuracy in the data.
4. Machine Learning Model: Develop a binary classification model that
predicts whether a doctor is recommended or not based on the specified
attributes, with a focus on doctors' satisfaction levels.
5. Model Training: Train and fine-tune the machine learning model using the
created data set.

5
6. Recommendation System: Create a user-friendly recommendation system
that takes user preferences and requirements into account. The system
should provide a list of recommended doctors based on input criteria.
7. User Interface: Design a user interface that allows users to interact with
the recommendation system and input their preferences.
8. Evaluation: Evaluate the model's performance using appropriate metrics
and validate the recommendation system's effectiveness in providing
suitable doctor recommendations.

There are two actors for this project:

1. Admin
2. User - Patient

Functional Requirements of Admin

 Data Collection
 Data Preprocessing
 Data-set Creation
 Model Training

Functional Requirements of User \ Patient

 Give his preferences as input to the system to find a doctor.


 Give feedback about the result of the model.
 Rate the prediction model.

Non-Functional Requirements:

o Performance requirements:
 The system need to be reliable.
 Web pages are loaded within few seconds.
 If unable to process the request appropriate error message.

6
o Safety Requirement:

 Users must be authenticated.

 Details need to be maintained properly.

o Security Requirements:

 Sharing of details.

 The details of user must be safe and secure.

 After entering the password and user id the user can assess his profile.

o Evolution

 Testability.

 Maintainability.

 Extensibility

7
 USE CASE DIAGRAM:

8
 USAGE SCENARIOS:

Title: Admin – Users Registration


Use case ID: OGPM _01
Actor: Admin
Description: All Users(users/Patients) Create his/her
Account
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
Click on register.
Fill in particulars.
Clicks submit.
Admin Approved Accounts
Post condition: Task has been completed successfully.
Author: F23022836B

Title: Admin / Add Doctors info


Use case ID: OGPM _02
Actor: Admin
Description: Admin Add new doctors information
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
Login Account
Click on add new information
Fill in particulars.
Clicks submit.
Post condition: Task has been completed successfully.
Author: F23022836B

Title: Admin/ update doctors Information


Use case ID: OGPM _03
Actor: Admin
Description: Admin can update information
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
Login Account
Click on doctor you want to update
Update required fields
Clicks update.
Post condition: Task has been completed successfully.

9
Author: F23022836B

Title: Admin delete doctors information


Use case ID: OGPM _04
Actor: Admin
Description: Admin have authority to delete any info
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
Click on Delete.
Reload page
Post condition: Task has been completed successfully.
Author: F23022836B

Title: Admin Manage Users


Use case ID: OGPM _05
Actor: Admin
Description: Admin manage patients - users
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
Click user list.
Fill in particulars.
Clicks submit.
Post condition: Task has been completed successfully.
Author: F23022836B

Title: Admin View feedback


Use case ID: OGPM _06
Actor: Admin
Description: Admin view user feedback
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
Login admin
Click on feedback
Click on view
Post condition: Task has been completed successfully.
Author: F23022836B

10
Title: Admin/ Generate Reports
Use case ID: OGPM _07
Actor: Admin
Description: Admin create registered doctors reports.
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
Login with your account
Click on Reports
Create
Post condition: Task has been completed successfully.
Author: F23022836B

Title: User – Patient view doctors


Use case ID: OGPM _8
Actor: Patient - user
Description: User view doctors
Pre-condition: Application is running and ready for use.
Task sequence: Open application.
User login
View Doctors.
Post condition: Task has been completed successfully.
Author: F23022836B

11
Adopted Methodology

Definition:
“Methodology is a framework that is used to structure, plan and control the process
developing an information system”.
VU process model is a combination of the waterfall and spiral model.

Waterfall model:
Waterfall model is the first process model to be introduced. This model is also known as
linear sequential model or classic life cycle model. It consists of five stages.

1. Requirement definition:
In this stage, the systems services, constraints and goals are established by consultation
with system users.
2. System and software design:
In this stage, we conceptualize overall system architecture.

3. Implementation and unit testing:


In this stage the software design is realized as a set of programs or program units.
4. Integration and system testing:
In this stage, the individual program unit or programs are integrated and tested as a
complete system to ensure that the system requirements have been met.
5. Operation and maintenance:
Maintenance means correcting errors which were not discovered in earlier stages.
Spiral model:
It is a form of incremental model. In this model, main emphasis is given on risk analysis.
It is used for large and complicated projects. Generally, the spiral model has four phases:
planning, risk analysis, development, and evaluation. Planning phase covers scope,
requirement and functionality of the system. Second phase risk analysis is most important

12
phase. Development phase covers the designing, coding and testing and finally the
application is delivered to client for further evaluation
Adopted model: VU process model

In our project we choose VU process model it is the combination of waterfall and spiral
model.VU process model is a hybrid approach. It is depicted in following diagram

Requirements Analysis In each vu model


Each phase
Planning: risk analysis: report back
Software requirement cost effectiveness
Work plan with less work

Client evaluation: development: Design


deliver project designing, coding,
with specific testing
requirement otherwise
recycle for further
evaluation.

Acceptance Testing Coding

Above is the diagram of combination of waterfall and spiral model.

Reason for choosing this methodology:


1. VU process model has the benefits of predictability.
2. Maintenance is easy in this model.
3. Requirements are well understood.
4. It is more concise and advanced model than waterfall model.
5. VU process model is heavily dependent on risk analysis.
6. VU process model allows us to do correction at any stage.

13
WORK PLAN:

14

You might also like