SCHOOL OF INFORMATICS

DEPARTMENT OF COMPUTER SCIENCE

Tittle: Wolayita Sodo University Web Based Student Clinic

Information Management System

Group members
Name ID Number

1. TEZERA TAKELE--------------------------417/11

2. TEWODROS ESHETU--------------------414/11

3. TEMESGEN TESHOME-------------------402/11

4. TEKETEL BELAYNE----------------------394/11
5. YISHAK TEMESGEN----------------------464/11

Advisor:-
1. Mr. MESAY WANA

JUNE, 2023
Wolaita, Ethiopia
List of table
Table 1:actors description..........................................................................................................................13
Table 2:use case staff log in.......................................................................................................................16
Table 3 use case description for admin add staff.......................................................................................17
Table 4 use case description for admin delete staff...................................................................................18
Table 5:use case description for admin update staff..................................................................................19
Table 6 use case description for admin view staff.....................................................................................20
Table 7 use case description for reception add patient...............................................................................21
Table 8 use case description for admin summarize report.........................................................................22
Table 9 use case for view patient...............................................................................................................23
Table 10 use case for manager view report................................................................................................24
Table 11 use case for doctor prescribe.......................................................................................................25
Table 12use case doctor view report..........................................................................................................26
Table 13 use case view prescribe...............................................................................................................27
Table 14 use case description for add drug................................................................................................28
Table 15 use case description for view drug..............................................................................................29
Table 16 use case description for update drug...........................................................................................30
Table 17 use case description for delete drug............................................................................................31

I
List of fiure
Figure 1:system requirements......................................................................................................................6
Figure 2:cost estimation..............................................................................................................................7
Figure 3:patient information......................................................................................................................10
Figure 4:existing and proposed system in process.................................................................................11
Figure 5:use case diagram.........................................................................................................................15
Figure 6 sequence for login.......................................................................................................................32
Figure 7 sequence for view staff................................................................................................................33
Figure 8 sequence for admin add staff.......................................................................................................34
Figure 9sequence for admin update staff...................................................................................................35
Figure 10 sequence diagram for admin delete staff...................................................................................36
Figure 11sequence diagram for manager view patient...............................................................................37
Figure 12sequence diagram for manager view drug..................................................................................38
Figure 13sequence diagram for manager view patient...............................................................................39
Figure 14 sequence diagram for manager view report..............................................................................40
Figure 15 sequence diagram for manger summarize report.......................................................................41
Figure 16sequence diagram for doctor prescription...................................................................................42
Figure 17 sequence diagram for doctor view patient.................................................................................43
Figure 18sequence diagram for reception add patient................................................................................44
Figure 19 sequence diagram for reception update patient..........................................................................45
Figure 20 reception view patient...............................................................................................................46
Figure 21sequence diagram for store man add drug..................................................................................47
Figure 22sequence diagram for store man delete drug...............................................................................49
Figure 23 sequence diagram for store man view drug...............................................................................50
Figure 24sequence diagram for store man delete drug...............................................................................51
Figure 25sequence diagram for dispensary prescription............................................................................52
Figure 26sequence diagram for lab tech report..........................................................................................53
Figure 27Activity diagram for login.........................................................................................................54
Figure 28Activity diagram for admin add staff..........................................................................................55
Figure 29Activity diagram for delete staff.................................................................................................55
Figure 30Activity diagram for update staff..........................................................................................56
Figure 31 Activity diagram for admin view staff.......................................................................................56
Figure 32Activity diagram Manager View drug........................................................................................57
Figure 33Activity diagram manager for view patient................................................................................57
Figure 34Activity diagram for manager for view report............................................................................58
Figure 35 Activity diagram foe doctor prescription...................................................................................58
Figure 36 Activity diagram for reception add patient...............................................................................59
Figure 37 Activity diagram for reception for update patient information..................................................60
Figure 38 Activity diagram Store man view drug......................................................................................60
Figure 39 Activity diagram for store man add drug...................................................................................60
Figure 40 Activity diagram for store man delete drug....................................................................61

II
Figure 41 Activity diagram for lab technician view result.........................................................................62
Figure 42:class diagram.............................................................................................................................63
Figure 45 system architecture....................................................................................................................65
Figure 46 deployment diagram..................................................................................................................65

III
 Catalog
List of table...................................................................................................................................................I

List of fiure...................................................................................................................................................II

Chapter one.................................................................................................................................................1

1.1Introduction....................................................................................................................................1

1.2 Background of the study................................................................................................................1

1.3 Statement of the problem.............................................................................................................2

1.4 Objectives of the project...............................................................................................................2

1.4.1 General objective................................................................................................................2

1.4.2 Specific objective................................................................................................................2

1.5 Scope of the study.........................................................................................................................2

1.6 Limitation of the study...................................................................................................................3

1.7 Methodology.................................................................................................................................3

1.7.1 Data collection methodology..............................................................................................3

1.8 Tools used for system analysis and design.....................................................................................4

1.9 Implementation.....................................................................................................................................4

1.10 Software and hardware requirements.........................................................................................4

1.11 Development Environment..........................................................................................................5

1.12Testing technique.........................................................................................................................5

1.13 System requirements...................................................................................................................6

1.14 Feasibility Study...........................................................................................................................7

1.14.1 Economic Feasibility..........................................................................................................7

1.14.2 Developmental cost..........................................................................................................7

1.14.3 Operational Cost...............................................................................................................7

1.14.4 Technical Feasibility..........................................................................................................7

IV
 1.15 Cost Estimation............................................................................................................................7

Chapter Two................................................................................................................................................9

2. System Analysis.......................................................................................................................................9

2.1 Introduction of Existing System.....................................................................................................9

2.2 Players in the existing manual system.........................................................................................10

2.3 Forms and other documents of the existing systems..................................................................10

2.4 strength of the existing system..................................................................................................11

2.5 weakness of the existing system................................................................................................11

2.6 Proposed System.........................................................................................................................11

2.6.1 Functional requirements..................................................................................................12

2.6.2 Non- functional requirements..........................................................................................12

2.7 Analysis model............................................................................................................................13

2.7.1 Use case model.................................................................................................................13

2.8 Use case Diagram of the System.................................................................................................14

2.8.1 use case diagram..............................................................................................................15

2.8.2 Use Case Description........................................................................................................16

2.9 Sequence diagram.......................................................................................................................32

2.10 Activity diagram.........................................................................................................................54

2.11 Class Diagram of the system......................................................................................................62

Chapter Three....................................................................................................................................63

4. System Design....................................................................................................................................63

4.1. Introduction................................................................................................................................63

4.2 Purpose of the system.................................................................................................................63

4.3 Design Goal..................................................................................................................................63

4.4 Proposed system architecture.....................................................................................................64

V
 4.5 Deployment diagram...................................................................................................................65

References.................................................................................................................................................66

VI
Chapter one
1.1Introduction
In the present day, most applications are changed in automated systems. This helps increase the
qualities of the work, reduces the complexity of tasks, keeps the security of the data in
advantageous condition, data transfers make more easily, provide timely and accurate reliable or
quality reports and analysis, provides faster product release, better service, and more reliable
products with better product histories.

Today the most business is done online worldwide, the management of institutions is done
through the networked system all the systems of information management have been
computerized. All these innovations have the aim to simplify life by making a lot of things easily
and in a short time. wolayita sodo university student Clinic Information Management System is
an automated system that is used to manage patient information, drug information, and staff
administration. It is meant to provide the Administration and Staff, with information in real-time
to reduce their workload.

This project concerned developing web based clinic information management system for
wolayita sodo university students. This project aims to simplify the workload for the clinic staffs
to reduce patients waiting time in the clinic.

1.2 Background of the study

Main health centers, clinics, and hospitals are also part of Ethiopia's healthcare system. Only
major cities have full-time doctors, and the majority of hospitals are in Addis Ababa. Access to
quality health care is extremely small, and in many rural areas, it is practically non-existent. This
industrial project will be done on a clinical management system. Good management is a
prerequisite for increasing the efficiency of health services. Of the major obstacles to effective
management of clinics, information system support is the one most frequently cited. Recently
there is a greater need for well-designed information management systems for ensuring that
services are delivered according to standards and data is managed according to manners. Manual
ordering and maintaining the general working systems are some of the issues facing Ethiopia's
healthcare system. Computerizing (automating) a device is one way to solve or answer such a
problem.

1
1.3 Statement of the problem
In the existing system clinics more of the time works its activities manually so this
system has created many problems using or accessing the system. Some of them are listed below:

 Manual-based client registration.

 Data loss
 Shortage of the place to store client’s data manually using a card system.
 Lack of security on the student’s information.
 High work burden for the employee.
 Searching for specific patient information is very time-consuming.

1.4 Objectives of the project

1.4.1 General objective
The general objective of this project is to develop web-based student clinic information
management system for wolayita sodo University.

1.4.2 Specific objective

Here are some specific objectives that would together help us achieve the overall project as
follows
 To study the existing system and find out the problem.
 To design, implement, and test the system
 To enhance the performance of the clinic by managing, requesting, and recording.
 To Increasing the security and privacy of the clinic.
 Better handling of medical information.
 To reduce data redundancy and data mishandling.
 To enhance the better control of the clinic management by avoiding manual errors.
 Deploy the system and maintain it till it fits the needs of the organization

1.5 Scope of the study

This project is designed for wolayita sodo university students. These clinics provide a lot of
services to patients which include; Daily treatment of patients, Keeps records about patients
respectively, with departments that include pharmacy, patient, causality which information will
be used for making reports.

2
1.6 Limitation of the study
The study is limited to the Drug sales, scheduling staff. The system cannot be accessed by blind
people and the proposed system provides only for regular students.

1.7 Methodology
This is a description of methods chosen to achieve the objectives of the proposed system. It
will go on to describe the techniques of data collection that will be employed in the project of
the proposed systems. The methods that will be applied to achieve the specific objectives are
observation, Oral interviews, document analysis.

1.7.1 Data collection methodology

Observation
We went to the clinic and observed their daily routine as regards their current system and they
were manually recording the patient’s records as specified by the receptionists, doctors, and
pharmacist. A follow up will made to determine the time it took to carry out the patient record
management. We observed the system’s weaknesses like it will vulnerable to errors.
Interviewing
In this method, there will interaction between us, the project developer and the Staff.
Interviews will be conducte with the medical potential employees to find out what difficulties
they encountered with the existing system.

Document Analysis
Studying the documents that are use in the past; enables us to get clinic form reports to
understand problems with the existing system, rules for processing data. We have analyze
different documents that are use in the existing system for storing patient information and their
drug store details.

Development methodology
To develop this system spiral model is going to be use spiral model is one of the most important
software development life cycle models which provides flexibility when working on a project. Its
flexibility regarding requirements going to help us incorporate changes at later phases. These
changes might be a result of incorrect assumptions we make during the earlier phases of the
project

3
1.8 Tools used for system analysis and design
We can use tools and technologies such as these for the Software Design and Analysis
Specification.
 Visual Paradigm
 Star UML
This tool will help us design use case model, activity diagram, State chart diagram and
sequence diagram.

1.9 Implementation
System implementation (coding) is the process of writing computer programs to satisfy the
business functional requirements identified during the system analysis phase, as well as the detail
design requirements found during the design phase.
Programming languages used for implementation
Several programming languages will be use to create this system, which will be list below.
 HTML is the basic markup language for building Web pages.
 JavaScript is a programming or scripting language that allows you to create dynamic web
pages.
 CSS specifies how HTML elements should display on a computer, in print, or in other
media.
 SQL is a language to operate database operation such as storing, manipulating and
retrieving data in databases.
 JQuery is a JavaScript Library. JQuery greatly simplifies JavaScript programming.
JQuery is easy to learn.
 Bootstrap is the most popular HTML, CSS, and JavaScript framework for developing
responsive, mobile-first websites.

1.10 Software and hardware requirements

Software requirements
 Microsoft Office.
 Windows operating system.
 PHP (We use PHP language for the back end of the system).
 Visual studio (we will use HTML language for developing the front end of the system)
 MySQL (for database operations)
 Web server (apache server)

4
 Hardware requirements

• Laptop computer or desktop computer (minimum 1 GB ram).

• Printer to print our documentation.
• 64 gigabyte flash drive used to make backup of important information in case of any
damage.
• Processer 800MHz Intel Pentium or equivalent
• Disk space must be 750mb or above.
• Network interface card must be present.
1.11 Development Environment
Software development environment refers to the collection of hardware and software tools we
will use for developing this system.
For the Software Design Specification, we will use tools and technologies such as:
 Online Visual Paradigm
All of this implementation (coding) will take place with Microsoft Visual Studio as the primary
IDE. And to build and run the system, we'll be using XAMPP MySQL for database options, as
well as XAMPP for the web server on our computer.
1.12Testing technique
Various testing methodologies will be included in the proposed system. These testing
methodologies will be used on our proposed system to ensure that it operates according to its
requirements. Functional Tests will be use to ensure that functional requirements are met, while
Non-Functional Tests will be use to ensure that nonfunctional requirements are met.
We will use the following practical testing methodologies:
Unit Test – the assignment of improvement is partitioned into little units (which for our situation
are that the units could be create by various individuals our group) and those units will be tried
independently in the event that they act as they are normal.

Integration Testing in reconciliation testing, there can be different phases of testing in our
proposed framework. To begin with, when the units are incorporated into a greater segment, a
coordination test will be apply by the colleague building up those parts. What's more,
furthermore, those segments will be coordinate with segments create by other group individuals

5
and combination test will be apply here again to guarantee that the incorporate parts act as
require. At long last, System Testing will be apply to test the entire framework in the wake of
incorporating all the sub components. Notwithstanding the useful test systems record above,
there will be nonfunctional testing procedures, for example,

 Performance Testing
 Security Testing

 Usability Testing

1.13 System requirements

The tools to be use for the system are select based on their preferable ability to
• Design an interface
• Create a database
• Run smoothly, efficiently, and effectively
Back end design tool
MySQL is to be use for the database system and PHP language is to be use for developing and
managing the back end of the system
Front end design tool
The user interface is to develop using HTML, JavaScript, and CSS as It connects the front end
and the database easily.
The following illustrates the activities and the corresponding tools to be use.

Figure 1:system requirements

Activities tools/programs

Client-side coding HTML

Client-side scripting JavaScript

Server-side scripting PHP

6
Database server XAMP, MySQL

Browser Chrome. Mozilla Firefox

Analysis tool(s) STAR UML

Documentation MS Word,WPS OFFICE

1.14 Feasibility Study

1.14.1 Economic Feasibility
Here is the economic feasibility of developmental and operating costs.
1.14.2 Developmental cost
The project will be develop by using easily found software and open source libraries. We will
also use the help of the internet for most of the demands we have. We plan to use our personal
computers regarding hard ware [Link] there would be no issues regarding hardware tools
Another factor that can be consider as a developmental cost is time limit but since this project is
our final project we will devote all of our time and energy to it. We say that the developmental
cost is trivial. Hence the proposed system is feasible.
1.14.3 Operational Cost
Operational costs may include that patients that choose to use the website will be charge for
internet usage or mobile data usage (by the ISP of course) accordingly, we can say that the
propose system is economically feasible.
1.14.4 Technical Feasibility
 Input: The main input for the proposed system will be basically for wolayita sodo university
student clinic management system.
 Output: The output for this propose system will be its functionality.
 Software: Software tools are available and found without difficulty.
We believe that it is technically feasible.
1.15 Cost Estimation
Fortunately, most of the tools that are need are already available for free. We’ve describe the cost
needed to develop our system in the below table cost estimation.

Figure 2:cost estimation

7
Items Quantity Cost in
ETB
Per unit Total
Personal computer 1 20,000 birr 20,000 birr
Internet For 3 month 700 birr 2,100 birr
Printing and 200 page 5 birr 1000 birr
binding cost
Pen and paper 1 packet paper and 600 birr and 25 625 birr
3 pen birr
Total 23,725 birr

8
Chapter Two
2. System Analysis
2.1 Introduction of Existing System
There are many clinical management systems available in the market. Most of the systems are
using a manual system to assist them in managing patients' records, and also other functions like
a drug store, user management, and reporting. The purpose of computerizing is to save time,
space, and money and to enhance the patients' record management process to more efficient and
effective, reduce man power. Improve clinical and administrative efficiency, and protect the data.
The Wolayita Sodo University student clinics works manual (card/paper-based.) The manual
(card/paper-based) ineffective, inefficient, and unsafe system can cause trouble in managing a
huge amount of patient records.
In the manual form: They are keeping patients' records manually. One of the most popular
techniques they used is a medical card. Medical cards are printed cards that include brief patient
information. The date tier each visit, diagnosis, and treatment for each diagnosis.
A medical card will be generated by the receptionist when the patient first visits the clinic.
Usually, patients still ask by the receptionist to show their identity card during registration. Then
the receptionist will fill in their information based on what is stated on the identity card. The
receptionist will also get the contact number from the patient as usual. Some of the clinics will
rewrite the new patient information in a record book for backup purposes. After that, the medical
card will be passed to the doctor to write down the diagnosis and treatment information after the
doctor diagnosed the patient and then passed it back to the laboratories. The laboratories check
the patient based on the paper given by the doctor and return the result to the doctor after the
result the doctor makes a prescription. These medical cards will be later kept in a cabinet or a
rack and it is organized according to the reference number on the card. The medical card is
mainly used for recording the diagnosis and treatment that have been done on the patient. The
medical card is also used for reviewing the treatment and diagnosis that is previously done by the
doctor. Normally each patient will have their own medical card.

9
2.2 Players in the existing manual system
 Receptionist: manually record and search patient information
 Doctor: treat and update the patient information (information updated manually). In addition,
doctors can refer other hospital
 Lab technician: diagnosis patient from the requests of doctor send results back to the doctor
manually.
 Dispensary: give the medicine to the patient according to prescription and record manually
prescription details
 Drug store man: record drug manually and controls the drug expiration date
 Manager: control and manage staff and drug, viewing report.

2.3 Forms and other documents of the existing systems

Figure 3:patient information

The existing system like input, process & out puts

10
 Figure 4:existing and proposed system in process

2.4 strength of the existing system

• Data won’t be corrupted.
• It is not complex
• Doesn’t require computer skill
2.5 weakness of the existing system
The absence of a well-established information system to serve patients and staff has led to
inconveniences. This has tantamount to the loss of patient and staff records.
This is basically because of the weakness of the existing system which includes over-reliance on
paper-based work. Paper files consume a lot of the office space, slow recording, processing, and
retrieval of patient details. Accessing and sharing information by different departments is
difficult due to poor information management.
2.6 Proposed System
The system that we are going to develop can solve the problems that we have mentioned in the
existing system. In general, this application will reduce the time, and also it will provide such an
easy way to use it for the patient. Wolayita Sodo university web based student clinic information
management system designed to minimize the problem of the current system which is described
in the problem statement. The application should be able to reduce the burden in registering.

11
The main purpose of this project is:
 To provide computerized patients registration
 To Update, search and record patient information
 To reduce data redundancy and data mishandling
 To Increasing the security and privacy of the clinic and patient profile.
 Calculate and record the expense of accessing the resources found in the clinic that is
attached to the student cost-sharing in a computerized format.

2.6.1 Functional requirements

 The system must update patient information: the system update the patient based on the
type of operation performed, some of the operations are lab diagnosis and prescription.
 The system must search for records: an authorized user will type the search key that he/she
wishes to retrieve; the system will search for the required information.
 The system must perform record and check inventory of laboratory and drug facilities.
 The system must record of submissions of patients, staff, and drug at submit point by the
use of forms.
 The system should be generating report.
 The system must store patient, drug and staff information.
2.6.2 Non- functional requirements
Usability

 Each record stored in the system in a single database server and can be access by users.
 The system should very straight forward to the user and easy to operate by the user
 The massage that is shown when error is detected will be in the English language in terms
that the user will understand.
Reliability
 The system must authenticate the users of the system.
 The error rate of this system must be shrinking.
Performance
 The system must allow the staff to search the patient records in an easy and efficient way
from a large amount of data
 The system response time must be faster and the system should allow the user to open
several tasks at one time when they using it.

12
 Security and Access permissions
 The system must verify and validate all user input and users must be notified in case of
errors detected in the course of using the system
 The system only allows the administrator to delete existing users in the database; the system
should be allowed to add new staff
 The data and information about the patient is the main asset. Therefore, the system must
be highly secured from external threats and unauthorized users. To access the system
users should log in with an authorized user name and password to ensure authentication.
 MD5 allows securing the password for unreadable text.
Backup and Recovery
 Make sure there is an additional server to back up the clinic data in case when the server
is down.
 Use other external discs to back up data
2.7 Analysis model
This section introduces the proposed system with UML system models. System models describe
the model of the envisioned system. For the new system model we will use Use-case models,
sequence diagrams, Analysis level class model, and state chart diagrams
2.7.1 Use case model
Actors represent roles that can be played by users of the system. They are parties outside the
system that interact with the system. The list of actors identified for the system along with their
description is presented in table
Table 1:actors description

Actors Actors Description

Administrator Administrator is a person who is responsible to control overall activity of the
system. The responsibility of the administrator includes adding staff, delete staff,
update the staff, and viewing the staff.

Manager Manager is a person who is responsible to view all activities and who is responsible
to provide solution and also generate report.

Doctor Doctor is a person who works in the Wolayita Sodo university students clinic and
who is responsible for treat the patient.

13
Lab technician Lab technician is a person who works in the Wolayita Sodo university students
clinic and who is responsible for diagnosis the patient.

Drug store Drug store man is a person who is assigned to add, delete ,update new drug in
man store.

Receptionist Receptionists a person who works in the Wolayita Sodo university student’s clinic
and responsible to add patient.

Dispensary Dispensary is a person who prepares the medicine based on prescription.

2.8 Use case Diagram of the System

The use case diagram is concerned with the interaction between the system and actors (objects
outside the system that interact directly with it). It presents a collection of use cases and their
corresponding external actors. A use case is a generic description of an entire transaction
involving several objects of the system. Use cases are represented as ellipses, and actors are
depicted as icons connected with solid lines to the use cases they interact with Use case are about
what the system should do, from the perspective of a user. A use case are describes a desired
behavior independently of implementation details. The goal of use cases is to capture all system-
level function that the users envision. [1]
A use case diagram is helpful in visualizing the context of a system and the boundaries of the
system’s behavior. Each use cases in the use case diagram can also be described using a narrative
form.

2.8.1 use case diagram

14
Figure 5:use case diagram

2.8.2 Use Case Description

The following section will mention a description of the sequence of events and interaction
between the system and actor of some of the essential use cases:

15
Table 2:use case staff log in

Use case number UC-01

Use case name Log in staff

Participating Admin ,manager ,doctor ,reception ,store man, dispensary, lab technician
Actors

Description Enables login staff

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The staff press” log in” tab from the 2 The system displays the login page
dashboard

3 Staff fill the username and password 4 The system validates user name
and password

Alternative flow A1 If the user entered inappropriate information press “Reset” button.

A2 Required filed missed

1. The system displays appropriate message based on missed

filed(s)

2. Go to step 3

Post-condition The staff log in successfully

Table 3 use case description for admin add staff

Use case number UC-02

16
 Use case name Add staff

Participating Admin
Actors

Description Enables add a staff

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The admin press “add staff” tab 2 The system displays” add staff
from the dashboard “page with different text field

3 The Admin fill the information

about staff
5 System successfully save the
message
4 Admin clicks “add staff “ button to
save the information

Alternative flow A1 If the user entered inappropriate information press “Reset”

button.

A2 Required filed missed

3. The system displays appropriate message based on

missed filed(s)

4. Go to step 3

Post-condition The staff information is added

Table 4 use case description for admin delete staff

Use case number UC-03

Use case name delete staff

17
Participating Actors Admin

Description Enables delete a staff

Entry pre-Condition System Validate username and password and the user logged in

User action System response

Flow of Events 1 The Admin press “delete staff” 2 System displays staff
tab from the dashboard information

3 The Admin press “delete 4 The system show delete

button”. successful message

Post-condition The staff information is deleted

Table 5:use case description for admin update staff

Use case number UC-04

Use case name update staff

18
Participating Actors Admin

Description Enables add a staff

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The Admin press “update 2 System displays “staff

button” from the dashboard information “

3 The Admin press ”update 4 The system shows updated

button” to update the staff successful message
information

Alternative flow A1 If the user entered inappropriate information press “Reset” button

A2 Go to step 3

Post-condition The staff information is updated

Table 6 use case description for admin view staff

Use case number UC-05

19
 Use case name view staff

Participating Actors Admin, manager

Description Enables delete a staff

Entry pre-Condition System Validate username and password

and the user logged in

User action system response

Flow of Events 1 The Admin/ manager press “view 2. System displays “staff
staff” tab from the dashboard information”

Post-condition The staff information will be displayed

Table 7 use case description for reception add patient

Use case number UC-06

Use case name Add patient

20
 Participating Receptionist
Actors

Description Enables add a patient

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The Receptionist press “add 2 System displays “patient

patient” tab from the dashboard information “page with
different text fields

3 The Receptionist fill the information 6 The system shows

about new patient successful message

4 The Receptionist press “add patient”

button to save

Alternative flow A1 If the Receptionist entered inappropriate information press “Reset”

A2 Go to step 3

Post-condition The patient information is added

Table 8 use case description for admin summarize report

Use case number UC-07

Use case name Summarize report

Participating Actors Manager

21
Description Enables summarize report

Entry pre-Condition System Validate username and password and the user logged in

User action System response

Flow of Events 1 The manager press “add summarized report 2 . System displays
“tab from the dashboard “report “ page with
different text fields

3 The manager fill the information about the

clinic

4 The manager press “save report button” 5 The system shows

successful message

Alternative flow A1 If the user entered inappropriate information press “Reset” button.

A2 Go to step 3

Post-condition The report information is added

Table 9 use case for view patient

Use case number UC-08

Use case name View patient

Participating Actors Receptionist, Doctor, Manager

Description Enables view a patient

22
 Entry pre- System Validate username and password and the user logged in
Condition

User action system response

Flow of Events 1 The Receptionist/Doctor/Manager 2. System displays “view

press “view patient” tab from the patient “ page with text
dashboard box

4 The Receptionist/Doctor/Manager
view patient information

Post-condition The patient information is displayed

Table 10 use case for manager view report

Use case number UC-09

Use case name view report

Participating Actors Manager

Description Enables view report

23
Entry pre-Condition System Validate username and password and the user logged in

User action System response

Flow of Events 1 The Manager press “view report” 2 System displays “report “
tab from the dashboard page

3 The Manager select any report 4 The system displays the

report information

Post-condition The report information is displayed

24
Use case UC-10
number

Use case name Prescribe

Participating Doctor
Actors

Description Enables prescription

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The Doctor press “prescription” tab from the 2 . System displays
dashboard “patient prescribe “
page with different
3 The Doctor fill the information about patient text fields
prescription
5 The system show
successful message

4 The Doctor press “add prescribe” button to

save the patient prescription

Alternative A1 If the user entered inappropriate information press “Reset” button.

flow
A2 Go to step 3

Post-condition The patient prescription is added

Table 11 use case for doctor prescribe

25
 Table 12use case doctor view report

Use case number UC-11

Use case name View report

Participating Doctor
Actors

Description Enables view report

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The Doctor press “view report” tab from 2 System displays “
the dashboard view report “ page
with different text
fields

3 The Doctor view the report

Post-condition The request information will be displayed

26
 Table 13 use case view prescribe

Use case code UC-12

Use case name view prescribe

Participating Actors Lab technician, Dispensary

Description Enables prescription

Entry pre-Condition System Validate username and password and the user logged in

Flow of Events User action system response

1 The Lab 2 System displays “request “

technician/Dispensary/press page with information
“view request” tab from the
dashboard

3 The Lab technician/Dispensary

view the request information

Post-condition The request information will be displayed

27
 Table 14 use case description for add drug

Use case code UC-13

Use case name Add drug

Participating Store man

Actors

Description Enables add a drug

Entry pre- System Validate username and password and the user logged in
Condition

User action system response

Flow of Events 1 The Store man press “add drug” tab 2 System displays “add
from the dashboard . drug “ page with
different text field

3 The Store man fill the information

about drug

4 The Store man press add drug button 5 The system display
to save the drug information successful message

Alternative flow A1 If the Store man entered inappropriate information press “reset”
button.

A2 Go to step 3

Post-condition The drug information is added

28
 Table 15 use case description for view drug

Use case code UC-14

Use case name view drug

Participating Actors Manager, Dispensary, Store man

Description Enables view drug

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The Manager/Dispensary/Store man 2. System displays “drug “

press “view drug” tab from the page with information
dashboard

3 The Manager/Dispensary/Store man

view the drug information

Post-condition The drug information is displayed

29
 Table 16 use case description for update drug

Use case code UC-15

Use case name Update drug

Participating Actors Store man

Description Enables update drug

Entry pre-Condition System Validate username and password and the user logged in

User action System response

Flow of Events 1 The Store man press “update drug” tab 2. System displays drug
from the dashboard information

3 The Store man update the drug 4 The system shows

information successful updated message

Alternate flow A1 If the Store man entered inappropriate

information press “reset” button.

A2 Go to step 3

Post-condition The drug information is updated

30
 Table 17 use case description for delete drug

Use case code UC-16

Use case name Delete drug

Participating Actors Store man

Description Enables delete drug

Entry pre- System Validate username and password and the user logged in
Condition

User action System response

Flow of Events 1 The Store man press “delete drug” tab 2. The system shows drug
from the dashboard information

3 The Store man delete the drug 4 System displays

information successfully deleted drug
message

Post-condition The drug information is deleted

31
2.9 Sequence diagram
It shows the way objects interact with one another as messages are passed between them. It also
demonstrates the behavior of objects in a use case by describing the objects and the messages
they pass.

Figure 6 sequence for login

32
Figure 7 sequence for view staff

33
Figure 8 sequence for admin add staff

34
Figure 9sequence for admin update staff

35
Figure 10 sequence diagram for admin delete staff

36
Figure 11sequence diagram for manager view patient

37
Figure 12sequence diagram for manager view drug

38
Figure 13sequence diagram for manager view patient

39
Figure 14 sequence diagram for manager view report

40
Figure 15 sequence diagram for manger summarize report

41
Figure 16sequence diagram for doctor prescription

42
Figure 17 sequence diagram for doctor view patient

43
Figure 18sequence diagram for reception add patient

44
Figure 19 sequence diagram for reception update patient

45
46
Figure 20 reception view patient

47
Figure 21sequence diagram for store man add drug

48
Figure 22sequence diagram for store man delete drug

49
Figure 23 sequence diagram for store man view drug

50
Figure 24sequence diagram for store man delete drug

51
Figure 25sequence diagram for dispensary prescription

52
Figure 26sequence diagram for lab tech report

53
2.10 Activity diagram
Activity diagrams are used to show how different workflows in the system are constructed, how
they start and the possibly many decision paths that can be taken from start to finish. They may
also illustrate the where parallel processing may occur in the execution of some activities.

Figure
27Activi
ty
diagram
for
login
 For
the
following activity diagrams we assume the actors are logged in to the system

54
Figure 28Activity diagram for admin add staff

Figure 29Activity diagram for delete staff

55
 Figure 30Activity diagram for update staff

Figure 31 Activity
diagram for admin view staff

56
 Figure 32Activity diagram Manager View drug

Figure 33Activity diagram manager for view patient

57
 Figure 34Activity diagram for manager for view report

Figure 35 Activity diagram foe doctor prescription

58
 Figure 36 Activity diagram for reception add patient

Figure 37 Activity diagram for reception for update patient information

59
 Figure 38 Activity diagram Store man view drug

Figure 39 Activity diagram for store man add drug

60
 Figure 40 Activity diagram for store man delete drug

Figure 41 Activity diagram for lab technician view result

61
2.11 Class Diagram of the system
Unified Modeling Language (UML) class diagrams are the mainstay of object-oriented
modeling. Class models show the classes of the system, their interrelationships (including
inheritance, aggregation, and association), and the operations and attributes of the classes. Class
diagrams are used for a wide variety of purposes, including both conceptual/domain modeling
and detailed structural design modeling. Classes are depicted as boxes with three sections: the
top one indicates the name of the class, the middle one lists the attributes of the class, and the
third one lists the methods. By including both an attribute and a method box in the class. Another
approach would be to have two sections, one for the name and one for the responsibilities. [1]

Figure 42:class diagram

62
 Chapter Three
3. System Design
Software architecture is structured into three layers by dotted lines. Each layer is an abstraction
of functionality. The layer on the bottom offers data management functionality to the services
layer. And the services layer offers functionality to several clients on the Internet. Each layer is
build onto the functionality of the next layer down the stack.
Client machine: - refers to a user's computer that is connected to a network and accesses the
system from server, machine.
Web browser: -The application program that serves for accessing the World Wide Web, one of
the major services on the Internet. In order to view a Web site, by using the website address
(URL).

Server machine: -is a system that responds to requests across a computer network to provide, the
system service

3.1. Introduction
System design model is a transformation of the analysis model in to a system design model. System
design is the first part to get in to solution domain in software development. This chapter focuses on
transforming the analysis model in to design model that takes in to account the nonfunctional
requirements and constraints described in the problem statement and requirements analysis section
discussed earlier

3.2 Purpose of the system

This document describes the design issues of the overall the system. It provides the complete architectural
overview of the proposed system. It is intended to capture and express the significant architectural
decisions which have been made on the system.

3.3 Design Goal

The design goals represent the desired qualities of the system and provide a consistent set of
criteria that must be considered when making design decisions. Design goals of the system are
presented as follows:
• Performance (Response time) : the performance of the existing/manual system, as observed,
is not as satisfactory because it is slow (time consuming) and energy consuming.

63
• Compatibility: The system should be compatible with windows platform and all users know
about the system of the registration.
• Security: The system should be secured that unauthorized user cannot access the data that does
not concern with them.
• Usability: the system should be user friendly for end users.
• Availability: the users should have access to the HUSCIS system whenever they need it.
• Maintenance: In time of failure or need modification the system need to be maintainable
4.4 Proposed system architecture
This gives a high level view of the new system with the main components of the system and the
services they provide and how they communicate. The system is implemented using a three-tier
architecture that comprises of user interface, process management and DBMS as

64
Figure 43 system architecture

3.5 Deployment diagram

Deployment diagram is a structure diagram which shows architecture of the system as deployment
(distribution) of software artifacts to deployment targets. Artifacts represent concrete elements in the
physical world that are the result of a development process.

Figure 44 deployment diagram

65
References

[1] "Designing a Web-Based Blood Bank Information Managemen".

[2] J. W. a. S., in Requirements Engineering A good practice guide, , Ramos Rowel and Kurts Alfeche, ,
1997..

66