Web Based GMBU Clinical Management System

Software requirement specification

Version 1.0

Prepared By:
Name ID
Azemaeraw RNSc/id/2013
Bontu RNSc/id/2013
Deborah RNSc/id/2013
Demeke RNSc/id/2013
Diriba RNSc/id/2013
Jemila Gena RNSc/id/2013
Saleamlak msganaw RNSc/0589/2013
February 12, 2023
Table of content

Table of content
List of figures
List of tables
Abstract

Chapter 1: Introduction
1.1 Introduction ------------------------------------------------------------------- 3
1.2 Problem Statement ------------------------------------------------------------------- 4
1.3 Objectives ------------------------------------------------------------------- 5
1.4 Scope ------------------------------------------------------------------- 6
1.5 Project Schedule ------------------------------------------------------------------- 7
1.6 Glossary -------------------------------------------------------------------- 7
1.7 Overview -------------------------------------------------------------------- 7
Chapter 2: Overall description
2.1 Introduction ------------------------------------------------------------------- 8
2.2 Product perspective ------------------------------------------------------------------- 8
2.3 Product function ------------------------------------------------------------------- 9
2.4 User characteristic ------------------------------------------------------------------ 11
2.5 Operation environment ------------------------------------------------------------------ 12
2.6 Design and implementation constraint ----------------------------------------------- 12
Chapter 3: System Analysis
3.1 Functional requirement --------------------------------------------------------- 12
3.2 Non-functional requirement --------------------------------------------------------- 16
3.3 software requirement --------------------------------------------------------- 16
Chapter 4: system design
4.1 system environment --------------------------------------------------------- 19
4.2 use cases -------------------------------------------------------- 20
4.2.1 Admin use cases --------------------------------------------------------- 20
4.2.2 Doctor use cases --------------------------------------------------------- 23
4.2.3 Nurse use cases --------------------------------------------------------- 24
4.2.4 Pharmacist use cases --------------------------------------------------------- 26
4.3 use case scenarios ---------------------------------------------------------- 28
4.4 sequence diagrams ---------------------------------------------------------- 37
4.5 Activity diagrams ---------------------------------------------------------- 44
4.6 E-R diagrams ---------------------------------------------------------- 47
4.7 deployment diagrams ---------------------------------------------------------- 47
Conclusion ------------------------------------------------------------------------------------------ 48
References ------------------------------------------------------------------------------------------ 49

2|Page
 LIST OF FIGURES
Figure 2.1 Features of GMBU CMS ----------------------------------------- 20
Figure 4.1 System environment ----------------------------------------- 21
Figure 4.2 Admin use cases ----------------------------------------- 24
Figure 4.3 Doctor Use cases ----------------------------------------- 26
Figure 4.4 Nurse Use cases ---------------------------------------- 28
Figure 4.5 Pharmacy use cases ---------------------------------------- 39
Figure 4.6 System sequence diagram ---------------------------------------- 40
Figure 4.7 Login Sequence diagram ---------------------------------------- 41
Figure 4.8 Register Student sequence diagram ---------------------------------------- 42
Figure 4.9 delete user sequence diagram ---------------------------------------- 43
Figure 4.10 search user sequence diagram ---------------------------------------- 44
Figure 4.11 update user sequence diagram ---------------------------------------- 45
Figure 4.12 Login Activity diagram ---------------------------------------- 46
Figure 4.13 get debt Activity diagram ---------------------------------------- 47
Figure 4.14 Instant message Activity diagram ---------------------------------------- 48
Figure 4.15 E-R diagram --------------------------------------- 48
Figure 4.16 CMS deployment diagram --------------------------------------- 49

LIST OF TABLES
Table 1.1 project time schedule -------------------------------------- 8
Table 1.2 glossary -------------------------------------- 8
Table 4.1 login scenario -------------------------------------- 30
Table 4.2 student registration scenario -------------------------------------- 31
Table 4.3 register user scenario -------------------------------------- 32
Table 4.4 register drug scenario ------------------------------------- 33
Table 4.5 update student scenario ------------------------------------- 34
Table 4.7 update user scenario ------------------------------------- 35
Table 4.8 update drug scenario ------------------------------------- 36
Table 4.9 delete user scenario ------------------------------------- 38

3|Page
Abstract:

Clinical management system (CMS) is a user support system which is developed to assist clinical
staffs (doctors, nurses, pharmacist, and clinical managers) in patient, drug, and clinical staffs
record management. CMS reduce the burden of clinical staff and change the manual (paper-
based) system to computerized system, CMS also provide an efficient and systematic
management environment within the clinic. In order to provide this functionalities there are five
main modules that need to be developed in CMS. The methodology used for developing CMS is
system development life cycle (SDLC). This system is written in python 3.SQLite was utilized as
the database for the system. Python development server used as web server. This thesis will
explains background study, methodology, system analysis, system design, system development
and implementation.

Introduction
The purpose of this document is to present a detailed description of software system by which
clinical management system of gambella university clinic will be built. It will explain the
purpose, feature and interface of the system as well as what the system will do and how it should
interact with user of the system. This document is mainly intended for the developers of the
systems. By inspecting this document painstakingly, they can develop user friendly, easy to use
clinical management system for gambella university clinic. Since the system created from this
document is also for GMBU clinical staffs (doctors, nurses, pharmacist, and clinical manager)
and Finance officers. These are just the user of the system, and can see this document to verify
whether the document include the functionalities that they needs..

Currently, GMBU clinic use manual (paper-based) system and store patient, drugs, and clinical
staff’s records on paper. For example, the clinic use cards to write down student’s medical
information such as last date visit, drug prescription, and laboratory results. Then those medical
cards are placed in shelf which is partitioned by department. And each department is categorized
by year. And each year contains students’ medical card organized by students’ name sorted
alphabetically. This work is troublesome and plaguing. Moreover the student medical
information is not secure.

The proposed system attempt to solve students’ medical information management and reduce the
burden of nurse and doctors. It is used as central repository of information that can be updated
and accessed electronically within a clinic, allowing sharing of vital student’s medical
information between nurse and doctors with security password access. These medical
information has familiar resemblance to traditional paper record that currently seen in GMBU
clinic. The main aim of this proposed system is to computerize the manual paper-based system.

4|Page
As conclusion, the proposed system will bring benefits to doctors, nurses, pharmacist, clinical
managers, students, and finance officers. Its aims is to assist users in achieving their respective
goals and objectives.

1.2 Problem Statement

The paper-based system, which currently used in GMBU clinic, cause many problems to the
user. When the student first visit to the clinic, the nurse is required to fill in a new medical card
for the student. This include some private information that can be obtain from the student’s
identity card such as name, identity card number, department, gender … and then the nurse will
pass this medical card to the doctor. After the student sees the doctor, some diagnosis and
treatment information will be written down on the medical card by the doctor. After student
getting their medicine, the nurse will keep that medical card on an organized rack based on
department as index of the card. These medical cards are grouped according to department and
year. Meaning that medical cards with the same department and year packed in single document
case and placed inside a cabinet. Plus the medical cards are arranged in alphabetical order
according to the student’s name. The nurse needs to search through the department, then year for
the medical card that match the student’s name for any subsequent visit of the student. Doing this
manually is tedious, error prone and plaguing. In addition after the doctor prescribe a drug, the
student would go to the pharmacy and receive the drug. When the student ask the pharmacist for
what purpose the drug is for, it is not uncommon to see pharmacist’s confused face which
indicate lack of knowledge about all medicines. What is more, during cost share calculations, the
students those who get service from clinic pay the same amount of money for health with the
students those who do not get any kind of service from the clinic. This is also not fair.

To summarize the following are the problems, which are observed in gambella university clinic,
lead us to create a system.
 Lack of security

The medical card is easily exposed to unauthorized user. They can easily get the vital
students’ medical information from the clinic because the medical card are just kept on
the shelf without any security lock.
 Time consuming
By using medical cards, times are wasted when the medical card need to pass from the
nurse to doctor. Besides that, the clinic also needs to speed times to organize the medical
cards from time to time. For example, when third year student become fourth year
student, there are some information need to be updated. Which also takes time.

5|Page
  Space

Clinic needs to provide space to store these medical cards. When the quantity of cards
increases every year, they need more and more space to store the cards. This is very
burning issue for gambella university clinic because currently the university expands its
student intakes capacity. Plus gambella is lowland area and malaria is common disease in
lowland. As a result many students are infected with malaria and the clinic need more
space to store medical card of those student.
 Redundant information

Sometimes, a student can have more than one medical card. This happen when the
medical card is misplaced and people who do the registration did not check properly and
just directly use a new medical card.
 Lack of knowledge

Sometimes, the pharmacist may not have enough information about all the medicine that
is in the store. This happened because there are ton of medicine out there and knowing all
the information about all medicine is humanely impossible.
 Over Cost share
In GMBU, this happened because the student those who get service from clinic and the
student those who do not get service from the clinic pay the same amount of money for
health. And this is over cost share for those who does not get service from the clinic.

1.3 Objectives
1.3.1 General objective
The main aim of this proposed system is to computerize the manual (paper-based)
system of gambella university clinic and enhance clinical management process in
advance.

1.3.2 Specific objectives

i. To assist nurses and doctors in student record management
ii. To assist pharmacist in drug record management
iii. To assist the manager in clinical staffs record management
iv. To tracing doctor’s diagnosis and treatments

v. Assisting nurses , doctors, pharmacist, and manager in digital

communication

6|Page
1.4 Scope
The proposed system is to be used in gambella university clinic. The target users of the system
are doctors, nurses, pharmacist, and manager of the clinic and finance officers. This project is
mainly emphasized on developing a system for storing electronic student medical, drug, and
clinical staffs’ records. And the target users have access to one or more of those records in their
own workspace. It also include some other functions that can help the target users to improve
their performance. In order to achieve this goal, this proposed system can be divided into five
module. Such as:
i. Registration module
ii. Nurse module
iii. pharmacy module
iv. Admin module
v. Finance office module
vi. Doctor module
The first module is registration module. This is where every registration is takes place. Students,
clinical staffs’ and drug can be registered to the database using this modules. All other module
can use the functionality of this module but not finance module.

The second module is nurse module. This is where the nurses add and delete student’s data,
search for registered students as well as passing student’s digital medical card to the doctor.

The third module is pharmacy module. This is where the pharmacy manage drugs, register drugs,
search drugs and see details information about drugs

The fourth module is administration module. This module help the manager to manage the
employee, of the clinic. This is where new clinic’s employee get registered, updated and deleted
(if necessary). Plus this module provide the manager database interfaces. So the manager can
easily manage the database.

The fifth module is finance office module. This module help finance officer to get students’ debt
from the clinic during cost share calculation.

The six module is doctor module. This is where the doctor describe disease, prescribe drug and
view laboratory results.

7|Page
1.5 Project schedule

No Tasks Duration

1 Project scheduling 3 days

2 Review existing system 10 days

3 Project Analysis and design 30 days

4 implementation 5 days

Table 1.5 project time schedule

1.6 Glossary:

Term definition

database The collection of information through table

CMS Clinical management system

GMBU Gambella University

CRUD Create, read, update and delete database basic operations

CID Clinical identification card

interface Any clickable button

interact Pressing the interface

Student Those who are infected with disease; patient

User doctor, nurse, pharmacist, clinical manager and finance officer

UID User identification card

Table 1.6 glossary

1.7 Overview:

8|Page
To give the readers a better understanding about this document, a general description of each
chapter is given as below.

Chapter 1 consist of an overview of project. This chapter include introduction of the proposed
project, problem statement of the existing paper-based system, objective of the project, scope,
project plan and schedule and overview of SRS document.

Chapter 2 consist of overall description of product. This chapter include system environment,
product perspective, product function, user characteristic, operating environment and design and
implementation constrains.

Chapter 3 consist of specific requirement of product. This chapter include functional

requirement, Non-functional requirement and software requirements

Chapter 4 consist of different design aspect of the products. This include use case diagrams and
use case scenarios, sequence diagram of some use cases, activity diagram of some use cases and
system, deployment diagram of the system and E-R diagram.

Chapter 2 Overall Description

This section gives background information about specific requirements of the web based clinical
management system to be developed in brief. Although we will not describe every requirement
in detail, this section will describe the factors that affect the final product.

2.1 product perspective

This software product is only intended for the GMBU clinical staff’s. The product will be
deployed to website and all users of the product will access by use of the website which will be
main user interface where users can operate all the provided functionality. Since it is dependent
system it should be hosted as part of large system.

This product consist of five main workspace such as nurse, doctor, pharmacist, clinical manager
and finance officer workspace. Each workspace contain different content and functionalities.

Nurse workspace is workspace for nurses. So nurses can visit this workspace and the workspace
provide the student registration, search student, and update student’s data and passing medical
card functionalities. Because it is user friendly, the nurse can easily interact with the interface.

Doctor workspace is also the workspace for doctor. It is provide an interface for searching user,
disease description and drug prescription. Plus this workspace includes functionality of viewing
student medical history and viewing laboratory results. In addiction every doctors’ activity such
as the prescribed drug, the stated disease as well as result of laboratory attached to particular
student and synced to the database and stored as student’s medical history. When a particular
student visit the clinic for the second time, the doctor can observe the medical history of that user
(if necessary). Which helps the doctor on their operations. Also the doctor pass any drug
prescription to pharmacist during working on this workspace.

9|Page
Pharmacist workspace is platform of pharmacists. It provides drug registration, searching drug
and updating drugs data interfaces. So the pharmacist can easily register a particular drug when it
is available. Once the drug is registered the pharmacist can also search for particular drug in
order to check whether the drug is in the store or not. If the pharmacist modify particular drug
data, this workspace help them to do that. So when drug prescription reach the pharmacist the,
search for particular for particular student and see the prescribed drug there. Then they can
search that particular drug by just coping and pasting. If the drug exist, the pharmacist can see
any detail information about the drug and pass the drug to the requested student. If it does not
exist, the pharmacist can communicate to the doctor digitally and let the doctor know about the
issue. This is what this workspace is for. Clinical manager workspace is the admin workspace. It
provides many functionalities including managing database and users of the CMS. Inside this
workspace the admin can manage user by creating account for new user, searching users and see
detail information about them, deleting particular user (if necessary). Users in this document is
includes only doctors, nurses, pharmacist, and finance office as well as clinical manager. Also
these are the user of CMS system. If they don’t have an account, the user can’t use this system.
As a result of that clinical manager mange the user this applications (such as registering user as
doctor or nurse …) besides managing database and controlling the system.

The last workspace is finance office workspace, this is where the finance officer get the amount
of money that the student borrowed from the clinic for health. All this user works on the same
database

. To use this product, users are required to register via administrator. Whenever a new user
registered, all the required data will be created in the database and a predefined workspace will
be assigned for the user. The admin has register nurses as nurse, doctor as doctors, pharmacist as
pharmacist, admin as admin. If they are not registered as this way, it is impossible to use the
system because the user will fail at passing the login page.

Generally this product require user to have an account and login to the system using their
account. As soon as they login, product will automatically redirect each user to their respective
workspace which includes user specific features and functionalities. The top level diagram below
shows all of the user features that will be implemented for the system.

2.2 product Function (features)

This new product, web based clinical management system, must have number of features which
will allow users to use functionalities which have been explained above. The main function of
this product is to computerize the paper-based clinical management system of Gambella
University. This product have the following major features:
 The product has a login interface as a result only authorized user of the system can
Manipulate records.

10 | P a g e
  Each user of the system have home page which used as workspace for them.

 Instant message help users of the system to communicate with each other

 Student may not have money but every time they visit the clinic and get service, a fair
amount of money is added to their account for the services. Because it will be required by
finance office during cost share calculation.

Figure 2. 1 features of GMBU CMS

 Administrator:
 login to the system
 Register (add) new user to the system
 modify the profile of registered user
 delete particular user if necessary
 manage databases
 view detail information of registered user

11 | P a g e
  show user data in table form

Nurse:
 check if particular student is registered or not
 add new student to the system
 modify each student’s data
 Doctor:
 State the disease
 View laboratory result
 Add appropriate fee to particular student for the service
 Prescribe drugs
 Pharmacist:
 Register drugs when new drug is available
 View detail information about drugs and modify if necessary
 Checking whether a particular drug is available or not
 Finance officer:
Get clinical debt of particular student

2.5 User Characteristic

There are two type of users in this product; the admin user and normal user. The admin user is
clinical manager and the rest are normal users.
Clinical manager: it is the one who control the system and have access to all features of the
product. It has a so-called administrative privileges and he has to be expert at database
management and should have knowledge on web programming and web protocols like https.
At least he/she should be computer science or any related field graduates.

Normal user: normal user have limited privileges to the system. This user should have basic
computer knowledge as well as how to browse internet
2.6 Operating Environment
System requirements – Hardware

12 | P a g e
  Platform: at least Microsoft server 2019
 CPU: at least Dual core 3.6 MHz
 Space: Minimum of 2 GB
 RAM: Minimum of 4 GB
System Requirements – software
 Web Services: apache server
 Other services: xamp server, python development server
User Requirements – hardware
Platform: window 10, window 8, window 7
CPU: at least 500 MHz
RAM: at least 512 MB
Peripherals: keyboard, mouse
User Requirements – software
Browser: Mozilla’s Firefox, Google chrome, Microsoft edge.

2.6 Design and Implementation Constraints

Developers of the product should be aware that main feature of the intended product is
portability. So they should use common libraries and tools that can work with all the common
internet browser application with no problem.

Chapter 3 system analysis

3.1 Functional Requirement
This product have the following functional requirements
Login operation [Taking User Name; password]
Instant message
Front end requirement
3.1.1 Manage student
3.1.1.1 Student Registration
3.1.1.1.1 Taking Student first name (Mandatory)
3.1.1.1.2 Taking Student last name (Mandatory)

13 | P a g e
 3.1.1.1.3 Taking Student Identification number (Mandatory)
3.1.1.1.4 Selecting Student Department (Mandatory)
3.1.1.1.5 Select Department Year (Mandatory)
3.1.1.1.6 Selecting Student Age (Mandatory)
3.1.1.1.7 Selecting Student Sex (Mandatory)
3.1.1.1.8 Submitting the Form
3.1.1.1.9 Resetting the form
3.1.1.2 Search Student
3.1.1.2.1 Taking student identification number
3.1.1.2.1 Submission to search
3.1.1.3 Update student’s data
Go through list of user, select particular user
Able to see detail information
Selecting update user
Able to update user data in the separate screen
1. Update Student first name
2. Update Student last name
3. update Student Identification number
4. Selecting Student Department
5. Select Year
6. Selecting Student Age
7. Selecting Student Sex
8. Submitting the Form
9. Resetting the form
3.1.2 User Login
3.1.2.1 Taking user name
3.1.2.2 Taking password

14 | P a g e
 3.1.2.3 Submission of the Login
3.1.3 Manage Drug
3.1.3.1 Add Drug
3.1.3.1.1 Taking drug name
3.1.3.1.2 Taking drug expire date
3.1.3.1.3 Taking drug production date
3.1.3.1.4 Taking what it treat
3.1.3.1.5 Selecting production country
3.1.3.1.6 Selecting manufacturer
3.1.3.1.7 Selecting drug weight
3.1.3.1.8 Selecting side effects
3.1.3.1.9 Taking description
3.1.3.1.10 taking procedures
3.1.4.1.5 Submitting the form
3.1.4.2 Search Drug
3.1.4.1.1 Select Drug Name
3.1.4.1.2 Submission to Search
3.1.4.3 View drug details
3.1.4.4 Update drug
3.1.4 Get Student Debt
3.1.5 Instant message
3.1.6 Add payment
Back end (Administrative tools) requirement
1.1 Admin home page – All features availability
1.2 Manage users
1.2.1 Adding new user
1.2.1.1 Taking Login Name (Mandatory)

15 | P a g e
 1.2.1.2 Taking login Password (Mandatory)
1.2.1.3 Taking confirm Password (Mandatory)
1.2.1.4 Taking first name (Mandatory)
1.2.1.5 Taking last name (Mandatory)
1.2.1.6 Taking e-mail in the e-mail format
1.2.1.7 Taking phone number (Mandatory)
1.2.1.8 Selecting user type (Mandatory)
1.2.1.8 Submitting the form
1.2.1.9 Resetting the form
1.2.2 Updating user
Go through lists, selecting a particular user.
Able to view detail information
Selecting update user
Able to update user data in the separate screen
1.2.3.1 Update Login Name (Provided previous login name)
1.2.2.2 Update login Password (Provide previous login password)
1.2.2.4 Update first name (Provide previous first name)
1.2.2.5 Update last name (Provide previous last name)
1.2.2.6 Update e-mail in the e-mail format (provided previous email-none)
1.2.2.7 Update phone number (provided previous phone number)
1.2.2.8 Update user type (provided previous value)
1.2.2.8 Submitting the form
1.2.2.9 Resetting the form
1.2.3 Search User
1.2.3.1 Select user name/user_id
1.2.3.2 Submission to search
1.2.4 Delete User

16 | P a g e
 Go through list of user, selecting a particular user.
Able to view detail information
Remove user
1.2.5 View User Activity
Go thought list of user, select particular user
Able to view detail information
View history
1.2.6 Table of user data
1.3 manage databases
1.4 Instant message

3.2 Non-functional Requirement


Operating System:
The software will be run on all operating system
 Usability:
Usability of software will be easy. So the users can use it without any difficulty
 Maintainability:
Software would be build up in such away that classifications of error and
maintenance of mechanism become easy
 Flexibility:
Software would be flexible so that it can easily accept all changes at low cost,
time and experience.
 Security:
Software will be secure. No one can use this application without
Username and password
 Access:
Software will be accessible over the internet
3.3 software requirements

3.3 Framework, Language, and Tools

The language and tools that have been used to develop this project are as follows. We used
Django as a framework, python, HTML, MySQL, Cascading Style Sheets (CSS), JavaScript as
an implementing language.

17 | P a g e
3.3.1 Django

Django is python framework that makes it easier to create web sites using python. It takes care of
the difficult stuff. So that you can concentrate on building your web application. The main
reason we select Django is that it follows MVT design pattern (Model View Template).

Model – the data we want to present, usually data from database

View – a request handler that returns the relevant template and content-based on the request from
user. Template – a text file containing the layout of the web page, with logic on how to display
the data.

3.3.2 PYTHON
Python is a popular programming language. It was created by Guido van Rossum, and released
in 1991. It is an easy to learn, powerful programming language. It has efficient high-level data
structures and a simple but effective approach to object-oriented programming. Python’s elegant
syntax and dynamic typing, together with its interpreted nature, make it an ideal language for
scripting and rapid application development in many areas on most platforms

It is used for:

 web development (server-side),

 software development,
 mathematics,
 System scripting.
3.3.4 HTML
HTML stands for Hyper Text Markup Language. HTML is a language for defining the building
of Web pages. HTML grants authors the means to,

 Distribute online documents with tables, lists, photos, titles, topic, etc.
 Improve online data via hypertext links, at the click of a button.
 Design schemes for operating activities with foreign services, for use in exploring for data,
presenting licenses, ordering products, etc.
 Include covers-sheets, video clips, sound clips, and other applications immediately in their
reports.

18 | P a g e
3.3.5 CSS
CSS is the language for describing the performance of Web pages, including appearances, layout
design, and fonts. It enables one to adjust the presentation to various types of devices, such as big
screens, small screens, or printers. CSS is confident of HTML and can be used with any XML-
based markup language. The division of HTML from CSS performs it more comfortable to
establish sites, receive style sheets pages, and original pages to different conditions. That is
committed to as the division of construction from a presentation

3.3.6 JavaScript
JavaScript is the world’s most successful web-based programming language. It is the language
for HTML, for the web, for servers, PCs, laptops, tablets, phones, and more. JavaScript is a
Scripting Language.
 JavaScript is programming code that can be implanted into HTML pages.
 All modern web browsers can perform JavaScript code.
 JavaScript is clear to learn

3.3.7 Tools
A software development tool is a program or applications that Software Developers use to
design, debug, maintain, or otherwise maintain other programs and applications. The term
applies typically to nearly simple programs, which can be connected coincidentally to perform a
task, much as one might use multiple control tools fix a physical object
To improve this website utilizing the following tools:

 Pycharm community text editors: for writing the program

 Notepad++
 MySQL Workbench
 Xampp Server: for hosting web application
 Browser
 Wonder share edraw max : for drawing diagrams
 Microsoft office word 2013, Liber Office writer: to write this SRS document
 Window 10 photo applications: to edit drawn diagram of edraw max
 Window 10 screen shot application: to take screenshot
3.4 Database
A database is an arranged group of data. The data are typically prepared to design essential
characters of reality in a way that maintains means demanding this information. The resulting
database is working to improve this website is MySQL.
Database is a must for our Project. All the experience will be stored in that database. For our
application, the database is a significant aspect. The database needs to be stable and secure
because security is a significant problem for a web application. So to select a database is

19 | P a g e
essential and more important than any other things for our project. We like MySQL because it is
the most suitable database for us for some reasons. Those reasons will be given below.
A MySQL database is a hosting database that is used to store students, drug, and clinical staffs.
A MySQL database is the usual general type of relational database on the web today. That is
partly because it is free but also very important. In basic terms, a MySQL database is intelligent
about saving any data that you want. It will let you quickly store and retrieve information
MySQL is a database server.
 It is ideal for both small and large application.
 MySQL Supports standard SQL.
 It is free to download and use.
 It compiles on some platforms.
These are the purposes we used MySQL as our database because it is so important to select the
right database for our application otherwise the whole hard work may go in vain. That’s why
considering all the options we’ve chosen this database, and it was so useful for our project as
well as the web application.
To build our web application, we needed a database server which is perfect for small and large
use. We needed a database that maintains standard SQL and also compiles some platforms. The
end and essential fact of the database is if it is free to download and practice or not.
Chapter 4 System design
System environment

Figure 4.1 System environment

20 | P a g e
4.2 Use Cases
This section outlines the use cases for each users. All users have more than one use cases

4.2.1 Admin use case

The clinical manager has the following sets of use cases:

Figure 4.2 Admin use cases

Use case: login

Brief description
The admin can login to the system as administrator
Initial Step-by-Step Description
Before this use case can be initiated, the system will provide a login page with username
and password
1. The admin will provide username and password
2. Then admin will interact with login button

21 | P a g e
 Xref: Section 4.2.2.
Use case: manage database
Brief description:
The admin manage the database that this system based on.
Initial Step-By-Step Description
Before this use case can be initiated, the admin has to login to the system as admin and
should have access to the admin home page.
1 System presents manage database button in action panel
2 The admin will click (choose) “manage database” button
3 The system present list of databases and “create database” button
4 The admin can see the tables in the give database and perform any CRUD operation
or he can create new database and table
Use case: Add user
Brief description
The admin can register (add) a new employee to the system.
Initial Step-by-Step Description
Before this use case can be initiated, the admin has to login to the system as
admin and should have access to the admin home page.
1. The system present “add user” button
2. The admin will interact with the button
3. The system will provide a submit form
4. The admin will fill all the required field and hit submit button
5. The system will tell the admin whether the operation is successful or not
Xref: Section 4.2.2.3
Use case: search user
Brief description:
The admin can search a particular registered user using UID.
Initial Step-By-Step Description
Before this use case can be initiated, the admin has to login to the system as admin
and should have access to the admin home page.

1) The system provide “search user here” text field and search button
2) The admin will provide user’s ID to text field and hit search button
3) The system will display all the information about the user, “delete user”,
“update user”, and “User activates” buttons.

Use case: update user

Brief description
The admin can user data if necessary
Initial Step-by-Step Description

22 | P a g e
 Before this use case initiated, the admin has to login to the system as admin and should
have access to the admin home page and click on particular user.
1) The system will provide a form with pre-filled fields and “save” button
2) the admin will replace the fields which are necessary to be updated and hit “save”
button
3) The system will let the admin know whether it is updated successfully or not.
Xref: Section 4.2.2.5

Use case: delete user

Brief description
The admin can delete a particular user if necessary
Initial Step-by-Step Description
Before this use case initiated, the admin has to login to the system as admin and
should have access to the admin home page and click on particular user need to be
deleted
1) The system will provide “delete user” button in action panel
2) The admin will click “delete user” button
3) The system will ask the admin “action cannot be undo, are you sure to delete?”
4) The admin will choose “yes” to delete or “no” to cancel the deletion.
Xref: section 4.2.2.9

4.2.2 Doctor Use case

The doctor have the following set of use cases:

23 | P a g e
 Figure 4.3 Doctor Use cases
Use case: login
Brief Description
The doctor can login to the system as doctor
Initial Step-by-Step Description
Before this use case can be initiated, the doctor should go to home page with
appropriate URL.
4.2.2.1The system provide to doctor a form which contain
Username and password field
4.2.2.2 The doctor will fill the form and interact with login button
Xref: Section 4.2.2.1
Use case: Search student
Brief Description
The doctor can search a student using their CID
Initial Step-by-Step Description
Before this use case can be initiated, the doctor should have access to
Doctor’s home page
1) The system will provide “search student here” text field and “search” button
2) The doctor will fill the text field with student CID and hit “search” button

24 | P a g e
 3) The system will display user as clickable list

Use case: show student medical history

Brief Description
The doctor view student’s medical history if necessary
Initial Step-by-Step Description
Before this use case can be initiated, the doctor should login to the system and have
access to the doctor’s home page as well as click a particular student.
1. The system will display basic student information (full name, age …) and
”medical history” button
2. The doctor will interact with “medical history” button
3. The system will provide him student past medical treatment (like diseases, drugs,
laboratory result) categorizing by month.

Use case: Drug prescription

Brief Description
The doctor can order drug for student
Initial Step-by-Step Description
Before this use case can be initiated, the doctor have to access to doctor’s home page
and click on a particular student among the list.
1. The system will provide “drug prescription” button
2. The doctor click on “drug prescription” button
3. the system will provide him a form
4. the doctor will fill the form and click “save” button
Use case: disease description
Brief Description
The doctor can order drug for student
Initial Step-by-Step Description
Before this use case can be initiated, the doctor have to access to doctor’s home
page and click on a particular student among the list.
1) The system will provide “disease description” button in diagnosis panel
2) The doctor click on “drug prescription” button
3) The system will provide him a form
4) The doctor will fill the form and click “save” button

4.2.3 Nurse Use Case

The nurse have the following use cases

25 | P a g e
 Figure 4.4 Nurse Use cases
Use case: login
Brief Description
The nurse can login to the system as nurse
Initial Step-by-Step Description
Before this use case can be initiated, the system should provide login page
1) The system provide a form which contain username and
password field
2) The nurse will fill the form and hit login button
Xref: section 4.2.2.1

26 | P a g e
 Use Case: Register Student
Brief Description
The nurse can register a new students and observe their information
Initial Step-by-Step Description
Before this use case can be initiated, the nurse have to access the nurse’s
home page
1. The system provide “register student” button in nurse panel
2. The nurse will click “register student” button
3. The system will redirect the nurse to registration page
4. The nurse will fill the form with the appropriate data and submit
the data to save
5. the system will tell the nurse whether it is registered successfully
or not
Xref: section 4.2.2.2
Use Case: Search student
Brief Description
The nurse can search a particular student using CID
Initial Step-by-Step Description
Before this use case can be initiated, the nurse have to access to the
nurse’s home page
1. The system will provide a text field and “search” button
2. The nurse will fill the student’s CID to text field and hit “search”
button
3. The system will display a user as clickable list.
Use case: Update student’s data
Brief Description
The nurse can modify student’s data if necessary
Initial Step-by-Step Description
Before this use case can be initiated, the nurse have to access to the nurse’s home page
and should search and click at particular student.
1) The system will provide “update user” button in action panel
2) The nurse will click “update user” button
3) The system will provide a form with pre-filled fields
4) The nurse will replace the pre-filled fields with new database
5) The nurse will hit “save” button
Xref: Section 4.2.2.5
4.2.4 Pharmacist Use case
The pharmacist have the following use cases

27 | P a g e
 Figure 4.5 Pharmacy use cases
Use case: login
Brief Description
The pharmacist login to the system as a pharmacist
Initial Step-by-Step Description
Before this use case can be initiated, the system should provide him a login page
1) The system provide to pharmacist a form which contain username
And password field
2) The pharmacist will fill the form and hit login button
Xref: section 4.2.2.1
Use case: add drug
Brief Description
The pharmacist will register drug when not registered drug is available
Initial Step-by-Step Description
Before this use case can be initiated, the pharmacist have to access the pharmacist
home page
1) The system provide “add drug” button in action panel
2) The pharmacist will hit “add drug” button
3) The system will redirect the pharmacist to drug registration page
4) The system will show form fields
5) The pharmacist will fill the form and hit register button

28 | P a g e
 6) The system let the pharmacist know whether or not the operation is
successfully.
Xref: Section 4.2.2.4
Use Case: Search drug
Brief Description
The pharmacist can search particular drug by using DID
Initial Step-by-Step Description
Before this use case can be initiated, the pharmacist have to access pharmacist
home page
1) The system will provide “search drug here” text field and “search” button
2) The pharmacists will providing DID for text field and hit “search” button
3) The system will show detail information about drug.
Xref: Section 4.2.2.8
Use Case: View drug detail
Brief Description
The pharmacist can see detail information about drug
Initial Step-by-Step Description
Before this use case can be initiated, the pharmacist have to access pharmacist
home page and search particular drug
1) The actor will click on searched drug
2) The system will show detail data about the drug such production data,
expiration date, drug’s name
3) The system will show detail information about drug.

4.2.2 Use case Scenarios

The following use case scenario show more detail use case interactions
Section 4.2.2.1
ID 01

Use Case Name login

Description Here using the use case the admin will login to the system

Actors Admin, doctor, nurse, pharmacist, finance office

pre-condition Visit the login page by putting the URL to the search bar of their
Browser.

Post condition The users should be redirected to their appropriate home pages.

29 | P a g e
 For example. Admin has to redirected to admin home page
doctors has to redirected to doctor’s home page
nurse has to redirected to nurse’s home page
pharmacist has to redirected to pharmacist’s home page
finance office has to redirected to finance home page

Basic flow 1. the actor go to the websites home page using appropriate URL

2. the system display login page with username , password field and
login button
3. the actor will fill the username field with his username
4. the actor will fill the password field with his password
5. the actor then hit the login button
6. the system will redirect the actor to appropriate home page

Alternative flow If the given username and password is invalid, reenter again valid
username and password.

Table 4.1 login scenario

Section 4.2.2.2
ID 02

Use case name Student registration

Description Using this use case new student that go to clinic can be registered.

Actors Nurse

Pre-condition The nurse has to login to the system and click “add new student” button
from the action panel

Post condition The student get successfully registered and get digital and clinical
identification card.

Basic flow 1. the nurse login to the system

30 | P a g e
 2. the system will redirect the student to their home page
3. the nurse will click to “add new student” button
4. the system will redirect them to registration home page
5. the actor will fill the form;
5.1 Enter student First Name (required)
5.2 Enter student last Name (required)
5.3 Enter student ID (required)
5.4 Select Student Department (required)
5.5 Select Student Year (required)
5.6 Select Student Batch (required)
5.7 Enter Student Card fee (optional)
6. the actor hit submit button
7. the system will notify the actor the operation is successful.

Alternative flow If each field’s value is not valid, reenter valid value

Table 4.2 student registration scenario

Section 4.2.2.3
ID 03

Use case name Register user

Description Using this use case admin can add a user when new user hired to clinic

Actors Admin

Pre-condition The admin has to login to the system and click “add new user” button
from the action panel

Post condition User can be registered successfully and get digital user identification
card

Basic flow 1. the admin login to the system

2. the system will redirect the admin to their home page

31 | P a g e
 3. the admin will click to “add new student” button
4. the system will redirect them to registration home page
5. the admin will fill the form;
5.1 Enter user first name (required)
5.2 Enter user last name (required)
5.3 Enter user ID (required)
5.4 Select user profession (required)
5.5 Enter user phone number (required)
5.6 Enter user email address (optional)
5.7 Enter user salary (required)
5.7 upload user photo (optional)
5.8 upload user credentials(required)
6. the actor will hit “submit” button

Alternative flow If invalid value is entered, reenter again a valid value.

Table 4.3 register user scenario

Section 4.2.2.4
ID 04

Use case name Register drug

description Using this use case the pharmacist can easily registered when a new
unregistered drug is available.

Actors pharmacist

Pre-condition The pharmacist login to the system and click “add drug” button in
action panel

Post condition The drugs can successfully registered

Basic flow 1. the pharmacist login to the system

2. the system will redirect the pharmacist to their home page

32 | P a g e
 3. the pharmacist will click to “add drug” button
4. the system will redirect them to registration page
5. the Actor will fill the form;
5.1 Enter Drug name
5.2 Enter Drug ID
5.3 Select Drug production date
5.4 Select Drug expiration date
5.5 Enter General Drug description
5.6 Select diseases cured
6. the actor will hit submit button
7. The system notify that the operation is successful.

Alternative flow If invalid value is entered, reenter again a valid value.

Table 4.4 register drug scenario

Section 4.2.2.5

ID 05

Use case name update Student

Description Using this use case the actors can easily modify the student’s data

actors nurse

Pre-condition The actors have to login to the system

after login the actor has to search a particular student via CID
and click the result

Post condition

Basic flow 1. the actor login to the system

2. the system will redirect the actor to their home page
3. the actor will put student’s id in text field

33 | P a g e
 4. the actor will hit “search” button
5. the system will display the student as clickable list
6. the actor will click on clickable list
7. the system will redirect the actor to update page
8. the system will display form:
8.1 Enter student First Name (pre-filled with previous value)
8.2 Enter student last Name (pre-filled with previous value )
8.3 Enter student ID (pre-filled with previous value)
8.4 Select Student Department (pre-filled with previous value)
8.5 Select Student Year (pre-filled with previous value)
8.6 Select Student Batch (pre-filled with previous value )

8.7 Enter Student Card fee (pre-filled with previous value)

9. actor will replace all or a particular field with new value
10. the actor will hit “update” button
11. the system will notify that the operation is successful

Alternative flow If invalid data entered, reenter valid data again

Table 4.5 update student scenario

Section 4.2.2.6
ID 06

Use case name Update user

Description Using this use case , the admin can update users data if necessary

Actors Admin

Pre-condition The actors have to login to the system, search for a particular user and
click on a particular user

Post condition

Basic flow 1. the actor login to the system

34 | P a g e
 2. the system will redirect them to their home page
3. Actor will fill the text field with user id
4. Actor hit “search” button
5. The system will display the result in the form of clickable list.
6. the Actor will click on list
7. the system will redirected to the update page
8. the system will display update form
8.1 Enter user first name (pre-filled with previous value)
8.2 Enter user last name (pre-filled with previous value)
8.3 Enter user ID (pre-filled with previous value)
8.4 Select user profession (pre-filled with previous value)
8.5 Enter user phone number (pre-filled with previous value)
8.6 Enter user email address (pre-filled with previous value)
8.7 Enter user salary (pre-filled with previous value)
8.8 upload user photo (pre-filled with previous value)
8.9 upload user credentials(pre-filled with previous value)
9. the actor will hit “update” button
10. the system will notify that the operation is successful

Alternative flow If invalid value provided, reenter valid data

Table 4.7 update user scenario

Section 4.2.2.7
ID 07

Use case name Update drug

description Using this use case, actor of this use case can modify drugs’ attribute

Actor pharmacist

35 | P a g e
Pre-condition The actor should login to the system, search a particular drug and click
the result

Post condition

Basic flow 1. the actor will login to the system

2. the system will redirect the actor to their home page
3. the actor will fill the text field with drug id
4. then the actor will hit “search” button
5. the result will be displayed as clickable list
6. the actor will click the clickable list
7. the system will redirected to update page
8. the system will display a form
8.1 Enter Drug name (pre-filled with previous value)
8.2 Enter Drug ID (pre-filled with previous value)
8.3 Select Drug production date (pre-filled with previous value)
8.4 Select Drug expiration date (pre-filled with previous value)
8.5 Enter General Drug description (pre-filled with previous value)
8.6 Select diseases cured (pre-filled with previous value)
9. the actor will replace all or particular field with new value
10. the actor will hit “update” button
11. The system will notify that the operation is successful.

Alternative flow If invalid data provided, reenter valid data

Table 4.8 update student scenario

Section 4.2.2.8
ID 08

Use case name Search drug

description Using this use case, actor of this use case can search drugs among

36 | P a g e
 stored

Actor pharmacist

Pre-condition The actor should login to the system

Post condition The searched drug will be displayed as clickable list

Basic flow 1. the actor will login to the system

2. the system will redirect the actor to their home page
3. the actor will fill the text field with drug id
4. then the actor will hit “search” button
5. the result will be displayed as clickable list

Alternative flow If invalid user id provided, reenter the user id again and search

Section 4.2.2.9

ID 09

Use case name Delete user

description Using this use case, actor of this use case can delete particular user of
the system

Actor admin

Pre-condition The actor should login to the system and search particular user and
click on the result of the search

Post condition That particular user will be deleted from the database

Basic flow First the actor login to the system and search particular user then the
system will display the searched user as clickable list. So the actor can
Click the clickable list to view detail information about the user.

Then the system will show detail information about user as well as
delete button. The actor click on delete button and then the system will
Ask the actor whether he want to delete or not. If the actor response is
yes, the user will be delete from the system. If the actor response is No,

37 | P a g e
 the user will not be deleted

If the operation is successful, the system will tell the actor that he
successfully deleted the user.

Alternative flow The admin will click on tabulate user data. Then the system will display
The user data in table form. So the user will right click on row of table

Then system will produce popup menu which include delete options.
When the user click the delete option system ask the actor to confirm. If
the actor confirm the deletion, the user will be deleted from the
database and the table will be updated. Then the system notify the
whether the operation is successful or not.

Table 4.9 delete user scenario

4.3 Sequence diagram

Sequence diagrams model the interactions between objects in a single use case. They illustrate
how the different parts of a system interact with each other to carry out a function, and the order
in which the interactions occur when a particular use case is executed.

In simpler words, a sequence diagram shows how different parts of a system work in a
‘sequence’ to get something done. The following sequence diagrams show each steps that
happened on each use cases.

A sequence diagram is structured in such a way that it represents a timeline that begins at the top
and descends gradually to mark the sequence of interactions. Each object has a column and the
messages exchanged between them are represented by arrows.

4.3.1 System sequence diagram:

The figure down below show each sequences that are performed when a particular student visit
the clinic and get service from it. Which shows the processes that happed from student
registration up to taking drugs and going back to dorm.

38 | P a g e
 Figure 4.6 system sequence diagram

4.3.2 Login sequence diagram:

Login is the use case of all users. Which mean that this product will cover the database records
with username and password. The login sequence diagram shows things that happened during the
login process. How each user can login and what steps have to implemented during login is
depicted by the following sequence diagram

39 | P a g e
 Figure 4.7 Login sequence diagram

4.3.3 Register student sequence diagram

The following diagram show the sequence of actions that need to be performed during register
student use case

40 | P a g e
 Figure 4.8 register student sequence diagram

41 | P a g e
4.3.4 Delete user sequence diagram

Figure 4.9 delete user sequence diagram

42 | P a g e
4.3.5 Search user sequence diagram

Figure 4.10 search user sequence diagram

43 | P a g e
3.3.7 Update user data

Figure 4.11 update user sequence diagram

44 | P a g e
3.4 Activity Diagram
An activity diagram visually presents a series of actions or flow of control in a system simi-
lar to data flow diagram. It can also describe the steps in a use case diagram.

4.4.1 Login Activity diagram

The following diagram show flow control of login use case

Figure 4.12 Login Activity diagram

45 | P a g e
4.4.2 Get debt Activity diagram

Figure 4.13 get debt Activity diagram

46 | P a g e
4.4.3 Instant Message activity diagram

Figure 4.14 Instant Message Activity diagram

47 | P a g e
3.5 E-R Diagram
ER diagram stands for Entity relationship Diagram, also known as ERD is diagram that
displays the relationship of entity sets stored in a database. In other words, ER diagrams
help to explain the logical structure of databases.

The following figure shows logical structure and relationship of GMBU clinical
management system databases. The database contains seven tables and each table related
with one or more tables logically as it is depicted in the figure.

Figure 4.15 E-R diagram of GMBU clinical management system

3.6 Deployment Diagram

Deployment diagram describes the software system’s specifications and physical hardware
system required to run the software. The deployment diagram also determines the
installation of the software on the hardware. It maps software segments of method to the
device that is going to implement it. The following diagram deployement diagram of
GMBU clinic management system.

48 | P a g e
 Figure 4.16 CMS deployment diagram

Conclusion
As described above, each chapter of this SRS document explain different thing about the
proposed applications. In chapter one allover description explained perfectly including
hardware and software requirement that CMS need to run. Functionality of products
explained from chapter two up to the chapter three. Diagrammatically last chapter
diagramed most of the software components not mentioning lot of limitation of this
software and this documents. So any software developer can see this document and create
web-based clinical management system which computerize paper-based system and reduce
the burden of clinical staff.

49 | P a g e
 References:

 https://www.studocu.com/in/document/apj-abdul-kalam-technological-
university/software-project-management/srs-example-for-web-application/20881481

 https://ir.unimas.my/id/eprint/3354/1/Clinical%20management%20system%20(CM
S).pdf
 https://www.slideshare.net/vidyasg/srs-present

 https://www.slideshare.net/susheel2658/srs-for-virtual-eucation

50 | P a g e