GOVERNMENT ENGINEERING COLLEGE ,MODASA

(DOCTOR APPOINMENT BOOKING SYSTEM)

Software Requirements Specification

Submitted by
1. (YASH RASHMIKANT PATIL)
(200160107128)
2. (SOLANKI GOPALKUMAR JESHINGBHAI)
(200160107133)
Table of Contents
1. Introduction
1.1 Background
1.2 Objective
1.3 Scope
1.4 Features
1.5 Gantt chart and pert chart

2. Requirements
2.1 Functional requirement
2.2 Non functional requirement
2.3 H/W and S/W specification

3 . Designing
3.1 Data model
3.2 Architecture
3.3 Diagram ( E-R , use case , DFD , Activity state)

4. Coding and prototypes

4.1 Coding
4.2 prototypes

5. Testing
5.1 Testing method
5.2 Test cases

6. Cost estimation
6.1 Calculate project cost

7. Risk identification
8. Conclusion , Future scope , Reference
 1. Introduction

1.1 Background
have Health care is changing with a new emphasis on patient-centeredness. Fundamental to
this transformation is the increasing recognition of patients' role in health care delivery and
design. Medical appointment scheduling, as the starting point of most non-urgent health care
services, is undergoing major developments to support active involvement of patients. By using
the Internet as a medium, patients are given more freedom in decision making about their
preferences for the appointments and improved access.

1.2 Objective
The main objective of the Project on Doctor Appointment System is to manage the
details of Doctor, Appointment, Patient, Booking, Doctor Schedule. It manages all the
information about Doctor, Doctor Fees, Doctor Schedule, 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,
Appointment, Doctor Fees, Patient. It tracks all the details about the Patient, Booking, Doctor
Schedule.

1.3 Scope
It may help collecting perfect management in details. In a very short time, the collection will
be obvious, simple and sensible. It will help a person to know the management of passed year
perfectly and vividly. It also helps in current all works relative to Doctor Appointment System.
It will be also reduced the cost of collecting the management & collection procedure will go
on smoothly.

1.4 Features
• Creating & Changing Issues at ease,Query Issue List to any depth,Reporting & Charting in
more comprehensive way
• User Accounts to control the access and maintain security ,Simple Status & Resolutions
• Multi-level Priorities & Severities.
• Targets & Milestones for guiding the programmers information
• Attachments & Additional Comments for more
• Robust database back-end
• Various level of reports available with a lot of filter criteria' • It contain better storage capacity.
• Accuracy in work. • Easy & fast retrieval of information. Well designed reports
.• Decrease the load of the person involve in existing manual system.
• Access of any information individually.
• Work becomes very speedy.

1.5 Gantt chart

It is also known as Bar chart is used exclusively for scheduling purpose. It is a project
controlling technique. It is used for scheduling. Budgeting and resourcing planning. A Gantt is
a bar chart with each bar representing activity. The bars are drawn against a time line. The
length of time planned for the activity. The Gantt chart in the figure shows the Gray parts is
slack time that is the latest by which a task has been finished.
Pert chart
PERT chart is organized for events, activities or tasks. It is a scheduling device that shows
graphically the order of the tasks to be performed. It enables the calculation of the critical path.
The time and cost associated along a path is calculated and the path requires the greatest amount
of elapsed time in critical path.
2. Requirements

2.1 Functional requirement

The system should enable patients and doctors to log in.

The system should enable patients and doctors to register.
The system should enable patients and doctors to log out.
The system should allow Patients to book appointment.
The system should allow Patients to make enquiries.
The system should allow Patients to search for available doctors.
The system should allow Patients to modify or cancel their appointment.
The system should allow Patients and Doctors to view and modify their profile.
The system should allow Doctors to set their available time.
The system should enable administrator to log in.
The system should allow administrator to manage users
The system should enable administrator to reply enquiries.
The system should allow administrator to delete past appointments.
The system should allow administrator to manage & access data base.

2.2 Non functional requirement

2.2.1 Reliability
The system should be available when requested for service by users.
The system should have a very low failure rate.

2.2.2 Performance
The system must have a good response time.
 The system should be able to achieve a lot in a specified amount of
time.
The system must run error free while operating with a huge set of
data.

2.2.3 Security
All external communications between the system’s data server and clients must be
encrypted.
The access permissions for system data may only be changed by the system’s
data administrator.

All system data must be backed up every 24 hours and the backup copies stored in a

secure location which is not in the same building as the system.

2.2.4 Usability
The system should include well-structured user manuals.
The system should have Informative error messages.
Efficient help facilities.
The system should have a well-formed graphical user interfaces.
The system should be user friendly.
2.2.6 Safety
The system should maintain a good back up.

2.2.6 Supportability
The system should be able to be transferred from one environment to another.
The system should be easy to maintain
The system should be able to deal with additional international conventions
such as languages, or number formats, styles.
The system should be able to be used on multiple platforms.

2.3 H/W and S/W specification

2.3.1 Hardware requirement

Develop a Doctor appointment booking system web need many hardware
components use in system list out a hardware below
 Product : Dell Inspiron
Ram : 8gb
Processor : Intel core i5
Storage : 256gb

2.3.2. software requirement

Develop a Doctor appointment booking system web need many software .

List out blow

A GRAPHICS EDITOR
WEB BROWSERS
LANGUAGES -: HTML JAVAS CRIPT , CSS
HOSTING IS REQUIRED
3. Designing
3.1 Data model

The Waterfall Model was the first Process Model to be introduced. It

is very simple to understand and use. In a Waterfall model, each
phase must be completed before the next phase can begin and there
is no overlapping in the phases. The waterfall model is the carliest
SDLC approach that was used for software development In "The
Waterfall" approach, the whole process of software development is
divided into separate phases. The outcome of one phase acts as the
input for the next phase sequentially. This means that any phase in
the development process begins only if the previous phase is complete.
The waterfall model is a sequential design process in which progress
is seen as flowing steadily downwards (like a waterfall) through the
phases of Conception, Initiation, Analysis, Design, Construction.
Testing, Production/Implementation, and Maintenance.
3.2 Architectu
 3.2 Diagram ( E-R , use case , DFD , Activity state )

3.2.1 E-R Diagram

3.2.2 use case
3.3.3 DFD
3.3.4 Activity state
Coding and Prototypes
3.3 Coding

Admin’s side

Admin can add doctors , edit doctors , delete doctor

Schedule new doctors session ;
View patient details
View booking of patient ;

Doctor’s side

View their appointment

View their scheduled sessions
View detail of patient
Delete account
Edit account settings

Patient‘s side

create accounts themselves;

view their old booking
delete account
edit account settings;

3.4 prototypes
Admin’s side

doctor’s side

Patient’s side
 4. Testing

4.1 Testing method

5.1.2 During Test Cases that are good at revealing the presence of faults is central to
isuccessful testing. The reason for this is that if there is a fault in the program, the
program can still provide the expected behavior on the certain inputs. Only for the
set of inputs the faults that exercise the fault in the program will the output of the
program devise from the expected behavior. Hence, it is fairto say that testing is as
good as its test case.

The number of test cases used to determine errors in the program should be
minimum. There arctwo fundamental goals of a practical testing activity:-
maximize the number of errors detected and.minimize the number of test cases.As
these two goals are contradictory so the problem of selecting test cases is a complex
one. While selecting the test cases the primary objective is to ensure that if there is
an error or fault in the program, it is exercised by one of its test cases. An ideal test
case is one which succeeds (meaning that there are no errors, revealed in its
execution) only it there are no errors in the program one possible set of ideal test
cases is one which includes all the possible inputs to the program. This is often
called "exhaustive testing", however it is impractical and infeasible as even a small
program can have an infinite input domain.

So to avoid this problem we use "test criteria" in selection of the test cases. There
are two aspects of the test case selection:- specifying a criteria for evaluating the test
cases generating the set of cases that satisfy a given criteria.

The fully automated process of generating test criteria has not been yet found rather
guidelines are only the automated tool available to us previously. The two
fundamental properties for a testing criterion are:- Reliability: a criterion is reliable if
all the sets that satisfy the criteria detect the same error.
Validity: a criterion is valid if for any error in the program there is some set satisfying
thecriteria that will reveal the error.The fundamental theorem of testing is that if a testing
criterion is valid and reliable, if a set satisfying criteria succeeds then the program contains no
errors.
APPROACHES TO TESTING
considered for selection of test cases. Duc to this nature, it is also called "black box
testing". impractical.
There are two fundamental approaches to testing they are:
.3 Functional Testing Black Box Testing

In functional testing the structure of the program is not considered. Test cases are
solely determined on the basis of requirement or specification of the program or
module
Internals of the modules and the programs are not
The most obvious functional testing procedure is "exhaustive testing", which is

The other criteria for generating the test case are to generate them "randomly" this
strategy has a little chance of resulting in a test case that is close to optimal. There is
no appropriate criterion for developing the test case so we have certain heuristic

approaches:
Equivalence Class Partitioning in which the domain of all inputs is divided into a set
ofequivalence classes, so that if any test in that class succeeds, then every test in that
class will succeed i.e. the success of one set element implies the success of the other.
Boundary Value Analysis: It has been observed that programs work correctly for a set
of values in an equivalence class fail on certain values. These values generally lie on
the
boundary of equivalence class. So, in the boundary value analysis we chose an input
for a test case from an equivalence class, such that input lies on the edge of equivalence
class.
Boundary value testcases are also called "extreme cases".
Cause-Effect Graphing: The problem with the prior approaches is that they consider
each input separately i.e. both concentrate on classes and conditions of one input. The
combination of inputs is not considered which is used in many cases. One way to
exercise the combination of various input conditions is to consider all the valid
combinations of the equivalence class of the input conditions. The technique starts
with identifying the causes and the effect of system under testing.There are three
different approaches
5.4 STRUCTURAL TESTING
In the structural approach the test cases are generated on the basis of the actual code
of the program or the module to be tested, This structural approach is sometimes called
"glass boxtesting", This testing is concerned with the implementation of the program.
The content is not to exercise the various input conditions rather different
programming structures and data structures used in the program.to structural testing
they are

5.5 Control flow based criteria

Most common structure based criteria use control flow based testing in which the
control flow graph of the program is considered and coverage of various aspects of
graph are specified as criteria. The various control flow based strategies are
• statement coverage,
• branch coverage and
• all path coverage
5.6 Data Flow based testing
The basic ideabehind the data flow-based testing is to make sure that during testing,
the definitions of variables and their subsequent use is tested. To implement the data
flow-based testing the data flow graph is first made from the control flow graph.
5.7 Mutation Testing:
In the above two testing techniques the focus is on which path to be executed, but
mutationtesting is not a path-based approach. The mutation testing requires that the
set of test cases must be such that they can distinguish between the original programs
and is mutants. In software world there is no fault model as in hardware so most of
the techniques do guess work regarding where the fault must lie and then select the
test cases to reveal those faults. In Mutation testing faults of some pre-decided types
are introduced in the program beingtested. Then those faultsare found in the mutants.

5.8 Implementation, Evaluation And Testing

Implementation is the process of having systems personnel check out and put new
equipment into use, train users, install the new application and construct any files of
data needed to use it. This phase is less creative than system design. Depending on the
size of the organization that will be involved in using the application and the risk
involved in its use, systems developers may choose to test the operation in only one
area of the firm with only one or two persons. Sometimes, they will run both old and
new system in parallel way to compare the results. In still other situations, system
developers stop using the old system one day and start using the new onethe next.
Evaluation of the system is performed to identify its strengths and weaknesses. The
actual evaluation can occur along any of the following dimensions:
Operational Evaluation: Assessment of the manner in which the system functions,
including case of use, response time, overall reliability and level of utilization.
Organizational Impact: Identification and measurement of benefits to the organization
in such areas as financial concerns, operational efficiency and competitive impact.
User Manager Assessment: Evaluation of the attitudes of senior and user manager
within the organization, as well as end-users.Development Performance: Evaluation
of the development process in accordance with such yardsticks as overall development
time and effort, conformance to budgets and standards andother project management
criteriMaintenance is necessary to eliminate errors in the working system during its
working life and to tune the system to any variations in its working environment often
small system deficiencies are found as a system is brought into operations and changes
are made to remove them. System planners must always plan for resource availability
to carry out these maintenance functions. The importance of maintenance is to
continue to bring the new system to standards.Test Case 1: Registration Process:
Description: - This test will perform a check whether system allows to do their
registration or not.Test Data Used: - All the valid user information format.
4.2 test cases

Test Case 1: Registration Process:

Description: - This test will perform a check whether system allows to do their
registration or not.
Test Data Used: - All the valid user information format
Actual Output:- System allows user to do registration,
Pass/Fail:- Pass.

Test Case 2: Login Process.

Description: - This test will perform a check whether system user who is already
register then he/she can do login process.
Test Data Used: - All the valid user information format.
Actual Output: System allows user to do login if he/she can do registration
process.Pass/Fail:- Pass.
Description: This test will perform a check whether system allows a Application to

Test Case 3: Manage User/Customer by Admin:user/customer remove or not from

system and whether this data is updated or not.
Test Data Used: User role as Administrator.
Actual Output: - System allows admin to do these actions. Pass/Fail:- Pass.

Test Case 4: Chose previous education

Description: This test will perform a check whether request for chose steam
User is performed or not.
Test Data Used: - User role as Customer.
Actual Output: - System allows User (Customer)
Pass/Fail:- Pass.

Test Case 5: Review Test

Description: This test will perform a check whether request for Review by User is
performed or not.
Test Data Used: - User role as Customer.
Actual Output: - System allows User (Customer) to do Review. Pass/Fail:- Pass.

Test Case 6: Chat with available Guidance Description: - This test will perform a
check whether for Chat with available Guidance if
User has any query.
Test Data Used User role as Administrator. Actual Output: - System allows admin to
do these actions. Pass/Fail:- Pass.
5. Cost estimation
5.1 cost calculation
he "Constructive Cost Model (COCOMO)" is one of the efficient cost estimation
models widely used in many software projects.
Instead of being a function of a single variable, resource estimations might be
influenced by various factors, resulting in multivariable models. One way of
developing multivariable models is starting with an initial estimate produced by
utilizing the static single-variable model equations. which depend on size, and then
updating the forecast based on other factors. This theory argues that cost is mainly
determined by size, with other factors negligible impact. The Constructive Cost
Model (COCOMO) is one model discussed here.
Before diving into the COCOMO's basic concepts, readers must first understand the
characteristics of software project types in order to apply the model.
COCOMO model techniques divide software projects into three categories: organic,
semi- detached, and embedded.
Semi-detached: A development project can be classified as semi-detached if it
involves a mix of experienced and inexperienced personnel. The team members may
have little expertise with related systems but may be unfamiliar with some system
features under development.

Effort (E) a (KLOC) b PM (Person month)

Time = c(E)d

Person Required = effort/time

Where KLOC denotes the product's size, the number of lines of code 8KLOC. And
the effort is the overall amount of action necessary to finish the work in PM (Person
Months).

E= 2.4(8) 1,05PM

= 21.3PM

T=2.5(21.3) 0.38 Months

= 20.2305Months

Cost required to develop the product = 20.2305 x 15000 = 3,03,457.5

7.Risk management
7.1 Risk Management

Risk management is the process of measuring, or assessing, risk and developing

strategies to manage it. Strategies include transferring the risk to another party,
avoiding the risk.reducing the negative effect of the risk, and accepting some or all
of the consequences of a particular risk.Traditional risk management focuses on
risks that can be managed using traded financial instruments. In ideal risk
management, a prioritization process is followed whereby the risks with the greatest
loss and the greatest probability of occurrence and lower loss are handled later.

7.1.1Risk Identification

After establishing the context, the next step in the process of managing risk is to
identify potential risks. Risks are about events that, when triggered, cause problems.
Hence, risk identification can start with the problem itself.
In this project there can be following risks. The other risk is associated with the
software. If in the software the wrong user is authorized by mistake then he may do
changes that cause the system in dangerous mode. There can be risk of natural
threats.

7.1.2.Risk Analysis

Risk analysis is the important aspect of the system planning, whenever planning the
Website programmer always has to consider the risk of system which he might face
in the App.Risks are of two types:

1.Proactive Risk:

Proactive Risk Management provides an extremely practical guide to tools,

techniques & strategy that best enable that risk-based communication.

2.Reactive Risk-

Risks can occur in many ways because it is one window system to improve existing
real-life system. Risk analysis begins with a detailed study of the risk issues that
have been identified and approve by decision-makers for further evaluation. The
objective is together enough information about the risk issues to judge the likelihood
of occurrence and cost schedule and technical performanceRisk analyses are often
based on detailed information that may come from a variety of Techniques,
including but not limited to:Analysis of plans and related documents Comparisons
with similar systems

7.1.3 Risk Planning

Once risks have been identified and assessed all techniques to manage the risk fall
into one or more of these for major categories: Tolerate (retention)

- Treat (mitigation)

- Terminate (elimination)

-Transfer (buying insurance) Ideal use of these strategies may not be possible. Some
of them may involve trade-offs that are not acceptable to the organization or person
making the risk management decision

7 . conclusion ,future scope, reference

7.1 conclution
Patients are increasingly looking at convenient ways to book appointments. They
prefer to use options available on their mobile or laptop to book appointments. An
online doctor booking appointment system that integrates seamlessly with an E.H.R
is ideal for doctors as well. 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. At Genamet we offer this to doctors. In addition to building a
digital presence for doctors, we also integrate the appointment booking system.

Future scope
Many people in India are suffering from any of these diseases and they go to the
hospital to treat it, but even there people have to wait for the appointment and people
get sick a lot of time, so you sit at home because of this application. This application
will revolutionize the future as you can get information about the doctor and get the
date easily

Reference
www.genamet.com
www.webslesson.com
https://en.m.wikipedia.org