2.

4 USE CASE DIAGRAM

24 | P a g e
2.5 USE CASE DESCRIPTION

(1) PATIENT

* REGISTRATION
DESCRIPTION - The new patient can register themselves and add their details like name,
age , gender, blood group etc. The patient entry will be made in the hms database.

PRE -CONDITION – The patient must be a new patient, If necessary fields left by user
then prompt user to fill the necessary fields.

MAIN FLOW OF EVENTS

1. Patient selects sign up in login module.
2. A registration form get displayed
3. Patient fills the required details.

POST CONDITIONS - Patient record is added to hms database.

* UPDATION
DESCRIPTION-The patient should be enabled to update his/her details and the changes
should reflect in hms database.

PRE-CONDITION – The patient must be a registered patient, The patient cannot update
details after treatment starts.

MAIN FLOW OF EVENTS

1. Patient logs in to the system.
2. Patient view his record
3. Patient selects update details.
4. Now patient may change the necessary fields.
5. Pop of update details.

POST CONDITION - The record of patient is updated in hms database.

25 | P a g e
*APPOINTMENT
DESCRIPTION - It shows users a list of available doctors, timings, dates and enables
patients to select the most suitable appointment date and doctor. The patient may also
the cancel the appointment.

PRE-CONDITION - The patient must be a registered patient, Patient can fix only one
appointment for a particular department.

MAIN FLOW OF EVENT

1. Patient first logs in to system.
2. View his/her record.
3. Create a new appointment or cancel the appointment..

POST CONDITIONS - patient details are displayed and a new appointment is fix or a
existing appointment is cancelled. The hms database is updated.

*PAYMENT
DESCRIPTION – It enables user to pay the consultant fee of Doctor online.

PRE-CONDITION - The patient must be a registered patient, If Patient don’t wants to pay
online he/she can pay by cash also.

MAIN FLOW OF EVENT

1. Patient first logs in to system.
2. View his/her record.
3. Appointment confirmed by the Doctor then go for Payment.

POST CONDITIONS – A Reciept will be displayed. The hms database is updated

26 | P a g e
(2) DOCTOR
DESCRIPTION- The doctor view patient record/ update his details and add description of
the treatment given to patient.

PRE-CONDITION – The doctor must be a registered doctor, System does not allow the
doctor to modify the qualification, hospital managed details.

MAIN FLOW OF EVENTS

1.Doctor logs in to the system.
2. Doctor may select view patient.
2.1 Patient record is displayed with treatment history.
3. Doctor add description of patient treatment.
4. Doctor may select appointment details
4.1 Appointment Requests is displayed with schedule.
5. Doctor confirm or cancel appointment.

POST CONDITION – The patient and doctor ‘s database are updated.

(3) ADMIN

DESCRIPTION - The admin add doctor, update docotr details and verify payment and
generate Bill/Reciept for the same.

MAIN FLOW OF EVENTS

1. Admin logs in the system.
2. Admin may add doctor new doctor.
2.1 admin fills the doctor’s details.
3. Admin view Doctor record.
3.1 Admin enters the doctor id in the system.
3.2 Doctor details are displayed, Admin can update details.
4. Admin Verify the payment submited by the Patient.
4.1 Generate Bill/Reciept and confirmation message for the same.

PRE –CONDITION - Admin must first log in with his/her credentials.

POST CONDITION - The hms database is updated.

27 | P a g e
2.6 User characteristics

ADMIN
Admin has the full access to the system which means he is able to manage any activity
with regard to the system. He is the highest privileged user who can access to the
system.

Key functions:
•Access patient record, doctor Record.
•Add new doctor entry in system database.
• Confirm Payment and Generate Bill.
• View Records.(Total no of patients treated, doctor added/remove, consultant fee).

PATIENT
Patients can choose the best preferred appointments from the options provided and
can also change the appointment schedule or cancel it. After appt. is confirmed by the
respective doctor they can pay their consultant fee online. Patients have access to only
their records.

Key functions:
• Make appointment.
• Cancel appointment.
• Update Details.
• Payment.
• View Payment History.
DOCTOR
Doctors can view the patient appointment list and provide the confirmation or make
changes in the appointment list if required. Doctors have access to only records of those
patients whom they are treating.

Key functions:
• Confirmation of appointment.
• Cancellation of appointment.
• Modification of appointment list.
• Add Prescription.

28 | P a g e
2.7 Constraints

• System is wirelessly networked with an encryption.

• System is only accessible within the hospital’s website only.
• Database is password protected.
• Should use less RAM and processing power.
• Each user should have individual ID and password.
• Only administrator can access the whole system.

2.8 Assumptions and dependencies

▪ Each user must have a valid user id and password

▪ Server must be running for the system to function
▪ Users must log in to the system to access any record.
▪ Only the Administrator can delete records.

29 | P a g e
CHAPTER 3
SPECIFIC REQUIREMENTS
3.1 Performance requirements
3.2 Safety requirements
3.3 Security constraints
3.4 Software system attributes
3.4.1 Usability
3.4.2 Availability
3.4.3 Correctness
3.4.4 Maintainability
3.4.5 Accessibility
3.5 Functional Requirements

30 | P a g e
3.1 PERFORMANCE REQUIREMENTS

o Response time- The system will give responses within 1 second after checking the
patient information and other information.
o Capacity-The system must support 1000 people at a time
o User interface- User interface screen will response within 5 seconds

3.2 SAFETY REQUIREMENTS

If there is extensive damage to a wide portion of the database due to catastrophic failure,
such as a disk crash, the recovery method restores a past copy of the database that was
backed up to archival storage and reconstructs a more current state by reapplying or
redoing the operations of committed transactions from the backed up log, up to the time
of failure. All the administrative and data entry operators have unique logins so system
can understand who is login in to system right now no intruders allowed except system
administrative nobody cannot change record and valuable data.

3.3 SECURITY REQUIREMENTS

1. Want take the responsibility of failures due to hardware malfunctioning.

2. Warranty period of maintaining the software would be one year.
3. Additional payments will be analyzed and charged for further maintenance.
4. If any error occur due to a user’s improper use. Warranty will not be allocated to it.
5. No money back returns for the software.

3.4 SOFTWARE SYSTEM ATTRIBUTES

3.4.1 Usability: Software can be used again and again without distortion.

3.4.2 Availability: The system shall be available all the time.

3.4.3 Correctness: Bug free software which fulfills the correct need/requirements
of the client.

3.4.4 Maintainability: The ability to maintain, modify information and update fix
problems of the system.

3.4.5 Accessibility: Administrator and many other users can access the system
but the access level is controlled for each user according to their work scope.
31 | P a g e
3.5 FUNCTIONAL REQUIREMENTS

S.No. MODULE APPLICABLE DESCRIPTION

NAME ROLES
1. LOGIN PATIENT PATIENT: Can login using unique Id and
DOCTOR Password after this system shall show
ADMIN his/her profile.

DOCTOR: Can login using unique Id and

Password after this system shall show
his/her profile.

ADMIN: Can login using unique Id and

Password after this system shall show a
profile with links to maintain the website.
2. REGISTRATION PATIENT PATIENT: Can Register by filling all the
required details, after this the system will
verify the details and check if already
registered or not.
3. MAKE APPT. PATIENT PATIENT: Can Select doctor, date time and
make an appointment request after this
system shall show a confirmation for
appointment request.
4. CANCL APPT. PATIENT PATIENT : Can Cancel appointment if want
DOCTOR to by just one click after this system shall ask
for re-schedule or refund of payment.

DOCTOR : Can Cancel appointment if want

to by just one click after this system shall
send a message to the patient.
5. PAYMENT PATIENT PATIENT : Enter payment details and make
payment after this system shall show the
generated bill by the hospital.
6. DOCTOR ADMIN ADMIN : Can add a new doctor by filling all
MODULE the details after this system shall show a
confirmation message.
Can Remove a doctor by just one click after
this system shall show confirmation
message.
32 | P a g e
7. PATIENT PATIENT PATIENT : Can view payment history or can
MODULE search for a particular bill also after this
system shall show a bill or history.

Can also See or search for a doctor by

entering dept. name or doctor id if known
after this system will check for the doctor if
found shall show doctor’s profile.

Can also update details after this system

shall ask for re-enter password and after
verifying password shall update details.
8. ADD DOCTOR DOCTOR : Enter Patient Id and after this all
PRESCRIPTION the treatment details and medicine, remark
and advice for the patient after this system
shall show a message for update.

33 | P a g e
CHAPTER 4
DESIGN

4.1 Data Dictionary

4.2 ER Diagram
4.3 Data Design
4.4 Component Level Diagram

34 | P a g e
4.1 DATA DICTIONARY

1. legal_character [a-z| A-Z]

2. Dig it [0-9]
3. special_ch [@|$|#|+|-]
4. Blood [A|B|AB|O]

1. Name first_name + (middle_name) + last_name

2. first_name {legal_character}*
3. middle_name {legal_character}*
4. last_name {legal_character}*
5. P_ID {legal_character + digit}*
6. D_ID {legal_character + digit}*
7. A_ID {legal_character + digit}*
8. Password {legal_character + digit + special_ch}*
9. Address House_no + (Street) + City
10. House_no {legal_character + digit}*
11. Street {legal_character}*
12. City {legal_character}*
13. Mobile No. { digit }*
14. Blood_Group {Blood + special_ch}*
15. Specialization {legal_character}*
16. Consultant Fee { digit }*
17. Medicine {legal_character + digit}*
18. Advice {legal_character + digit}*
19. Remark {legal_character + digit}*

Table 4.1 Data Dictionary

35 | P a g e
4.2 ER DIAGRAM

36 | P a g e
4.3 DATA DESIGN

S NO. COLUMN DATA CONSTRAINTS DESCRIPTION

NAME TYPE

1. P_ID Varchar(50) Primary Key Contains Unique Id

2. Name Varchar(50) - Contains Name
3. DOB Varchar(50) - Contains Date Of
Birth
4. Gender Varchar(50) - Contains Gender
5. Blood Group Varchar(50) - Contains Blood Group
6. Email ID Varchar(50) - Contains Email Id
7. Address Varchar(50) - Contains Address
8. Mobile No. Integer - Contains Mobile No.
9. CGHS/Private Varchar(50) - Contains Category
Table 4.2 Patient

S NO. COLUMN DATA CONSTRAINTS DESCRIPTION

NAME TYPE

1. P_ID Varchar(50) Primary Key Contains Unique Id

Patient
2. Specialization Varchar(50) - Contains Name of the
Department in which
Patient wants to visit
3. Doctor’s Name Varchar(50) - Contains Doctor
Name Patient Wants
To Visit
4. Consultant Fee Integer - Contains Consultant
Fee Of Doctor
5. Date Date - Contains Date For
The Appointment
6. Time Time - Contains Time For
The Appointment
Table 4.3 Appointment

37 | P a g e
S NO. COLUMN DATA CONSTRAINTS DESCRIPTION
NAME TYPE

1. D_ID Varchar(50) Primary Key Contains unique ID

2. Age Integer - Contains age
3. Gender Varchar(50) - Contains gender
4. Specialization Varchar(50) - Contains
specialization
5. Experience Varchar(50) - Contains experience
of the doctor
(In months)
6. Language Varchar(50) - Contains in how
many languages
doctor can speak.
7. Mobile No. Integer - Contains mobile
number
8. Email ID Varchar(50) - Contains Email Id
9. Schedule Varchar(50) - Contains day and
time for which the
doctor is available
Table 4.4 Doctor

S NO. COLUMN DATA CONSTRAINTS DESCRIPTION

NAME TYPE

1. D_ID Varchar(50) - Contains unique ID

2. P_ID Varchar(50) Primary Key Contains unique ID
3. Medicine Varchar(50) Contains name of the
medicine.
4. Remark Varchar(50) Contains Remark
given by the doctor
for the patient.
5. Advice Varchar(50) Contains any advice
for the patient.
Table 4.5 Prescription

38 | P a g e
S NO. COLUMN DATA CONSTRAINTS DESCRIPTION
NAME TYPE

1. A_ID Varchar(50) Primary Key Contains unique ID.

2. Name Varchar(50) - Contains Name
3. DOB Varchar(50) - Contains Date Of
Birth
4. Gender Varchar(50) - Contains Gender
5. Email ID Varchar(50) - Contains Email Id
6. Mobile No. Integer - Contains Mobile No.
7. Address Varchar(50) - Contains Address
Table 4.6 Admin

S NO. COLUMN DATA CONSTRAINTS DESCRIPTION

NAME TYPE

1. P_ID Varchar(50) - Contains unique ID.

2. Bill No. Varchar(50 Primary Key Contains number of
the bill.
3. Date Varchar(50 - Contains Date of The
bill.
4. Time Varchar(50 - Contains Time of the
bill generated.
5. Amount Int - Contains amount of
the bill.
Table 4.7 Bill

39 | P a g e
4.4 COMPONENT LEVEL DIAGRAM
Book Appointment Module
enum Status { confirm , cancel} ;

int Department, Date , Time, mode, ch;

char Dr_Name(50);

cout<< Enter The Information :

cin>> Department;
cin>>Dr_Name;
cin>> Date;
cin>> Time;
bool Appointment = cancel;

cout<<Mode;
cout<<1.Cash;
cout<<2.Debit Card/Credit Card
cout<<3.Net Banking
cout<<Enter mode of payment;
cin>>mode;

if(mode==1)
{
Generate a Receipt and send confirmation message;
}
else if(mode == 2)
{
Enter Card Details
Make Payment
Send confirmation message
}
else
{
Enter Account Details
40 | P a g e
Make Payment
Send confirmation message
} //end if

Send appointment Request to the doctor

Doctor will check the Appointment Requests;

cout<<Mode;
cout<<1.Confirm;
cout<<2.Cancel;
cout<<Enter Your choice;
cin>>ch;

if(ch==1)
{
Appointment = Confirm;
Send a Confirm Message to the patient.
}
else
{
Send a Cancel Message to the patient.
}//end if

41 | P a g e
42 | P a g e
CHAPTER 5
ESTIMATION AND SCHEDULING

5.1 Project Scheduling

5.2 Timeline chart
5.3 Size Estimation (FUNCTION BASED METRICS)
5.4 Cost Estimation (COCOMO II MODEL)

43 | P a g e
5.1 Project Scheduling

Planned Actual Planned Actual Assigned person

TASK ~> Start Start complete complete
PROBLEM Jan W1 Jan W1 Jan W1 Jan W1 Esha, Akansha,
STATEMENT Monica
SOFTWARE MODEL Jan W2 Jan W2 Jan W2 Jan W3 Akansha, Monica
PROJECT Jan W2 Jan W2 Jan W3 Jan W3 Esha, Akansha
SCHEDULING
SRS Jan W3 Jan W3 Feb W1 Feb W1 Esha, Monica
CONTEXT LEVEL Feb W1 Feb W1 Feb W1 Feb W2 Esha, Monica
DIAGRAM
DFD LEVEL - 1 Feb W2 Feb W2 Feb W2 Feb W3 Akansha, Monica
DFD LEVEL - 2 Feb W3 Feb W3 Feb W3 Feb W4 Esha, Akansha,
Monica
DATA DICTIONARY Mar W1 Mar W1 Mar W1 Mar W1 Esha, Akansha
ER DIAGRAM Mar W1 Mar W1 Mar W2 Mar W2 Esha
DATA DESIGN Mar W2 Mar W2 Mar W2 Mar W2 Akansha
USE CASE DIAGRAM Mar W3 Mar W3 Mar W3 Mar W3 Akansha
USE CASE Mar W4 Mar W4 Mar W4 Mar W4 Akansha, Esha
DISCRIPTION
FUNCTION POINT Mar W3 Mar W3 Mar W3 Mar W4 Esha, Akansha,
MATRIX Monica
COCOMO MODEL Apr W1 Apr W1 Apr W1 Apr W1 Esha, Akansha,
Monica
RISK ANALYSIS Apr W2 Apr W2 Apr W2 Apr W2 Esha, Akansha

TESTING Apr W2 Apr W2 Apr W2 Apr W2 Esha, Akansha

Table 5.1 Project Scheduling

Jan – January Feb – February Mar – March Apr – April W - Week

44 | P a g e
5.2 Timeline chart

Month ~> January February March April

Week ~> 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3
PROBLEM STATEMENT
SOFTWARE MODEL
PROJECT SCHEDULING
SRS
CONTEXT LEVEL
DIAGRAM
DFD LEVEL - 1
DFD LEVEL - 2
DATA DICTIONARY
ER DIAGRAM
DATA DESIGN
USE CASE DIAGRAM
USE CASE DISCRIPTION
FUNCTION POINT
MATRIX
COCOMO MODEL
RISK ANALYSIS
TESTING

Table 5.2 Timeline Chart

45 | P a g e