CHAPTER FOUR

SYSTEM ANALYSIS, DESIGN AND DEVELOPMENT

4.0 Introduction
The purpose of Design phase is to plan a solution for problem specified by the requirements.
System design aims to identify the modules that should be in the system, the specification of
those modules and how the interact with each other to produce the results. The goal of the design
process is to produce a model that can be used later to build that system. The produced model is
called design of the system.
This section consists of the requirements analysis of the project. The requirements analysis stage
is to identify and understand the requirements that would be expected from and required of the
project. Included within the requirements specification are the techniques or methods to identify
user requirements, functional requirements and the non-functional requirements of the system
4.1 System Analysis
“Is the process of studying a procedures or business in order to identify its goals and purposes
and create system and procedures that will achieve them in and efficient way” (Teorey T. J
2009).
Assuming that a new system is to be developed, the next phase is system analysis. Analysis
involved a detailed study of the current system, leading to specifications of a new system.
Analysis is a detailed study of various operations performed by a system and their relationships
within and outside the system. During analysis, data are collected on the available files, decision
points and transactions handled by the present system. Interviews, on-site observation and
questionnaire are the tools used for system analysis (Teorey T. J 2009).
4.1. 1 Problems faced by current system
The current system through which operations are carried out is a manual paper-based system.
Some problems associated with this system were mentioned earlier in previous section, they are
listed categorically in this subsection for the convenience purposes.
Time consuming: A major complain of patients regarding service providing and management is
the lengthy and almost invariably unnecessary waiting at queues and delays which may result
from causes of incorrect time being relayed to the doctor starting late in examining patients.
Figure 1.1 Use case Diagram of Patient Record Information System

Verify longs
in

Sign In

Home Page
Doctor
Admin

Modify
records

Insert
records

Register
records

Stuff Delete
Patient
records

Delete
account

Logout
The design class diagram in Figure 1.1 outlines the overall structure of the proposed system.
The system will rely on different classes of people. As seen in the use case diagram, these
different people will have different abilities within the system. An important note is that each of
these classes will be allowed access to certain files i.e. a patient has access to only their own file,
nurses will have access to all files but not consultation notes and doctors will have access to
everything. Administrators will have access to the administration section of the system where
they have the ability to change access rights and manage the users of the system. Each individual
would have to be given a unique identifying number as well. The requirements are divided into
two categories:
Functional requirements
Non-functional requirements.
4.2.1 Functional Requirements
Admin management: this role encompasses the overall administration of the healthcare facility.
Overall administration of the patient record information system.

Patient Management: this role focuses on the patient experience within the patient record
management system.
The primary objective here is to provide easy access to all the previous medical reports. Most
often we lost the medical reports at the end of the diagnosis.
Patients Profile: The patient’s profile will be open to visiting doctors only. Only the patient
chooses his/her record visibility here. The profile will be private to maintain privacy of
information.
Doctor management: this pertains to the administration of medical particularly physicians.
Stuff management: this involves overseeing the human resources within a healthcare facility
4.3.2 Non-Functional Requirements
There are a number of non-functional requirements that are expected from the system. They are
the following:
Consistency – The system should perform consistently to provide services to the users, the
interfaces of the system are to be consistent and standardized such that end users are comfortable
with using it.
Convenience – Convenience in using the system to carry out operations is a necessary
requirement to avail the services.
Availability – It is an essential requirement; the system has to be available and operational 24
hours in order to ensure that there is no disruption in the operations.
Usability –The system needs to be user-friendly and easy to use so that users are encouraged to
use it and do not confused or discouraged away from it otherwise.
Security – Ensuring security and privacy of the users and their personal data is very important;
user passwords to allow authorized access only and mechanisms to prevent unauthorized access
shall be in place.
Reliability – The healthcare management system must be reliable in terms of its functions; it
must deliver the functional requirements efficiently.
4.3.3 Software requirements
The Software Requirements include; Windows 8/10/11, PHP, MySQL and HTML.
4.3.4 Hardware requirements
The Hardware Components includes; Processor – i3, i5, Hard Disk – 5 00GB, Memory – 2GB
RAM
4.4 System Design
This stage is vital in the sense that the proposed procedures of operations described in the form
of activity diagrams will eventually result in software. In this section the activity diagrams, use
case diagrams and data dictionary for the system will be presented. The reason for giving activity
diagrams and use case diagrams is that they are an efficient and effective means to convey how
particular actions on the system are carried out to the reader which can be comprehended by
quick glance.
4.4.2 Database Design
Database design is the organization of data according to a database model, the designer
determines what data must be stored and how the data element interrelate, with this information
they can begin to fit the data to the database model (Teorey T. J 2009).
Conceptual database diagram: A conceptual data model is the integrated view of all data in an
enterprise, and bridges the gap between the data organization as viewed by the database
management system (the physical data model), and by individual user applications (logical data
models). One of the primary motivations behind this three-level architecture is shielding
applications from changes to the physical design ("physical data independence"), and changes to
the conceptual design ("logical data independence").
4.4.3 Physical database design
4.5 System Development
System development is the process of defining, designing, testing and implementing a new
software application or a program, it could include the internal development of customized
system, the creation of database system, or the acquisition of a third party developed software.
1.1 Sample of system Login interfaces

This part of the system introduced the login interface for all the activities to be done with in the
system, it’s the part where Admin login and all the staffs that are working within the hospital.
1.2 Admin Login interfaces

This part of the system introduced the admin login interfaces, its roles are to add, delete, update
and control all the activities within the system.
4.6.1. User login interface.

Allow the registration and management of doctors. Maintain a database of

doctors’
credentials, specialties, and contact information. Provide the ability to assign
doctors to
specific patients or appointments.
1.4 User login interface.
Figure 14 shows the profile page of the system where information about the
user will be displayed. On the interface of the administrator, all barangay health
worker accounts will be displayed, the administrator can also delete these accounts
on this page.
Provide secure user authentication and authorization. Allow administrators to
create and
manage user accounts with different access levels. Maintain a user database
with user
1.5 Patient login interface.

In this figure, the patient profile page is shown. Once a user selects a name of
a patient, it will be redirected to this page. In this page all the personal information,
activities and history of the patient will be displayed. In addition, the backup module
is responsible for creating this page. Furthermore, users can easily see the edit
history on this page.
4.6.3. System Testing