Final - SRS - of Doctor - Appointment - Booking - System AYUSH

Software Engineering Project management [BTCS504]
CHAPTER 1 – INTRODUCTION
1. Introduction
In this project we are trying to develop a web application that is simple to use and
understandable for everyone. Doctor Appointment Booking System is a platform where you
can book you appoint with the doctors according to your need and conditions, even this
platform contain your previous data as well which will help the doctor to change the
prescription.
In the upcoming future we will notice that Doctor Appointment Booking will add the features
like video call & online medicine delivery to your residential address. As we all are humans at
sometimes in our-life we need doctors help so this platform will help us to make it easy.
1.1 Objective
The main objective of the Doctor Appointment System is to manage the details of Doctor,
Patient, Test, Medicine, Booking Number. It manages all the information about Doctor,
Appointment, Booking Number, Doctor. The project is totally built at administrative end and
thus only the administrator is guaranteed the access. The purpose of the project is to build an
application program to reduce the manual work for managing the Doctor, Patient,
Appointment, Test. It tracks all the details about the Test, Medicine, Booking Number.
▪ Define hospital.
▪ Recording information about the Patients that come.
▪ Generating bills.
▪ Recording information related to diagnosis given to patients.
▪ Keeping record of the immunization provided to children/patients.
▪ Keeping information about various diseases and medicines available to cure them.
AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 1

1.2 Identification of need
The old manual system was suffering from a series of drawbacks. Since whole of the system
was to be maintained with hands the process of keeping, maintaining and retrieving the
information was very tedious and lengthy. The records were never used to be in a systematic
order. For this reason, we have provided features Present system is partially automated
(computerized), actually existing system is quite laborious as one has to enter same information
at three different places. Since our project is a web-application, all it needs is a stable internet
connection which makes the application accessible from anywhere from any type of device.
The reason behind it is that there is lot of information to be maintained and have to be kept in
mind while running the business For this reason we have provided features Present system is
partially automated (computerized), actually existing system is quite laborious as one has to
enter same information at three different places.
1.3 Preliminary investigation

The purpose of the preliminary investigation is to evaluate project requests. It is not a design
study, nor does it include the collection of details to describe the business system in all respect.
Rather, it is the collecting of information that helps committee members to evaluate the merits
of the project request and make an informed judgment about the feasibility of the proposed
project.
1.4 Problem domain

• Managing the many different appointment types.
• Gathering all documentation and authorizations necessary before an appointment.
• Adjusting schedules based on provider preferences for appointment types.
• Handling referrals and the associated authorizations.

1.5 Solution Domain
This project is to create a web application where users are enabling to download reports,
prescriptions, X-rays etc easily & securely. Even each and every user can share his/her reports
with any other doctors and the data is fully secure. This application can adjust the appointment
according to patients severe conditions on doctor’s order. The project should be very easy to
use enabling even a novice person to use it.
1.6 Platform Investigation
1.6.1 Hardware
Doctor Appointment System is a browser-based application hence, any device with any
hardware specification can run it smoothly.
• Processor: Intel® Core™ i3 or above.
• Hard Disk: 160 GB or above.
• RAM: 2 GB Min, 8GB recommended.
• Display: Any TFT monitor or higher.
• Keyboard: Any with minimum required keys.
1.6.2 Software
Any JavaScript enabled browser can easily run the Doctor Appointment System.
• Operation System: Microsoft® Windows® 7/8/10(32- or 64 bit)
• Front end tool: HTML, JavaScript, css.
• Business Logic: JDK 8, php, xml, json.
• Database: Sql Lite, MySql.
• Environment: VS code

CHAPTER 2 – SYSTEM REQUIREMENT ANALYSIS
2. SYSTEM REQUIREMENT ANALYSIS
Requirements analysis encompasses those tasks that go into. determining the needs or
conditions to meet for a new or altered product or project, taking account of the possibly.
conflicting requirements of the various stakeholders, analyzing, documenting, validating and
managing software or system.
2.1 Information Gathering
There are various websites that offer this kind of services, but they also charge fees for
this and are difficult to use. Doctor Appointment Booking System is a web-
application that doesn’t charge any processing fees and it also help every patient to take
consult from top notch doctors just with one click. It’s fast, secure and the design is
intuitive.
2.1.1 Functional Requirements
• Adding Patients: The Hospital Management enables the staff at the front desk to
include new patients in the system.
• Assigning an ID to the patients: The HMS enables the staff at the front desk to provide
a unique ID for each patient and then add them to the record sheet of the patient. The
patients can utilize the ID throughout their hospital stay.
• Mandatory Patient Information: Every patient has some necessary data like phone
number, their first and last name, personal health number, postal code, country,
address, city, 'patient's ID number, etc.
• Updating information of the Patient: The hospital management system enables users
to update the information of the patient as described in the mandatory information
included.
The Functional Requirement possess certain characteristics few of them are as given below
▪ It indicates that the specified application offers some incentive to the State regarding
hierarchical and additionally operational destinations forms for no less than 3yrs.

▪ It contains a total arrangement of prerequisites required for the application. Which

waters the issue of anybody’s any longer presumption.
2.1.2 Non-Functional Requirements

There are a lot of software requirements specifications included in the non-functional
requirements of the Hospital Management System, which contains various processes,
namely Security, Performance, Maintainability, and Reliability.
Security:
• Patient Identification: The system needs the patient to recognize herself or himself
using the phone.
• Logon ID: Any users who make use of the system need to hold a Logon ID and
password.
Performance:
• Response Time: The system provides acknowledgment in just one second once the
'patient's information is checked.
• Capacity: The system needs to support at least 1000 people at once.
• User-Interface: The user interface acknowledges within five seconde.
Maintainability:
• Back-Up: The system offers efficiency for data backup.
• Errors: The system will track every mistake as well as keep a log of it.
Reliability:
• Availability: The system is available all the time.

2.2 System Feasibility

A feasibility study aims to provide an independent assessment that examines all aspects
of a proposed project, including technical, economic, financial, legal, and environmental
considerations. This information then helps decision-makers determine whether or not
to proceed with the project. A feasibility study contains: An executive summary
describing the project's overall viability. A description of the product or service
being developed during this project. Any technical considerations, including
technology, equipment, or staffing.
2.2.1 Operational Feasibility
No doubt the proposed system is fully GUI based that is very user friendly and all
inputs to be taken all self-explanatory even to a layman. Besides, a proper training
has been conducted to let know the essence of the system to the users so that they
feel comfortable with new system. As far our study is concerned the clients are
comfortable and happy as the system has cut down their loads and doing.
2.2.2 Technical Feasibility
This included the study of function, performance and constraints that may affect the
ability to achieve an acceptable system. For this feasibility study, we studied
complete functionality to be provided in the system, as described in the System
Requirement Specification (SRS), and checked if everything was possible using
different type of frontend and backend platforms.
2.2.3 Economical Feasibility
Our project is economically feasible because basic technologies are used which
won’t add load to the network connection or the system.It is completely free and is
device independent which means user can open it in any browser whether it’s on an
android phone, an iOS device or PC’s.

CHAPTER 3 – SYSTEM DESIGN

3. SYSTEM DESIGN
it is the process of defining elements of a system like modules, architecture, components and their
interfaces and data for a system based on the specified requirements. There are four system design
processes: developing stakeholder expectations, technical requirements, logical decompositions,
and design solutions.
3.1 USE CASE DIAGRAM
A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the
tasks, services, and functions required by a system/subsystem of an application. It depicts the
high-level functionality of a system and also tells how the user handles a system.
• It gathers the system's needs.
• It depicts the external view of the system.
• It recognizes the internal as well as external factors that influence the system.
The relationships between and among the actors and the use cases of Doctor
Appointment System:
• Admin Entity: Use cases of Super Admin are Manage Doctors, Manage Appointment,
Manage Booking, Manage Fees, Manage schedule, Manage Clinics, Manage Users and
Full Doctor Appointment System Operations
• System User Entity: Use cases of System User are Manage Doctors, Manage
Appointment, Manage Booking, Manage Fees, Manage schedule, Manage Clinics.
• Doctor Entity: Use cases of Doctor are Check Appointments, Create Prescriptions,
Search Patient, Appointment History.
• Patient Entity: Use cases of Patient are Request for Appointments, Check Appointment
Status, Make Payment


Figure.3.1 – Use Case Diagram for Appointment Booking System

3.2 CLASS DIAGRAM
The class diagram depicts a static view of an application. It represents the types of objects
residing in the system and the relationships between them. A class consists of its objects, and
also it may inherit from other classes. A class diagram is used to visualize, describe, document
various different aspects of the system, and also construct executable software code.
It shows the attributes, classes, functions, and relationships to give an overview of the software
system. It constitutes class names, attributes, and functions in a separate compartment that
helps in software development. Since it is a collection of classes, interfaces, associations,
collaborations, and constraints, it is termed as a structural diagram.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the
application, however class diagram is a bit different. It is the most popular UML diagram in the
coder community.
The purpose of the class diagram can be summarized as −
• Analysis and design of the static view of an application.

• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
Classes of Doctor Appointment System Class Diagram:
▪ Doctors Class: Manage all the operations of Doctors

▪ Appointment Class: Manage all the operations of Appointment
▪ Booking Class Manage all the operations of Booking
▪ Fees Class: Manage all the operations of Fees
▪ schedule Class: Manage all the operations of schedule
▪ Clinics Class: Manage all the operations of Clinics

Figure.3.2 – Class Diagram for Appointment Booking system

3.3 SEQUENCE DIAGRAM
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place. We can also use the terms event diagrams or event
scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what order
the objects in a system function. These diagrams are widely used by businessmen and software
developers to document and understand requirements for new and existing systems.
Figure.3.3 – Sequence Diagram for Appointment Booking system

3.4 COLLABORATION DIAGRAM
The collaboration diagram is used to show the relationship between the objects in a system.
Both the sequence and the collaboration diagrams represent the same information but
differently. Instead of showing the flow of messages, it depicts the architecture of the object
residing in the system as it is based on object-oriented programming. An object consists of
several features. Multiple objects present in the system are connected to each other. The
collaboration diagram, which is also known as a communication diagram, is used to portray
the object's architecture in the system.
Actors
Normally an actor instance occurs in the collaboration diagram, as the invoker of the interaction.
If you have several actor instances in the same diagram, try keeping them in the periphery of the
diagram.
• Each Actor is named and has a role

• One actor will be the initiator of the use case
Links
Links connect objects and actors and are instances of associations and each link corresponds to
an association in the class diagram
Links are defined as follows:

• A link is a relationship among objects across which messages can be sent. In collaboration
diagrams, a link is shown as a solid line between two objects.
• An object interacts with, or navigates to, other objects through its links to these objects.
• A link can be an instance of an association, or it can be anonymous, meaning that its
association is unspecified.
• Message flows are attached to links, see Messages.

Messages
A message is a communication between objects that conveys information with the expectation
that activity will ensue. In collaboration diagrams, a message is shown as a labeled arrow placed
near a link.
• The message is directed from sender to receiver
• The receiver must understand the message
• The association must be navigable in that direction
Figure.3.4 – Collaboration Diagram for Appointment Booking system

3.5 ACTIVITY DIAGRAM

The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behaviour of the system. Other four diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing the dynamic nature of a system, but they are also used to construct the executable
system by using forward and reverse engineering techniques. The only missing thing in the
activity diagram is the message part.
It does not show any message flow from one activity to another. Activity diagram is sometimes
considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows
different flows such as parallel, branched, concurrent, and single.
It does not show any message flow from one activity to another. Activity diagram is sometimes
considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows
different flows such as parallel, branched, concurrent, and single.
The purpose of an activity diagram can be described as −
• Draw the activity flow of a system.

• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
Features Of The Activity UML Diagram Of Doctor Appointment System:
• Admin User can search Test, view description of a selected Test, add Test, update Test
and delete Test.
• Its shows the activity flow of editing, adding and updating of schedule.
• User will be able to search and generate report of Doctors, Appointment, Fees.
• All objects such as Test, schedule, Fees) are interlinked.
• Its shows the full description and flow of Test, Appointment, Fees, Doctors, schedule.

User activity diagram:
Figure.3.5.1 – User Activity Diagram for Appointment Booking system

Admin Activity Diagram:
Figure.3.5.2 – Admin Activity Case Diagram for Appointment Booking system
Doctor’s activity diagram
Figure.3.1 – Doctor Activity Diagram for Appointment Booking system

3.6 DATA - FLOW DIAGRAM (LEVEL – 0)

The DFD for Doctor Appointment System is the overall flow of data on the project. It is used
to document the transformation of data (input-output) for project development. This doctor
appointment system DFD consists of DFD levels 0, 1, and 2. It also uses entities, processes,
and data to define the whole system.
Zero Level Data Flow Diagram (0 Level DFD) Of Doctor Appointment System:
This is the Zero Level DFD of Doctor Appointment System, where we have elaborated the
high-level process of Doctor Appointment. It's a basic overview of the whole Doctor
Appointment System or process being analyzed or modeled. It's designed to be an at-a-glance

view of Timeslot Patient and Medicine showing the system as a single high-level process, with
its relationship to external entities of Doctor Appointment and Booking. It should be easily
understood by a wide audience, including Doctor Booking and Timeslot In zero level DFD of
Doctor Appointment System, we have described the high level flow of the Doctor Appointment
system.
Figure.3.6.1 – Data Flow Diagram for Appointment Booking system
First Level Data Flow Diagram (1st Level DFD) Of Doctor Appointment System:
First Level DFD (1st Level) of Doctor Appointment System shows how the system is divided
into sub-systems (processes), each of which deals with one or more of the data flows to or from
an external agent, and which together provide all of the functionality of the Doctor
Appointment System system as a whole. It also identifies internal data stores of Medicine,
Patient, Timeslot, Patient, Booking that must be present in order for the Doctor Appointment
system to do its job, and shows the flow of data between the various parts of Doctor, Booking,
Patient, Medicine, Timeslot of the system. DFD Level 1 provides a more detailed breakout of
pieces of the 1st level DFD. You will highlight the main functionalities of Doctor Appointment.

Second Level Data Flow Diagram (2nd Level DFD) Of Doctor Appointment System:
DFD Level 2 then goes one step deeper into parts of Level 1 of Doctor Appointment. It may
require more functionalities of Doctor Appointment to reach the necessary level of detail about
the Doctor Appointment functioning. First Level DFD (1st Level) of Doctor
Appointment System shows how the system is divided into sub-systems (processes). The 2nd
Level DFD contains more details of Medicine, Patient, Timeslot, Patient, Booking.
Appointment, Doctor.

CHAPTER 4- DESIGN
4. DESIGN
Software design is the process of envisioning and defining software solutions to one or more sets
of problems. One of the main components of software design is the software requirements analysis
(SRA). SRA is a part of the software development process that lists specifications used in software
engineering.
4.1 Data Design
Data design is the first design activity, which results in less complex, modular and
efficient program structure. The information domain model developed during analysis
phase is transformed into data structures needed for implementing the software. The
data objects, attributes, and relationships depicted in entity relationship diagrams and
the information stored in data dictionary provide a base for data design activity. During
the data design process, data types are specified along with the integrity rules required
for the data.

4.1.1 ER Diagram
An entity relationship diagram (ERD) shows the relationships of entity sets stored in a
database. An entity in this context is an object, a component of data. An entity set is a
collection of similar entities. These entities can have attributes that define its properties.
A model that represents system data by entity and relationship sets is called E-R
(EntityRelationship) diagram. It is a detailed logical representation of the data for an
organization. The entity-relationship (E-R) diagram is based on a perception of a real
world which consists of a set of basic objects.


4.2 System Architecture

The software architecture diagram is a visual presentation of all of the aspects that constitute a
system, either in part or whole. It is a depiction of a set of concepts that comprise architecture,
such as its principles, components, and materials. It is also a system diagram used to abstract
the general layout of the software system as well as the interactions, limitations, and limits
between parts.

4.2.1 Structure chart

Structure Chart represent hierarchical structure of modules. It breaks down the entire
system into lowest functional modules, describe functions and sub-functions of each
module of a system to a greater detail. Structure Chart partitions the system into black
boxes (functionality of the system is known to the users but inner details are unknown).
Inputs are given to the black boxes and appropriate outputs are generated.

CHAPTER 5- IMPLEMENTATION
5. IMPLEMENTATION
The word implementation usually refers to installing a new hardware or software system or
application. It can also mean the inclusion of a specific technical specification, software component
or software standard. For example, software development tools contain implementations of a
programming language.
5.1 Implementation of modules

▪ Admin module
▪ User module (patient)
▪ Doctor module
5.1.1 Admin module:
▪ manage department of hospitals, user, doctor.
▪ watch appointment of doctors
▪ watch transaction reports of patient payment
▪ Bed, ward, cabin status
▪ watch blood bank report watch medicine status of hospital stock

▪ watch operation report watch birth report


5.1.2 user module(patient):

▪ View appointment list and status with doctors
▪ View prescription details
▪ View medication from doctor
▪ View doctor list
▪ View blood bank status
▪ View operation history
▪ View admit history. like bed, ward icu etc
▪ Manage own profile



5.1.3 Doctor module:

▪ Manage patient. account opening and updating
▪ Create, manage appointment with patient
▪ Create prescription for patient
▪ Provide medication for patients
▪ Issue for operation of patients and creates operation report ▪ Manage own profile





Login

Logout

5.2 Results
5.2.1 User Module Result

• User login
• User registration

• User dashboard
• User details

5.2.2 Admin Module Results

• Admin login
• Admin dashboard

• Doctor’s details
• Patient’s details

• Appointment Schedule details
• Doctor’s schedule details

• Admin logout
5.2.3 Doctor’s Module Results

• Doctor login

• Doctor scheduled appointments
• Doctor total appointments

• Doctor Profile data

CHAPTER 6 – TESTING
6. TESTING
Software Testing is evaluation of the software against requirements gathered from users and
system specifications. Testing is conducted at the phase level in software development life
cycle or at module level in program code. Software testing comprises of Validation and
Verification. The benefits of testing include preventing bugs, reducing development costs and
improving performance.
6.1 Testing Objectives

The objective of testing is to uncover errors in a program and makes it feasible task.
Verification is the checking or testing of items, including software, for conformance and
consistency by evaluating the results against pre-specified requirements.
6.2 Testing Scope

The scope of a test defines what areas of a customer's product are supposed to get tested, what
functionalities to focus on, what bug types the customer is interested in, and what areas or
features should not be tested by any means.
6.3 Testing Principles
• Testing shows presence of defects.

• Exhaustive testing is not possible.
• Early testing.
• Defect clustering.
• Pesticide paradox.
• Testing is context dependent.
• Absence of errors fallacy.

6.4 Testing Method Used
• White Box Testing: In this technique, the close examination of the logical parts
through the software are tested by cases that exercise species sets of conditions or loops,
all logical parts of the software checked once errors that can be corrected using this
technique are typographical errors, logical expressions which should be executed once
may be getting executed more than once and error resulting by using wrong controls
and loops. When the box testing tests all the independent part within a module a logical-
decisions on their true and the false side are exercised, all loops and bounds within their
operational bounds were exercised and internal data structure to ensure their validity
were exercised once.
• Black Box Testing: This method enables the software engineer to device sets of input
techniques that fully exercise all functional requirements for a program, black box
testing tests the input, the output and the external data. it checks whether the input data
is correct and whether we are getting the desired output.
• Alpha Testing: Acceptance testing is also sometimes called alpha testing Be spoke
systems are developed for a single customer. The alpha testing proceeds until the
system developer and the customer agree that the provided system is an acceptable
implementation of the system requirements.
• Beta Testing: when a system is to be marked as a software product, another process

called beta testing is often conducted. During beta testing, a system is delivered among
a number of potential users who agree to use it. The customers then report problems to
the developers. This provides the product for real use and detects errors which may not
have been anticipated by the system developers.
• Unit Testing: Each module is considered independently; it focuses on each unit of

software as implemented in the source code. It is white box testing.

The steps involved during Unit testing are as follows:
• Preparation of the test cases.

• Preparation of the possible test data with all the validation checks.
• Complete code review of the module.
• Actual testing done manually.
• Modifications done for the errors found during testing.
• Prepared the test result scripts.
The unit testing done included the testing of the following items:
• Functionality of the entire module/forms.
• Validations for user input.
• Checking of the Coding standards to be maintained during coding.
• Testing the module with all the possible test data.
• Testing of the functionality involving all type of calculations etc.
• Commenting standard in the source files.
After completing the Unit testing of all the modules, the whole system is integrated with
all its dependencies in that module. While System Integration, we integrated the modules
one by one and tested the system at each step. This helped in reduction of errors at the time
of the system testing.
• Integration Testing: Integration testing aims at constructing the program structure

white at the same constructing tests to uncover errors associated with interfacing the
modules. modules are integrated by using the top-down approach.
• Validation Testing: Validation testing was performed to ensure that all the functional
and performance requirements are met.
• System Testing: It is executing programs to check logical changes made in it with

intention of finding errors a system is tested for online response, volume of transaction,

recovery from failure etc. System testing is done to ensure that the system satisfies all
the user requirements.
The steps involved during System testing are as follows:
• Integration of all the modules/forms in the system.

• Preparation of the test cases.
• Preparation of the possible test data with all the validation checks.
• Actual testing done manually.
• Recording of all the reproduced errors.
• Modifications done for the errors found during testing.
• Prepared the test result scripts after rectification of the errors.
The System Testing done included the testing of the following items:
• Functionality of the entire system.

• User Interface of the system.
• Testing the dependent modules together with all the possible test data scripts.
• Verification and Validation testing.
• Testing the reports with all its functionality.
After the completion of system testing, the next following phase was the Acceptance Testing.
Clients at their end did this and accepted the system with appreciation. Thus, we reached the
final phase of the project delivery.
System testing includes functional & non- functional testing and is performed by the testers.
Acceptance testing is functional testing and is performed by testers as well as a customer.
Testing is performed using test data created by the testers. Real/Production data is used while
performing acceptance testing.
There are four main stages of testing that need to be completed before a program can be cleared
for use: unit testing, integration testing, system testing, and acceptance testing.

6.5 Sample Test Data

For Users
Use case User Input Desired Actual Resu
Output Output lt
Login Verify User’s login Approve Logged pass

with Valid data in
Verify User’s login Error Invalid pass

with Invalid data
Verify all users Approve Valid pass

home links
password Verify the user Approve Passwo pass

change password rd
with valid data change
d
Verify the user Error Invalid pass
change password
with invalid data
Verify the user Approve Valid pass

change password
with existing data
Logout Verify the user Approve Logged pass

logout out
User’s details are Approve Valid pass

editable
Table 6.5.1- User test cases

For Doctors
Use User Input Desired Actual Result
case Output Output
Login Verify doctor login Approve Logged in pass
with data
Verify doctor login Error Invalid pass

with invalid data
Verify all doctor’s Approve Valid pass

home links
Logout Verify the doctor Approve Logged out pass

logout
Verify the doctor Error Invalid pass

login without data
Verify new details of Approve Added pass

new doctors can be
added to the system
Verify that the Approve Updated pass

details of existing
users can be updated
in the system.
Verify that the Approve Deleted pass

doctor’s record can
be deleted from the
system.
details Verify that for each Approve Visible pass

doctor’s details like
their timings,
specialty, fee,
patient visited etc is
visible to the
authorized users.
Doctor’s details are Approve Valid pass

editable
Table 6.5.2- Doctor test cases

For admin
Use case User Input Desired Actual Result
Output Output
Login Verify admin login Approve Logged in pass
with valid data.
Verify admin login Error Invalid pass

with invalid data.
Logout Verify admin logout Approve Logged out pass
Check for the Approve Valid pass

validation messages
spellings and text.
Check Add, Edit, Approve Valid pass

Update, Delete, Block
functionality in admin
panel.
Admin Dashboard: Approve Valid pass

Data Calculation
should be worked
perfectly and proper
calculated data should
be displayed on
Dashboard with List or
Graph.
managing Check for Uploaded Approve Valid pass

Image should be set
perfectly in fields in
admin panel.
Table 6.5.3- Admin test cases

6.6 Results
6.6.1 For User
• User login
• Login page

6.6.2 For Doctor
• Doctor Profile
• Doctor’s Schedule

• Edit doctor’s schedule

• Schedule management
• Logging out

6.6.3 For Admin
• Admin login wrong credentials
• Adding doctor’s

• Appointment list
• Patient details

CHAPTER 7 – LIMITATION
7. Limitation of Project
Although I have put my best efforts to make the software flexible, easy to operate but
limitations cannot be ruled out even by me: Though the software presents a broad range of
options to its users some intricate options could not be covered into it, partly because of logistic
and partly due to lack of sophistication. Paucity of time was also major constraint; thus it was
not possible to make the software full-proof and dynamic Lack of time also compelled me to
ignore some part such as storing old result of the candidate etc.
Considerable efforts have made the software easy to operate even for the people not related to
the field of computers, but it is acknowledged that a layman may find it a bit problematic at the
first instance. The user is provided help at each step for his convenience in working with the
software.
List of limitations which is available in the Doctor Appointment System:

• The transactions are executed in off-line mode, hence on-line data for patient, booking
capture and modification is not possible.
• Off-line reports of Doctor, Doctor Schedule, Patient cannot be generated due to batch
mode execution.
• Internet Connectivity: Since our application is only accessible by internet, the user must
have a strong/decent internet connection, to surf.
• Awareness: To increase popularity, our application should be well-known by users.
• Promotion: Our website should be promoted thoroughly on every platform, to gain
popularity.
There are, of course, also drawbacks to seeing your doctor online instead of in person. As with any
technology-assisted treatment, electronic glitches are a possibility. It can be especially frustrating
to be in a change with a doctor and keep losing the connection. Other issues can involve lags in
chat or audio that can make communication more difficult. In the end, the best thing you can do is
assess on a case by case basis whether you wish to make an appointment for an in-person visit or
get in a quick appointment online. By choosing the best option for each time you need to see a
doctor, you can be more sure that you are getting the care that you need when you need it

CHAPTER 8- FUTURE SCOPE
8. Future Scope
In a nutshell, it can be summarized that the future scope of the project circles around
maintaining information regarding:
• We can give more advance software for Doctor Appointment System including more
facilities.
• We will host the platform on online servers to make it accessible worldwide.
• Integrate multiple load balancers to distribute the loads of the system.
• Implement the backup mechanism for taking backup of codebase and database on
regular basis on different servers.
Multiple locations and multiple doctors
A good online doctor appointment booking system can manage multiple locations and multiple
doctors. Your clinic may be operational in multiple places and each clinic may have multiple
doctors each of who is available in a particular time slot. Does your system have the capability of
managing these complexities? There should also be no requirement to have multiple staff to manage
all this. Instead the system should manage multiple locations and doctors.
Access appointments on your computer, laptop and mobile phone
As a doctor, you can access the patient appointment information on any device. You should have
the ability to reschedule or cancel appointments in the event of any emergency. The online
appointment system that is hosted on the cloud can give you all the appointment details at any day
in the past, today or in the future.
24*7 booking: Anytime Anywhere
A manual system to manage appointments necessarily requires the availability of a receptionist or

office staff. A doctor appointment booking system, available on the internet, allows patients to book
an appointment from the comfort of their homes, using their computer, laptop or mobile, and at any
time. No matter where they are, they can contact doctors of their choice in any location. Even when
they are traveling they can consult with their doctor. Doctors can also adopt technology in the form
of teleconsulting to reach out to patients in remote corners. True outreach.

CHAPTER 9- CONCLUSION
CONCLUSION
Our project is only a humble venture to satisfy the needs to manage the project work. Several
user-friendly coding has also adopted. this package shall prove to be a powerful package in
satisfying all the requirements of the everyone. The objective of software planning is to provide
a frame work that enables the student to have all the requirements which are made available
within a limited time frame at the beginning of the software project and should be updated
regularly as the project progress.
At the end it is concluded that we have made effort on following points...
• A description of the background and context of the project and its relation to work
already done in the area.
• Made statement of the aims and objectives of the project.
• The description of Purpose, Scope, and applicability.
• We define the problem on which we are working in the project.
• We understand the problem domain and produce a model of the system, which describes
operations that can be performed on the system.
• We included features and operations in detail, including screen layouts.
• We designed user interface and security issues related to system
• Finally the system is implemented and tested according to test cases
Patients are increasingly looking at convenient ways to book appointments. They prefer to use
options available on their mobile or laptop to book appointments. It reduces fatigue and frustration.
Adopting digital technologies involving the use of appropriate tools is recommended for doctors.
The pandemic has made sure that digital modes are embraced even by sections of society that was
either hesitant earlier or had limited access to the internet or such tools. Patients are also likely to
be more welcoming of these tools. Having a presence on the internet is a starting point. Having a
convenient appointment system using which patients can reach you is the next step. Every doctor
should adopt digital tools lest they be left behind.

CHAPTER 10 – BIBLIOGRAPHY AND REFERENCES
1. Roger Pressman, “Software Engineering‐A Practitioner’s Approach”(Sixth Edition), McGraw-

Hill, 2005.
2. Ian Summerville, “Software Engineering”(Ninth Edition), Pearson Education, 2010.
3. Elizabeth Robson and Eric Freeman, “Head First HTML and CSS”(Second Edition), O'Reilly
Media, Inc,2012.
4. David DuRocher, “HTML and CSS Quickstart Guide”(Third Edition), ClydeBank Media
LLC,2011.
5. Jamie Chan, “SQL: Learn SQL (using MySQL) in One Day and Learn It Well”, LCF,2018.
6. Schwartz Baron and Zaitsev, “High Performance MySQL: Optimization, Backups, and
Replication”(Third Edition), O'Reilly Media, Inc,2012.
7. Hugh Williams, “Learning MySQL: Get a Handle on Your Data”(First Edition), O'Reilly
Media, Inc,2006.
8. Janet Valade, “PHP & MySQL For Dummies”(Fourth Edition), Wiley Publishing, Inc.,2009.
9. Laura Thomson, “PHP and MySQL Web Development” (Fifth Edition), Sams Publishing, 2003.
10.Alan Forbes, “The Joy of PHP Programming: A Beginner’s Guide to Programming

Interactive Web Applications with PHP and MySQL”(Fifth Edition), Plum Island,2015.
11.Google for problem solving.
12.Database Programming with MYSQL.
13. http://www.sql-tutorial.com/.
14.https://www.tutorialspoint.com/php.
15.https://www.practo.com/doctors .
16.http://www.javatpoint.com/php-tutorial .
17.https://www.askapollo.com/

Final - SRS - of Doctor - Appointment - Booking - System AYUSH

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final - SRS - of Doctor - Appointment - Booking - System AYUSH

Uploaded by

Copyright:

Available Formats

Software Engineering Project management [BTCS504]

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 1

1.2 Identification of need

1.3 Preliminary investigation

1.4 Problem domain

• Gathering all documentation and authorizations necessary before an appointment.

• Adjusting schedules based on provider preferences for appointment types.

• Handling referrals and the associated authorizations.

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 2

1.5 Solution Domain

1.6 Platform Investigation

• Processor: Intel® Core™ i3 or above.

• Hard Disk: 160 GB or above.

• RAM: 2 GB Min, 8GB recommended.

• Display: Any TFT monitor or higher.

• Keyboard: Any with minimum required keys.

• Operation System: Microsoft® Windows® 7/8/10(32- or 64 bit)

• Front end tool: HTML, JavaScript, css.

• Business Logic: JDK 8, php, xml, json.

• Database: Sql Lite, MySql.

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 3

CHAPTER 2 – SYSTEM REQUIREMENT ANALYSIS

2. SYSTEM REQUIREMENT ANALYSIS

2.1 Information Gathering

2.1.1 Functional Requirements

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 4

▪ It contains a total arrangement of prerequisites required for the application. Which

2.1.2 Non-Functional Requirements

• Capacity: The system needs to support at least 1000 people at once.

• User-Interface: The user interface acknowledges within five seconde.

• Back-Up: The system offers efficiency for data backup.

• Availability: The system is available all the time.

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 5

2.2 System Feasibility

2.2.1 Operational Feasibility

2.2.2 Technical Feasibility

2.2.3 Economical Feasibility

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 6

CHAPTER 3 – SYSTEM DESIGN

3.1 USE CASE DIAGRAM

• It gathers the system's needs.

• It depicts the external view of the system.

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 7

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 8

Figure.3.1 – Use Case Diagram for Appointment Booking System

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 9

3.2 CLASS DIAGRAM

The purpose of the class diagram can be summarized as −

• Analysis and design of the static view of an application.

Classes of Doctor Appointment System Class Diagram:

▪ Doctors Class: Manage all the operations of Doctors

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 10

Figure.3.2 – Class Diagram for Appointment Booking system

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 11

3.3 SEQUENCE DIAGRAM

Figure.3.3 – Sequence Diagram for Appointment Booking system

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 12

3.4 COLLABORATION DIAGRAM

• Each Actor is named and has a role

Links are defined as follows:

AYUSH KUMAR SINGH 20100BTCSAII07156 III YEAR/5th SEM 13

• The message is directed from sender to receiver

• The receiver must understand the message