ARSI UNIVERSITY

COLLEGE OF NATURAL AND COMPUTATIONAL

SCIENCES

DEPARTMENT OF COMPUTER SCIENCE

Pharmacy Management System for Arsi University

SUBMITTED TO DEPARTMENT OF COMPUTER SCIENCE

IN PARTIAL FULFILMENT OF THE REQUIREMENT FOR

THE DEGREE OF BACHELOR OF SCIENCE IN COMPUTER SCIENCE

BY

NAME ID NO

1. Abel Fikru ccs/ur7714/11

2. Firaol Damena ccs/ur7736/11
3. Meseker Alemayehu ccs/ur7746/11
4. Muleta Kenea ccs/ur7748/11
5. Robe Tilahun ccs/ur7756/11

ADVISOR: Mr. Abdurehman

Asella, Ethiopia

March-7- 2022
DECLARATION

This is to declare that this project work which is done under the supervision of Mr.
Abdurrahman and having the title Pharmacy Management System for Arsi University is the
sole contribution of: Abel Fikru, Firaol Damena, Meseker Alemayehu, Muleta Kenea and Robe
Tilahun.

No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and have
been cited properly. We will be responsible and liable for any consequence if violation of
this declaration is proven.

Date: March-7-2022

Group Members:

Full Name Signature

1. Abel Fikru ____________________

2. Firaol Damena ____________________
3. Meseker Alemayehu ____________________
4. Muleta Kenea ____________________
5. Robe Tilahun ____________________

I
APPROVAL FORM

This is to confirm that the project report entitled Pharmacy Management System for Arsi
University submitted to Arsi University, College of Natural and Computational Sciences,
Department of Computer Science by Abel Fikru, Firaol Damena, Meseker Alemayehu, Muleta
Kenea, and Robe Tilahun are approved for submission.

Advisor Name Signature Date

------------------------------------------------- ------------------------------ ------------------

Department Head Name Signature Date

------------------------------------------------- ------------------------------ ------------------

Examiner 1 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 2 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 3 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

II
ACKNOWLEDGEMENT

First of all we would like to give a great thanks to the Almighty creator who helped us in all.
We take this opportunity to express our sincere thanks to our Advisors Mr.Abdurahman for
his best guidance and support through his suggestions and ideas throughout our project and
correcting various documents error of our project with attention and care. Additionally, we
would like to thanks to the people who have helped & supported us throughout our study.
Finally, we would like extend special thanks to our parents for their unwavering confidence,
encouragement, and emotional support which was instrumental to the successful completion
of our bachelor degree coursework and for our classmates for their great help and keeping us
some suggestions based on the projects and others.

III
 TABLE OF CONTENTS

Table of Contents Page No

DECLARATION ....................................................................................................................... I

APPROVAL FORM ................................................................................................................. II

ACKNOWLEDGEMENT ....................................................................................................... III

LIST OF FIGURES ............................................................................................................... VII

LIST OF TABLES ...................................................................................................................IX

LIST OF ABBREVATIONS ............................................................................................... X

ABSTRACT .............................................................................................................................XI

CHAPTER ONE ..................................................................................................................... 1

1. INTRODUCTION ................................................................................................................. 1

1.1. Background ..................................................................................................................... 1

1.2. Statement of the Problem ................................................................................................ 1

1.3. Objectives of the Proposed System................................................................................. 2

1.3.1. General Objectives ................................................................................................... 2

1.3.2. Specific Objectives .................................................................................................. 2

1.4. Feasibility Study ............................................................................................................. 2

1.4.1. Technical Feasibility ................................................................................................ 2

1.4.2. Operational Feasibility ............................................................................................. 3

1.4.3. Political feasibility ................................................................................................... 3

1.4.4. Economic Feasibility (Cost Benefit Analysis) ......................................................... 3

1.5. Significance and Beneficiary of the Project .................................................................... 4

1.6. Scope and Limitation of the project ................................................................................ 5

1.6.1. Scope of Project ....................................................................................................... 5

1.6.2. Limitation of project ................................................................................................ 5

1.7. Methodology of the project ............................................................................................. 5

IV
 1.7.1. Data collection tools and techniques........................................................................ 5

1.7.2. System Analysis and Design .................................................................................... 6

1.7.3. System Development Models .................................................................................. 7

1.7.4. . System Testing Methodology ................................................................................ 7

1.8. System Development Tools and Techniques .................................................................. 8

CHAPTER TWO ..................................................................................................................... 10

2. DESCRIPTION OF EXISTING SYSTEM ......................................................................... 10

2.1. Introduction to Existing System.................................................................................... 10

2.2. Users of Existing System .............................................................................................. 10

2.3. Major Function of Existing Systems............................................................................. 11

2.4. Forms and Other Documents of the Existing Systems ................................................. 11

2.5. Drawbacks of the Existing System ............................................................................... 14

2.6. Business rule of the existing system ............................................................................. 15

CHAPTER THREE ................................................................................................................. 16

3. PROPOSED SYSTEM ........................................................................................................ 16

3.1. System Description ....................................................................................................... 16

3.2. Functional Requirement of Proposed System ............................................................... 16

3.3. Non-functional Requirements ....................................................................................... 17

3.3.1. User Interface and Human Factors ........................................................................ 17

3.3.2. Hardware Consideration ........................................................................................ 17

3.3.3. Security Issues ....................................................................................................... 18

3.3.4. Performance Consideration .................................................................................... 18

3.3.5. Error Handling and Validation............................................................................... 18

3.3.6. Quality Issues ......................................................................................................... 18

3.3.7. Backup and Recovery ............................................................................................ 18

3.3.8. Physical Environment ............................................................................................ 19

V
 3.3.9. Resource Issues ...................................................................................................... 19

CHAPTER FOUR .................................................................................................................... 20

4. SYSTEM ANALYSIS ......................................................................................................... 20

4.1. System Model ............................................................................................................... 20

4.1.1. Use Case Model ..................................................................................................... 21

4.2. Object Model ................................................................................................................ 33

4.2.1. Class Diagram ........................................................................................................ 33

4.2.2. Data Dictionary ...................................................................................................... 35

4.3. Dynamic Model ............................................................................................................ 36

4.3.1. Sequence Diagram ................................................................................................. 36

4.3.2. Activity Diagram ................................................................................................... 45

4.3.3. State Chart Diagram ............................................................................................... 51

CHAPTER FIVE ..................................................................................................................... 56

5. SYSTEM DESIGN .............................................................................................................. 56

5.1. Design Goals ................................................................................................................. 56

5.2. Proposed System Architecture ...................................................................................... 57

5.2.1. Subsystem Decomposition and Description .......................................................... 58

5.2.2. Hardware/Software Mapping ................................................................................. 60

5.2.3. Detailed Class Diagram ......................................................................................... 61

5.2.4. Access Control and Security .................................................................................. 63

5.3. User Interface Design ................................................................................................... 65

REFERENCES ........................................................................................................................ 66

VI
LIST OF FIGURES
Figure 1-1: Iterative methodology ............................................................................................. 7
Figure 2-1: Receipt Form ......................................................................................................... 12
Figure 2-2: Prescription form................................................................................................... 13
Figure 2-3: Report Form .......................................................................................................... 14
Figure 4-1: Use case diagram of proposed system .................................................................. 23
Figure 4-2: Class Diagram ....................................................................................................... 34
Figure 4-3: Sequence diagram for login ................................................................................. 37
Figure 4-4: Sequence diagram for register drug ..................................................................... 38
Figure 4-5: Sequence diagram for delete expired drugs .......................................................... 39
Figure 4-6: Sequence diagram for register user ....................................................................... 40
Figure 4-7: Sequence diagram for delete employee ................................................................ 41
Figure 4-8: Sequence diagram for send prescription ............................................................... 42
Figure 4-9: Sequence diagram for sell drugs ........................................................................... 43
Figure 4-10: Sequence diagram for bill print ........................................................................... 44
Figure 4-11: Activity diagram for login................................................................................... 45
Figure 4-12: Activity diagram for register drug ...................................................................... 46
Figure 4-13: Activity diagram for delete expired drugs .......................................................... 47
Figure 4-14: Activity diagram for register employee ............................................................. 48
Figure 4-15: Activity diagram for delete employee ................................................................. 49
Figure 4-16: Activity diagram for send prescription ............................................................... 50
Figure 4-17: State chart diagram for login ............................................................................... 51
Figure 4-18: State chart diagram for register drug.................................................................. 52
Figure 4-19: State chart diagram for delete drug ..................................................................... 52
Figure 4-20: State chart diagram for register employee/user ................................................... 53
Figure 4-21: State chart diagram for delete employee/user ..................................................... 53
Figure 4-22: State chart diagram for send prescription ........................................................... 54
Figure 4-23: State chart diagram for bill print ......................................................................... 54
Figure 4-24: State chart diagram for sell drug ......................................................................... 55
Figure 5-1: System Architecture (Layered Architecture of the System) ................................. 58
Figure 5-2: System decomposition diagram ............................................................................ 59
Figure 5-3: Hardware and software mapping .......................................................................... 60

VII
Figure 5-4: Detailed class diagram .......................................................................................... 61
Figure 5-5: User interface work flow....................................................................................... 65

VIII
LIST OF TABLES
Table 1-1: Hardware Tools ........................................................................................................ 8
Table 1-2: Software Tools ......................................................................................................... 8
Table 1-3: Development languages ........................................................................................... 9
Table 4-1: Use case description for login ................................................................................ 24
Table 4-2: Use case description for employee registration ...................................................... 24
Table 4-3: Use case description for delete employee .............................................................. 25
Table 4-4: Use case description for drug registration .............................................................. 26
Table 4-5: Use case description for check expired date .......................................................... 28
Table 4-6: Use case description for view report ...................................................................... 29
Table 4-7: Use case description for sale drugs ........................................................................ 30
Table 4-8: Use case diagram for send prescription .................................................................. 31
Table 4-9: Use case diagram for print bill ............................................................................... 32
Table 4-10: Data Dictionary .................................................................................................... 35
Table 5-1: Class diagram descriptions ..................................................................................... 62
Table 5-2: Access Control and Security .................................................................................. 64

IX
LIST OF ABBREVATIONS

PMSAU: - Pharmacy management system for Arsi university

CSS: - Cascading Style Sheets

DB: - Database

HTML: -Hyper Text Markup Language

NO: - Number

OOA:-Object Oriented Analysis

OOD: - Object Oriented Design

OOP: - Object Oriented Programming

PHP:-Hyper Text Preprocessor

UI: - User Interface

UML: - Unified Modeling Language

XAMPP: - Cross-Platform Apache MYSQL PHP Perl

RAM:-Random access memory

LAN: - local area network

Ip: - internet protocol

USB: - Universal serial bus

DVD: - digital optical disc

CD:-compact disk

X
ABSTRACT

This project is insight into the design and implementation of an automated Pharmacy
Management System. The current pharmacy management system does different activities in
the pharmacy like; drug management (register, arranging on the shelf), report writing to the
manager and etc. while doing those and other tasks it leads to different problems such as,
loss, duplication and redundancy of data and information, and other related problems. Due to
this reason we have proposed automated Pharmacy Management System that overcome
problems encountered in manual operation of existing system. To develop a proposed system
we followed Iterative model of software development. It involves planning, requirement
gathering and analysis, designing system, implementing, verification, evaluation and
deploying. In this document we have discussed the first four steps and we will proceed the
next steps on the next phase of this project. To collect data we have used methods like
interview, direct observation and existing documents analysis. To analyze and design system
we have used object oriented analysis and object oriented design methods. In the
implementation phase planned to use system development languages like PHP, CSS, HTML,
JavaScript, and MySQL. The system we are developing is analyzed using different model of
analysis like; Functional model by using Use case diagram, Object model by using class
diagram and data dictionary and finally dynamic model by using sequence diagram, activity
diagram, and state chart diagram.

XI
 CHAPTER ONE

1. INTRODUCTION

1.1. Background

Technology is spreading its wing in almost every walk of human life activities. Now a day it
is better if every activity is done using technology in order to fulfill the need of human being,
Organization and Enterprise. As today’s world stock control and managing processes have
been tedious and a complicated process in many organizations. This has been so because
these processes are done manually, placing the work load on the general staff.

Hence Pharmacy management system is a management system that is designed to improve

accuracy and to enhance the performance of the task in the pharmacy. It is an automated
system which helps to the employee inside the pharmacy to facilitate the activity of the
pharmacy in a manner way. [1]

In the pharmacy there are two places in which the drugs are available .Those are stock and
store. The stock is the place in which the drug that needs to be sold is stored. And the store is
the place in which the new bought drug is stored.

At present time manual system is being utilized in the pharmacy. It requires the pharmacy
employees to manually monitor each drug that is available in the pharmacy. This usually
leads to mistakes as the workload of the pharmacist increases.

1.2. Statement of the Problem

The current stock control and managing processes is tedious and complicated which
leads in too many difficulties or mistakes such as, difficulty of getting full information
about drugs which is finding drugs based on their categories and using shelf number
(location) specially when immediately needed, difficulty to identify which drugs are out
dated or expired, Incapability of control on sold / remaining product in the pharmacy and
Preparing bill report for each drug takes long time.

1
 1.3. Objectives of the Proposed System

1.3.1. General Objectives

The main objective of this project is to develop automated Pharmacy Management System
for Arsi University.

1.3.2. Specific Objectives

In order to achieve the main objective, we have the following specific objectives: -

 Investigate and analyzing the existing system.

 Identify the problems of the existing system.

 Perform requirement analysis.

 Prepare design for the proposed system.

 Implement and test the system for validation under variety of conditions

 Demonstrate the potential of the system for further application and scalability.

1.4. Feasibility Study

This is the study carried out so as to check if the whole process is viable. It is a preliminary
investigation which emphasized “look before you reap” approaches before starting and
implementing the project, It involves determining the implications of the system technically,
in terms of operation and also economically in comparison to the system in existence. [2]

1.4.1. Technical Feasibility

Automated Pharmacy Management System for Arsi University is technically feasible. In

order to ensure whether the system is technically feasible or not, the system should specify
the following cases:

 The software currently possesses the necessary technology, because it achieves the
required goal. As much as possible we tried to encounter all hardware and software
requirements and also the technology is easily available and deployed everywhere.

2
  The new system posses’ necessarily technical experts: In this project we use
programing languages such as HTML, PHP, java script and CSS to develop the new
system.

1.4.2. Operational Feasibility

This project is operationally feasible, because the proposed system is a good solution maker
for the problem or specific solution will work in the existing system and create a good
environment towards the user of the system. The proposed system is operationally feasible
because:

 We have all the resource needed for its implementation. These resources are desktop
computers, servers(for database), and so on that currently used by the University and
the student union.
 The system will minimize the time and man power needed to give fast and hospitable
service to the users.

1.4.3. Political feasibility

The system to be developed is not conflict with any government directives, because it gives
services for the people effectively and efficiently, all the stakeholders also agreed before the
system developed. So the government is profitable and the system will be politically feasible.

1.4.4. Economic Feasibility (Cost Benefit Analysis)

This stage determines the cost or value analysis. It can be software, hardware, and the people.
The new proposed system will be economically feasible because it takes less capital as
compared as the existing system. The existing system uses paper and pen for data registration
and if an error occurs during the process that paper will be thrown and be waste also needs
more place to store those forms but the proposed system contains database server which has
huge (sufficient) memory uses as storage and allows modifying any errors; also has not waste
of resources because of errors can be corrected. The other thing is that it reduces man power
since many activities can be done by the system.

3
 1.5. Significance and Beneficiary of the Project

The significance can be estimated in terms of energy, time which means the advantage is real
or actual rather than imaginary or visionary. For instance, improving response time,
producing error free out put such as producing information.

The significance of this project are as follows: -

 Provides better stock and store management: -which is it provides efficient, flexible
and reliable items (drugs) storing, locating and selling.

 To know the medicine that is finished in the pharmacy and replaces it by new
medicine in computerized way.

 To know the medicine which their expired date is reached or passed.

 Allows automated prescription acceptance from the hospital doctor which decreases
the ambiguities that can occur by the manual prescription.

 Bring better satisfaction for the client/customer.

 Decreases the work load of the pharmacy staff/employees.

Beneficiaries of the project: -

Here we described the benefits that are expected to gain after the development of the system.

 To the pharmacist
o Decreasing more time consumption
o Increasing job satisfaction and eliminating tedious tasks
o Helping pharmacists by facilitating the work load

 To the manager: -To control the activity which is done in the pharmacy in simple
manner.

 To the customer
o Gets good and fast services / Saves their time and energy since the system
decreases the client crowed
o Gets safe medicines which its date is checked and stored in a proper air
condition

4
 1.6. Scope and Limitation of the project

1.6.1. Scope of Project

The project will concentrate on the stock control activities and business processes like
maintaining stock (in store and stock) which will involve the store management, sending and
receiving prescription orders through the system as the major areas of concern. The system
will determine economic feasibility as well as viability of future trends of growth in the
organization. However, the system will also be confined to the crucial stages of system
development life cycle which will include planning, analysis, design and implementation of a
computerized stock control system. Since the system will be built in conjunction with the
current system. A prototype of the proposed system will be produced with an implementation
plan.

1.6.2. Limitation of project

The following are some scopes we excluded from proposed system because of lack of enough
time and if it these are included the project become with wide range scope which is difficult
to be handled by us.

 It works for the one who understand English language (we have not planned to use
other language).

 Online payment system

 Online Patient detail report: - laboratory report, patients card report and others which
are not necessary for prescription.

 Blind users can’t interact with the system

 Can’t identify if the pharmacist sells only the prescriber drug or not

 Can’t handle the process of purchasing the needed drug for the pharmacy

1.7. Methodology of the project

1.7.1. Data collection tools and techniques

 Data collection Techniques: -

Document analysis: - The team reviewed documents such as books, e-books and some
related previously done projects which are very important to develop our project. During the
5
analysis of documents, we give a special consideration to those documents which can bring
more features to our system.

Interview: This is one of data collection method that enables to gather information from the
organization directly in the form of asking question and getting answers for those questions.
So, we will use this method to gather information by asking the manager of the pharmacy
some basic questions regarding the following issues will be asked (Questionnaires) during the
interview: -

Questionnaires: -

o How drug information management system is going on?

o During managing, are there any problems? If there, what are they?

o What requirements are needed for the process?

Observation: - This is also another data collecting method. In fact, we have also used this
observation method to gather data. This method enables us observing and understanding how
drug information management is going on.

 Data collection Tools: - Pen, Mobile phone (for taking photos and voice record) and
Note book (questioner paper).

1.7.2. System Analysis and Design

The team chooses object-oriented analysis and design approach specifically UML (Unified
Modeling Language) model to analyze and design the system, based on our preliminary
analysis of the old system.

It has the following phases: -

 Object Oriented Analysis (OOA): During this phase we used to Model the functions
of the system (use case modeling), Find and identify the business objects, Organize
the objects and identify the relationship between them and finally model the behavior
of the objects.
 Object Oriented Design (OOD): During this phase we used to refine the use case
model to reflect the implementation environment, Model object interactions and
behaviors that support the use case scenario, and finally update object model to reflect
the implementation environment.

6
We have selected this technique because it has the following advantages: -

 Increase reusability: - the object oriented provides opportunities for reuse through
the concepts of inheritance, polymorphism, encapsulation and modularity.

 Increased extensibility: - when there is a need to add new feature to the system you
only need to make changes.

 Improved quality: - quality of our system must be on time and meet our exceeded
the expectation of the users of our system, improved quality comes from increased
participation of users in the system development

1.7.3. System Development Models

Software development methodology we are going to use for our system development is
iterative software development methodology. Iterative development is a rework scheduling
strategy in which time is set aside to revise and improve parts of the system. [3]This model
iterates requirements, design, build and test phases again and again for each requirement and
builds up a system iteratively till the system is completely built.

Figure 1-1: Iterative methodology

1.7.4. . System Testing Methodology

Before directly deploying this system, the team will perform different testing for its
functionality and meeting customers need. First the team tests each unit at each phase. So, if a
problem is encountered it will immediately fix. Second the team will perform an integration
testing to check whether the system meets all the functional requirements.

7
In order to deliver this system as well operated system to test this project at implementation
phase by using different types of testing methodologies. Those testing methods are:

 Unit testing: -To test the independent module using this mechanism of testing.

 Integration testing: -using this type of testing method to test the modules which are
independent and dependent to each other.

 System Testing: -using these methods will test the functionality of all modules
considering as a single system. System will be tested using the following system
testing procedures.

o Alpha testing: -In this testing method, the system will test by giving the correct
input. It is tested by a customer at the developer Site.

o Beta testing: -In this testing method, team will force the system to be tested for
incorrect data input.

1.8. System Development Tools and Techniques

While developing the project starts from the documentation to the implementation, we will
use the following case tools:

System Development Tools:

Table 1-1: Hardware Tools

Tools Purpose

Flash disk= 32 Gb and CD-R To transfer data from one computer to the
other computer. Used for recovery purpose.

Personal Computer=8Gb RAM and 1Tb To input data, to display the output, to do the
main programs and to insert input and to
Memory/ROM
store information.

Printer For print the documentation.

Table 1-2: Software Tools

8
 Tools Purpose

EdrawMax To draw different diagrams.

Notepad++, Sublime_Text_2.0.2 It is one of the writing editors which help us to

write code using PHP programming language.

MS Word and ppt For write documentation part and For presentation
purpose. Respectively.

Chrome, Internet explorer, Opera mini For Browsing

Table 1-3: Development languages

Tools Purpose

CSS

For Client-side scripting

JavaScript

HTML

PHP For Server-side scripting

XAMPP Database for data storage

9
 CHAPTER TWO

2. DESCRIPTION OF EXISTING SYSTEM

2.1. Introduction to Existing System

Arsi University is one of the public institutions of higher learning in Ethiopia and found in
central part of Oromia Region in Arsi Zone Asella town in kebele 10 near to Rehoboth
General Hospital. Arsi university established in 2014(2006 E.C) by decree No.322/2014 of
the Council of Ministers of the Federal Democratic Republic of Ethiopia. Arsi University
started with four Colleges and one School, namely; College of Agriculture and
Environmental Sciences, College of Health Sciences, College of Business and Economics,
College of Humanities and School of Law and now College of Natural and Computational
science also founded last year.

Asella Referral Hospital (including the pharmacy) was founded in 1964 and is now part of
Arsi University and its College of Health Sciences. As a tertiary hospital, it serves as a
referral hospital for the Arsi Zone, providing healthcare for its more than 3.5 million
inhabitants. The current system of Arsi University pharmacy information management is
manual system.

 It was Haile Selassie First Hospital

 At the beginning it had a capacity of 60 beds

 staffs: -one general practitioner, two nurses, four advanced health Assistants & two
elementary health assistants one junior health assistant training school •

 The name was changed to Asella Hospital after the revolution of Derg regimes in
1975.

2.2. Users of Existing System

An existing system compromises different players to carry out its job. Among those different
actors (players), the most common are: -

 Pharmacist: -The customer comes with the ordered prescription then the pharmacist
looks that order of drug and gives the drug accordingly. The customer gets his/her
requested service from the pharmacist.
10
  Manager: -The manager gets reports from the pharmacist, store coordinator, and
cashier. The reports help the manager to see how services are given to the client.

 Store coordinator: -Store coordinator is responsible to register the drugs that buy
from the private sectors or from the governmental association, and also control the
drug that are goes out to the stock.

 Cashier: -The cashier receives the cost of the drug from the customer ordered by the
pharmacist.

 Doctor: -Gives prescription to the patients to take to the pharmacy.

2.3. Major Function of Existing Systems

The existing system has the following functions

 Drug Registration: -Whenever the new drugs come in to store, the pharmacy Store
coordinator registers those drugs using paper and pen.

 Report preparation: Report is being prepared in the form of paper documentation

from the work done by either of employees.

 Manage Drugs: The pharmacy manager manages drugs and all pharmacy activities
using report paper.

2.4. Forms and Other Documents of the Existing Systems

In the existing system, they use different forms and reports to manipulate different records
associated with the different activities.

 Receipt Form: - It is a paper format that indicates as the patient or pharmacy buys
and sell drug. This form includes name of the patient, price, amount, tax, of purchased
medicine, date. Its picture form is looks like as follows.

11
Figure 2-1: Receipt Form

12
 Prescription paper/form: -even this type of form of paper is sent from the hospital it
remains in the pharmacy and it contains patients name, sex, age, medicines name and
dosage prescriber’s/Doctor’s name and signature (seal) finally the date. Its picture
form is looks like as follows.

Figure 2-2: Prescription form

13
  Report Form
It is a paper format to display the number, type and cost of drugs which are bought for
the pharmacy.

Figure 2-3: Report Form

2.5. Drawbacks of the Existing System

The manual pharmacy management system has many drawbacks. These drawbacks can be
seen from the following perspectives like performance, economic, control, efficiency and
services given by the existing system to the users.

 Efficiency

o Time wastage: - employees waste time due to manual: - data processing, data
entry, report generation and Preparation of different forms.

o Material wastage: - The organization wastes many materials especially

concerning stationery materials, and file cabinets.

Writing recipient and prescription paper can be example for the above two listed problems.

14
  Controlling- since all the records associated with the manual system this may cause
Loss of control on sold / remaining product in the pharmacy.

 Economy: -From view of material, there is high resources usage for unnecessary
expanses, like paper, pen and etc. For each client’s there will be writing paper. The
same is true for drugs report purpose also. This causes the pharmacy to spend more
money for regularly buying of those stationary materials, also they might make
mistakes while writing those report (registration) so, that paper will be waste because
of it will be thrown.

 The performance of any system is required to show to meet the needs of users of that
system. The current system’s performance is weak and measured by its response time.

o Response time: -the performance of the current system is weak because of its
response time is very high. For instance, when a client wants to buy some
drugs by bringing prescription it takes too much time to read (since, mostly it
is difficult hand writing) and search the ordered

2.6. Business rule of the existing system

The existing system has its own mechanism in which its customers are treated. These
include:

BR1: The customer must bring the prescription to buy drugs from the pharmacy.

BR2: The customer must pay to get what she or he need to buy.

BR3: the payment should only be given to the casher.

BR4: The pharmacist must sell the prescribed drugs only.

BR5: Manager should control the entire activity in the stock and should receive clear and
appropriate report from the workers of the pharmacy.

15
 CHAPTER THREE

3. PROPOSED SYSTEM

3.1. System Description

By carefully analyzing and observing the problem of existing system we came up with a
solution that the current manual system should be automated. The automated system will
eliminate/reduce the problem on time, work load and complexity on storing drugs
information. The system will include a database for recording drugs that facilitate fast
information retrieval, modifying, inserting and deleting. It also includes an attractive user
interface that facilitates accessing the database and recording drugs easily.

The system allows the user to enter expiry date for a particular product or drug during
opening stock and sales transaction. It also involves arrival of new batches of drugs, getting
information about the drugs e.g., expiry date, number of drug type left.

Players represent external entities that interact with the system. They manage and perform
the tasks in the system.

The following are main desired solutions of proposed system for problems listed in existing
system:

 Improving the efficiency of the system by ensuring effective managing of services

and activities.

 Generating report

 Reducing the employees’ workload in the organization items functionality

 Automate the prescription writing system

3.2. Functional Requirement of Proposed System

The functional requirement is the services that are provided by the system. It also describes
the interactions between the system and the user, and any other external system. The
Proposed system is expected to provide the following functionalities.
16
  Input requirement

o Search and query of user request data in the database

o Verify the requested information

o Each input items information must include item id, item name, code, quantity,
manufactured company, and expiry date.

 Output requirement

o Produce reports of all drugs purchased and sold in a given period of time

o Display store item that are reach to expired date

o Display employee information to the manager and system admin

o When there is no item in the store the system response the low stock items.

3.3. Non-functional Requirements

Nonfunctional requirement describes visible aspects of the system that are not directly related
to the system. Unlike functional requirement, non-functional requirement deals with
additional quality of the system such as performance, error Handling, usability, availability
and security matter.

Some of the non-functional Requirements are:

3.3.1. User Interface and Human Factors

The user interface shall be simple for the user on how to use the system and easy to learn.
The interface has help files that describe the usage and about office that contains the general
information about the office access publicly of each user interface. The homepage contain the
entry (log in) pages and it is master page.

3.3.2. Hardware Consideration

The system will use high memory capacity and high processing speed computers to help
users in getting instant responses.

17
 3.3.3. Security Issues

The system is secured from malicious users from accessing the database because most of the
information is stored in the server. The authentication is done through password protection in
database manipulation. This means that before entering to the database the system will
request user name and password. This will prevent unauthorized data modification on the
database.

 The system follows a role-based security which means the access level and privilege
for each Users are set by the system administrator.

 The system has authentication mechanism (Username and password).

3.3.4. Performance Consideration

The system should provide response for the users with less time than the previous system. If a
user follows the correct way of execution the system will stay safe if not the system will
respond to that action. It is expected that the system will serve many clients at a time.

3.3.5. Error Handling and Validation

The system handles errors by giving error-message and warning to the user. The error
handling can be seen in different aspects. The system should check the validity of a user
during log in. Any user can view the different part of the system based on the role assignment
that the system provides. The system should handle errors which are occurred due to invalid
inputs of the user then displays error message and additional information’s on how to correct
it.

3.3.6. Quality Issues

Information in database should be as much as possible correct and updated with in a fixed
period of time.

3.3.7. Backup and Recovery

Backups are useful to restore important data or files after they have been accidentally deleted
or corrupted.

18
There are several realistic methods for backing up data. Some of them are Flash Memory,
DVD Backup, Tape Backup, and Hard Drives. The best backup method for data depends
upon many factors, including: the importance of the data, the amount of data to be backed up,
and the funds available for backup.

For the system we are going to develop, we choose Hard Drives because copying and
retrieving data from separate hard drives is very easy and cheap compared to tape drive
systems. All we have to do is plug the hard drive into our computer’s USB port. And while
hard drives do fail, their failure rate is much lower than that of backup media such as CDs.

3.3.8. Physical Environment

Since pharmacy of Arsi university is currently growing in technology issues from time to
time. Its main data center may afford server machine to deploy the system effectively. The
system is expected to withstand the following external factor.

 Less processer speed of personal computer that are caused by dust and other
unnecessary things happened in client computers for accessing the system.

 Less power that causes the system fail or stop functionality.

 The server and the other devices in which system installed should kept in a secured
and air-conditioned rooms

3.3.9. Resource Issues

On the server side the resource required by the server will be a hung memory space, high
speed processor and good connection to serve many users. However, on the client side,
internet access and connection speeds many become an issue.

19
 CHAPTER FOUR

4. SYSTEM ANALYSIS

4.1. System Model

To produce a model of the system which is correct, complete and consistent we need to
construct the analysis model which focuses on structuring and formalizing the requirements
of the system. Analysis model contains three models: functional, object and dynamic models.
The system model can be described by use case diagrams. Class diagrams describe the object
model. Dynamic model can also be described in terms of sequence, state chart and activity
diagrams. For the purpose of this project, we have described the analysis model in terms of
the functional model, object model and dynamic models by using use case, class, activity and
sequence diagrams.

System modeling involves the evaluation of system components in relationship with one
another to determine their requirements and how to satisfy them. Some system modeling
tools will be employed during the course of this project that will support development tasks,
from analysis to design, then to implementation. This will be represented with the use of the
sequence diagram, activity diagram, state chart diagram, collaboration diagram and class
diagram for the Pharmacy Management System.

Here are the scopes of the system modeling phase.

 Functionality description of the system by using use case diagrams.

 Structural description of the system in class diagram.

 Communication of the objects of the system by using sequence diagrams.

 Flow of actions using activity diagram

20
 4.1.1. Use Case Model

The use case model describes the proposed functionality of the new system. A use
case represents a discrete (distinct) unit of interaction between users and the
system. [4]Use cases are tasks of the proposed system.

Generally, use case modeling involves the following activities:

 Identifying if there are any additional actors and use cases,

 Constructing a use case model, and
 Documenting the use case course of events.

Actor identification: -

Actor: is a person, or external entity that plays a role in one or more interaction with the
System.

In the use cases an actor interacts with the system to perform a piece of meaningful work that
helps them to achieve a goal and has access to define their overall role in the system and the
scope of their action. Depending on the above explanation actors in this system are the
following:

 Manager: Controls the overall activity in the shop.

 Pharmacist: Manages the drug information in the stock (receive prescription and sell
drugs).

 Store coordinator: Manages the outgoing and incoming drug from the stock.

 Cashier: Collect the price of the sold items and generate report to the manager.

 Doctor: Send prescription to the pharmacist

Use case identification: -

Each Use Case describes the functionality to be built in the proposed system, which can
include another Use Case's functionality or extend another Use Case with its own behavior.
The most important and basic use cases of this system are the following: -

21
 Login

 Create account

 Update account

o Change users address information

o Change user name /E-mail and password

 View employee

 Delete employee

 Register drug

 Delete drug

 Check expire date

 View available drugs/item

 Report generation

 Report view

 receive prescription

 logout

22
Figure 4-1: Use case diagram of proposed system

23
Use Case Description: -

Table 4-1: Use case description for login

Name Login

ID UC1

Actors Manager, Pharmacist, Casher, Store coordinator, Doctor

Description In order to get into or access the system

Pre-condition 1. The Manager, Store coordinator, Pharmacist, Doctor or Cashier

must open the system

2. Open the system.

3. Click on login link.

4. Login form displayed.

5. Select account type and enter user name and password.

Flow of events 6. Click on the login button.

7. System verifies in the account database.

8. Main form displayed.

9. End of use case.

Post condition 1. Access the system

Table 4-2: Use case description for employee registration

24
Name Employee Registration

ID UC2

Actor’s Manager

Description Register the information of the workers in the pharmacy

Pre-condition 1. Initiate the system

2. Have user name and password

3. The manager opens the system.

4. The manager log to his or her page

5. The manager clicks on the register employee link.

Flow of event 6. The system displays the register employee form.

7. The manager inserts the necessary information of the

employee.

8. The manager clicks on the register button.

9. Then the system will generate successfully message

10. End of use case.

Post condition 1. Access the system

2. Close the system

Table 4-3: Use case description for delete employee

25
Name Delete Employee

ID UC3

Actor’s Manager

Description Delete the employee when it is necessary.

Pre-condition 1. Initiate the system.

2. Have user name and password

3. The manager log to his or her page.

4. The manager clicks on manage employee link.

5. The system displays the delete employee form.

Flow of event 6. Click on the delete button.

7. Then the system will generate successfully message

8. End of use case

Post condition 1. Return to home page or

2. Close the system

Table 4-4: Use case description for drug registration

26
Name Register Drug

ID UC 4

Actors Store coordinator

Description Registering the new drug from the store in to the data base.

Pre-condition 1. Initiate the system.

2. Have user name and password.

3. The Store coordinator opens the system.

4. The Store coordinator log to his or her page.

5. The Store coordinator click on Register drug link.

Flow of event 6. The system displays the register drug form.

7. The Store coordinator will enter the attributes of the

drug.

8. Then click on submit.

7. Then the system will generate successfully message.

9. End of use case

Post condition 1. Return to home page or

2. Close the system

27
 Table 4-5: Use case description for check expired date

Name Check Expired Date

ID UC 6

Actors Store coordinator

Description In order to check the drug that is the verge of the expired date.

Pre -condition 1. Initiate the system.

2. Have user name and password.
3. Open the system.
4. The Store Coordinator log to his or her page.
5. The Store coordinator click on check expired date link.
6. Then the form will be displayed.
7. The Store coordinator enters the expired date of the drug.
8. Then Store coordinator clicks on search button.
9. The system displays the list of the dug that is inserted in its date.
10. The Store coordinator click on the clear button.
Flow of event
11. Then the system will response successfully message.
12. End of use case.
Post Condition 1. Return to home page or
2. Close the system

28
 Table 4-6: Use case description for view report

Name View report

ID UC 8

Actors Manager

Description Viewing report sent from units

Pre -condition 1. There must be list of reports that must be sent by different units.

2. Open the system.

3. The home page will be displayed.
4. The manager inserts user name and password with their account type.
Flow of event 5. The system will verify the user’s name and password.
6. Then the system displays his/her page.
7. The manger clicks on fetch report link.
8. Then the system will display response.
9. End of use case.
Post condition 1. Return to their appropriate page.
2. Close the system

29
 Table 4-7: Use case description for sale drugs

Name Sale Drug

ID UC 7

Actors Pharmacist

Description To sell the drug to the customer

Pre- condition 1. The doctor must send the prescription to the pharmacist.

2. The pharmacist opens the system.

3. The home page will be displayed.
4. The pharmacist inserts user name and password.
5. The system will verify the user’s name and password.
6. Then the system displays his/her page.
7. The pharmacist clicks on prescription link.
8. Then the system displays the prescription list.
9. If any prescription received then go to sale drug link.
10. Click on sale drug link.
11. Enter the necessary information of the customer and the
drug.
12. Then click on the load button/save.
Flow of event
13. Then the system will response successfully message.
14. Then click on send button.
15. Then the system will response successfully message.
16. End of use case.
Post condition 1. Return to home page or
2. Close the system

30
 Table 4-8: Use case diagram for send prescription

Name send prescription

ID UC 5

Actors Doctor

Description Send prescription for the pharmacist.

Pre -condition 1. The doctor must have user name and password.

2. Open the system.

3. The home page will be displayed.
4. The doctor inserts user name and password with their account type.
Flow of event 5. The system will verify the user’s name and password.
6. Then the system displays his/her page.
7. The doctor clicks on write prescription link.
8. Then the system will display response.
9. Then click on send button.
10. End of use case.
Post condition 1. Return to their appropriate page.
2. Close the system

31
 Table 4-9: Use case diagram for print bill

Name Print bill

ID UC 9

Actors Cashier

Description Printing soled drug bill for the customer

Pre -condition 1. There must be list of drugs that must be inserted by the pharmacist

2. Open the system.

3. The home page will be displayed.
4. The cashier inserts user name and password with their account type.
Flow of event 5. The system will verify the user’s name and password.
6. Then the system displays his/her page.
7. The cashier clicks on fetch order link.
8. The cashier clicks on fetch drug link.
9. The list of drugs with corresponding quantity and price.
10. The cashier clicks the total price to print after selecting the order drugs.
11. Then the system will display response.
12. End of use case.
Post condition 1. Return to their appropriate page.
2. Close the system

32
 4.2. Object Model

4.2.1. Class Diagram

Class diagrams in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among the classes.

A class represent a concept which encapsulates state (attributes) and behaviour

(operations). Each attribute has a type. Each operation has a signature. The class name is
the only mandatory information.

Class Name:

 The name of the class appears in the first partition.

Class Attributes:

 Attributes are shown in the second partition.

 The attribute type is shown after the colon.

 Attributes map onto member variables (data members) in code.

Class Operations (Methods):

 Operations are shown in the third partition. They are services the class provides.

 The return type of a method is shown after the colon at the end of the method
signature.

 The return type of method parameters is shown after the colon following the
parameter name. Operations map onto class methods in code

The class diagram with its corresponding objects will be present in the following diagram

33
Figure 4-2: Class Diagram

34
 4.2.2. Data Dictionary

Table 4-10: Data Dictionary

Attribute Description Required?

F_ Name To store first name of user 

M_ Name To store Middle name of user 

L_ Name To store Last name of user 

sex To store the gender of the user 

Age Stores the ages of the users (patients age in 

prescription)

Phone To store the phone number of the user 

password Store a unique code to identify the user that have the 
access to the system (for log in)

U_name Store a unique email or username to identify the 

user that have the access to the system (for log in)

user_id To uniquely identify a user of the system 

Doc_id Uniquely identifies each doctor which sent the 

prescription

Doctor’s name Stores the name of doctors 

Drug_name To store drugs name to be identified by their name 

Patients_name To store patients name (in the prescription) 

35
quantity To store a number of drugs purchased/soled 

unit price Stores price of each soled / purchased drugs 

Total_price To store the total price of the soled or purchased 

drugs

shelf_number To store the location (shelf number) of the drugs 

expired_date Stores the expired date of the drugs 

Reporter_ID Which uses to identify the report of each user using 

their ID

Date Stores the date of drugs soled/purchased, 

prescription written and sent

batch number Stores the drugs company made id (batch number) 

Access_type Stores access type of the user (login as….) 

Bill _No Uniquely identifies each bill which is prepared for a 

patient

Company_name Set to identify from where the drugs are purchased 

for the pharmacy

4.3. Dynamic Model

4.3.1. Sequence Diagram

A sequence diagram in a unified modeling language (UML) is a kind of interaction diagram

that shows how processes operate with one another and in what order. It is a construct of a

36
Message Sequence Chart. A sequence diagram shows object interactions arranged in time
sequence. [5]

Figure 4-3: Sequence diagram for login

37
Figure 4-4: Sequence diagram for register drug

38
Figure 4-5: Sequence diagram for delete expired drugs

39
Figure 4-6: Sequence diagram for register user

40
Figure 4-7: Sequence diagram for delete employee

41
Figure 4-8: Sequence diagram for send prescription

42
Figure 4-9: Sequence diagram for sell drugs

43
Figure 4-10: Sequence diagram for bill print

44
 4.3.2. Activity Diagram

An activity diagram is similar to a flowchart to represent the flow from one activity to
another activity. Activity diagrams and State chart diagrams are related. While a state chart
diagram focuses attention on an object undergoing a process (or on a process as an object), an
activity diagram focuses on the flow of activities involved in a single process. [6] The
Activity diagram shows how these single-process activities depend on one another.

Figure 4-11: Activity diagram for login

45
Figure 4-12: Activity diagram for register drug

46
Figure 4-13: Activity diagram for delete expired drugs

47
Figure 4-14: Activity diagram for register employee

48
Figure 4-15: Activity diagram for delete employee

49
Figure 4-16: Activity diagram for send prescription

50
 4.3.3. State Chart Diagram

A state chart diagram is a view of a state machine that models the changing behavior of a
state. State chart diagrams show the various states that an object goes through, as well as the
events that cause a transition from one state to another. [7]The common model elements that
state chart diagrams contain are: States, Start and end state, Transitions.

Figure 4-17: State chart diagram for login

51
Figure 4-18: State chart diagram for register drug

Figure 4-19: State chart diagram for delete drug

52
Figure 4-20: State chart diagram for register employee/user

Figure 4-21: State chart diagram for delete employee/user

53
Figure 4-22: State chart diagram for send prescription

Figure 4-23: State chart diagram for bill print

54
Figure 4-24: State chart diagram for sell drug

55
 CHAPTER FIVE

5. SYSTEM DESIGN

Systems design is the transformation of the analysis model into a system design model. This
chapter mainly concerned with the design part of the pharmacy management system. The
purpose of this chapter is to provide an overview as to how to actually build the proposed
system and to obtain the information needed to derive the actual implementation of our
system. In addition to these systems design makes the implementation easy the design is very
important. In this section we will see different types of system modeling techniques that will
be used for the implementation of the system such as component modeling, deployment
diagram, data base design and class mapping.

5.1. Design Goals

Design goal inferred from the non-functional requirements of the system and the objectives
of the design goal are to model a system with high quality. Others will have to be elicited
from the client. In general, this identifies the following goals: response time, efficiency, cost,
maintenance, and reliability, security, availability and end user criteria.

Response time: As this mentioned the performance characteristics in the non-functional

requirement of the requirement analysis document, the system should respond the user
requests within a specified period of time and up to the standard response time after the
request has been issued.

 Low cost: - the pharmacy management system should be developed with minimum
cost possible.

 Maintenance: - The system should be easily extensible to modify the property

administration system organization criteria, add new functionality, portable to
different platforms. The code for the system should be easily readable, understandable
and should be easily mapped to Specific requirements.

 Reliability: The information provided by the system to the users will be fetched from
the database. To make the system reliable to the users as well as to the staffs making
56
 sure information stored on the database is correct is a main task. To make sure this is
achieved client side and server-side form validation will be applied to every input data
against pattern errors, invalid data.

 Security: As mentioned in the requirement analysis document user can log into the
system with authorized password and username.

 Availability: since the system is an online and it will be accessible 24 hours unless
some problems happened like connection failure, power failure or others.

 End User Criteria: - The system should have simple and understandable graphical
user Interface such as forms and buttons, which have descriptive names. It should
give reliable response for each user request at least before the session expires. All the
interfaces, forms and buttons are written or designed in a simple language or common
language so that the user can access it without any difficult.

5.2. Proposed System Architecture

The system architecture defines how pieces of the application interact with each other, and
what functionality each piece is responsible for performing. There are three main classes of
application architecture. They can be characterized by the number of layers between the user
and the data. The three types of application architecture are single-tier (or monolithic), two-
tier, and n-tier, where n can be three or more. In a three-tier or a multi-tier architecture has
client, server and database. Where the client request is sent to the server and the server in turn
sends the request to the database. The database sends back the information/data required to
the server which in turn sends it to the client. So, our system has three tier architecture
representations.

57
 Figure 5-1: System Architecture (Layered Architecture of the System)

5.2.1. Subsystem Decomposition and Description

Decomposition refers to the process by which a complex problem or system is broken down
into parts that are easier to conceive, understand, program, and maintain. It results large
systems in to a set of loosely dependent parts which make up the system.

To reduce the complexity of the solution domain, we decompose a system into simpler parts,
called subsystems, which are made of a number of solution domain classes. From the
functional requirements the proposed system could consists of the following subsystems:

 Register Subsystems:
o Register drug
o Register employee

 Manage account subsystem:

o Create account
o Delete account
o Update account
o Change Password

58
 Deleting subsystem:
o Delete drug
o Delete employee

 Selling drugs subsystem

o Check the availability of the drug
o Print the soled drug

 Report generation subsystem

o Write report
o View report
o Generation of bill report

 Prescription management subsystem

o Send prescription
o Receive/View prescription

Figure 5-2: System decomposition diagram

59
 5.2.2. Hardware/Software Mapping

The functionalities and services will be accessed through the AU PMS LAN, which is
necessary to specify the nodes and the communication between these nodes of the system.
The web server can run on any computer that support PHP and its database can run on any
computer that supports MYSQL.

The system will be functional on windows Operating System. The programming languages
that we are going to use for developing the system are: PHP, Scripting language such as
Hyper Text Markup Language (HTML), Cascading Style Sheet (CSS), and JavaScript (JS).
For the database management system and web server will run on XAMPP Server.

The diagram below depicts the hardware/software mapping of pharmacy management system
for Arsi University.

Figure 5-3: Hardware and software mapping

60
5.2.3. Detailed Class Diagram

Figure 5-4: Detailed class diagram

61
 Table 5-1: Class diagram descriptions

Class name Attribute and Data type Length Operation

F_ Name: varchar(20)
M_ Name: varchar(20)
L_ Name: varchar(20)
Manage user account
Manager_id: varchar(20) (Create, Delete, and Update
Manager sex: char(6) user account) and view all
Phone : varchar(20) reports

U_name: varchar(25)
password: varchar(20)

F_ Name: varchar(20)
M_ Name: varchar(20)
L_ Name: varchar(20)
Manages the drug
pharma_id: varchar(20)
information in the stock
Pharmacist sex: char(6)
(receive prescription and sell
Phone : varchar(20) drugs).
U_name: varchar(25)
password: varchar(20)

F_ Name: varchar(20)
M_ Name: varchar(20)
L_ Name: varchar(20)
Manages the outgoing and
ST_id: varchar(20) incoming drug from the store
Store Coordinator sex: char(6) (register, delete expired
Phone : varchar(20) drugs) and report to the

U_name: varchar(25) manager.

password: varchar(20)

62
 F_ Name: varchar(20)
M_ Name: varchar(20)
L_ Name: varchar(20)
Collect the price of the sold
Cashier_id: varchar(20) items and generate report to
Cashier sex: char(6) the manager.
Phone : varchar(20)
U_name: varchar(25)
password: varchar(20)

F_ Name: varchar(20)
M_ Name: varchar(20)
L_ Name: varchar(20)
Doc_id: varchar(20)
Send prescription to the
Doctor sex: char(6)
pharmacist
Phone : varchar(20)
U_name: varchar(25)
password: varchar(20)

5.2.4. Access Control and Security

Access control is way of limiting access to a system or to physical or virtual resources. In

computing, access control is a process by which users are granted access and certain
privileges to systems, resources or information. In access control systems, users must present
credentials before they can be granted access. In physical systems, these credentials may
come in many forms, but credentials that can't be transferred provide the most security.

63
 Table 5-2: Access Control and Security

Operations Manager Pharmacist Store Cashier Doctor

coordinator

Create user account 

Delete user account 

Update user information 

Register drugs 

Delete expired drugs 

Update drug information 

Print bill 

Sell drug

Report generation   

View report 

Send prescription 

View prescription 

View available drugs   

64
 5.3. User Interface Design

User interface is the external part of the system which is used to access and interact with the
system easily. User interface design focuses on the user's experience and interaction. Our
goal in user interface design is to make the user's interaction as simple and efficient as
possible, in terms of accomplishing user goals. The user interface design should be also
flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and
redoing, while also preventing errors wherever possible by tolerating varied inputs and
sequences and by interpreting all reasonable actions. Graphical user interface design is
utilized to support its usability by allowing users to interact with the new system through
graphical icons and visual indicators.

Figure 5-5: User interface work flow

65
REFERENCES

[1] "Steelkiwi," Steelkiwi Inc, [Online]. Available: https://steelkiwi.com/blog/how-to-develop-a-

pharmacy-management-system/. [Accessed 10 March 2022].

[2] "Wikipedia," [Online]. Available: https://en.wikipedia.org/wiki/Feasibility_study. [Accessed 10

March 2022].

[3] "tutorials point," [Online]. Available:

https://www.tutorialspoint.com/sdlc/sdlc_iterative_model.htm. [Accessed 10 March 2022].

[4] "Lucid," [Online]. Available: https://www.lucidchart.com/pages/uml-use-case-diagram. [Accessed

10 March 2022].

[5] "Wikipedia," [Online]. Available: https://en.wikipedia.org/wiki/Sequence_diagram. [Accessed 10

March 2022].

[6] "Wikipedia," [Online]. Available: https://www.smartdraw.com/activity-diagram/. [Accessed 10

March 2022].

[7] "tutorialspoint," [Online]. Available:

https://www.tutorialspoint.com/uml/uml_statechart_diagram.htm. [Accessed 10 March 2022].

66