G7 patient record system

Al-Zaytoonah University of Jordan
Faculty of Science and Information Technology
Department of Software Engineering

Patient record system
By
GAITH AMER RAMMAHA
ALAAMAHMOUDAl-ZOUBI
ZAID ALIGHANAYEM

Supervised by
DR. MOHAMAD LAFI

A GRADUATION PROJECT SUBMITTED IN PARTIAL FULFILMENT OF HE
REQUIREMENTS FOR THE DEGREE OF BSC IN SOFTWARE ENGINEERING

Month Year (May 2013)

i

Abstract
A brief discussion about the overall project, and must be up to one page length

Acknowledgment

Here you write your personal messages to the people you would like to thank.
The recommendation here is:
All members can write one general acknowledgment
If one chooses to write an acknowledgement, then all must write his/her own dedication.

iii

1 CHAPTER ONE: INTRODUCTION
1.1 Background
In our project we will try making it easy to anyone who involved in the medical category, like a
doctor, hospital, pharmacy even the patient himself, to check the patient's condition in a site that
have the record of all the disease, allergies, medicine (that he having or had) and the blood type
that can help the patient in any hospital he go so he get recover easily and fast.

When any one of the category want show the records he have to enter the site and login and
search to the exact patient by his name or the national number, then the doctor for example can
see or update the patient data (record) about the condition that he responsible of it.

Through our site the people who involved can save time, money and treating the patient more quickly
and known more information to help him easily.

1.2 Literature Review
Well, in our project the idea never get done by any one so we research for something
Similar, about a clinic that have a website to prove the info about the Disease and the
Medicine, and their project was not that useful for the community so we developed the
idea to become more productive.

1

1.3 Business Model

1.3.1Business Needs

Patient record is built to solve some problems that may face the patient when he goes to a
random hospital or clinic for treatment that don’t have patient record. Using our site the doctor
who responsible of the patient will be able to see what the patient records of diseases, info and
contact the Guardian of him. In this way we can save the money, effort and time for the hospital
or clinic and the patient.

After the doctor see the patient info online and find out what he is suffering, the doctor should be
able to change and update the patient record and what medicine need , so the pharmacy give the
patient the right medicine or for future condition .

The site offers a way to the patient and doctor can be contact or a doctor to another 24/7, any
doctor, pharmacy or anyone involved with the medical category can access the site by his
medical number to see any records of an any patient that he need to see, in the other hand the
regular person (patient) can access the site to only see his records.

1.3.2Business Environment

Def:Business environment encompasses all those factors that affect a company's
operations, and includes customers, competitors, stakeholders, suppliers, industry trends,
regulations, other government activities, social and economic factors and technological
developments.

In our project there are:
Tools:
Microsoft Project Professional 2010 Plus
IBM Rational Rose 2007
Adobe Dreamweaver cs5 or cs6
My SQL server 2008
Adobe Photoshop cs5
Microsoft Visio 2010
Microsoft PowerPoint 2010

2

*Microsoft Project Professional 2010 plus: Because we make a Gantt chart and we make
feasibility study of the project.
*IBM Rational Rose 2007: Because we analysis the project by this tools and make a design of
the project.
*Adobe Dreamweaver: Because we to build and design the website and use the PHP language
and design interface.
*My SQL Server: because store, insert and import the data in the server.
*Adobe Photoshop cs5: to design the picture in the web.
*Microsoft Visio 2010: Because we drawing charts of our project as a context diagram and state
chart diagram.
*Microsoft PowerPoint 2010: Because we drawing charts of our project as a context diagram
and state chart diagram and to presentation.

Environment:
1- Windows 8
2- CPU: Core i3 Second Generation 3.3 GHz Speed
3

3- RAM: 8 Giga DDR3
4- HD: 500GB

1.3.2.1 Software Context Diagram

Fig (1.1) Software context diagram

1.3.2.2 System Scope

The idea of the project consists the Medical Records of the Patient (MRP), which has three major
interfaces:

 Interface of admin where the admin give the privileges for users.
 Interface for a Patient to see his Medical Records.
 Interface of Medical staff where they can change and update thedata and for the patient.

4

1.3.3Stakeholder Analysis
Stakeholder name Stakeholder represent Role
Admin Who administrate the system He hasprivileges to edit the
whole data in the website.
Doctor Who update the data He change and update the Record
Patient.
Patient Who utilize the website See his record
Pharmacist Update the drug data (Limited ) Change the drug section in the
patient record.

Medical tester Update the tests section Change and update Medical tests
(Limited) section only
Radiology Update the Radiology picture Change and update Radiology
(Limited) section only
Table (1.1) Stakeholder analysis

1.3.4System Vision Document
1.3.4.1 Objectives
- Conversion the '' Record Patient'' system from manual and paper to electronic to keep up
with the modernity,
- Storage the records data so that Information will be available always.
- So can all any Patient get his records anywhere any time.

1.3.4.2 Benefits

5

1. Minimize time and effort.

2. Minimize errors.

3. Speed in giving results.

4. Facilitate data storing.

5. Reduce the number of Patients.

6. Reduce the pressure on admin and all stakeholders.

7. Saving money.

8. Provide security.

1.3.4.3 Capabilities

1. Reduce thetimeittakesin terms ofthe presence ofthepatient's
fileelectronicallyandminimizetheeffortto obtain the file.

2. Reduce errors that result from not patients arrange files through the system we will
process the order of the files on the system

3.Data storage byofficialsonthedatabaseof the systemwithease.

4. Save money by havingthe patient'sfileonthesystemand does not neednew testsastheyexist
on thesystem.
5.Provides security and safety of the data, Available through for all Patients and all medical
staff (doctors, hospital ... etc.).

1.3.5Project Management
1.3.5.1 Project Iteration and Schedule

Task Mode Task Name Duration Start Finish Predecessors Resource Names

6

Manually 0
Start
Scheduled days
Auto 12
Inception
Scheduled days
Auto 12
Iteration I1
Scheduled days
Auto Business
7 days
Scheduled Modeling
Manually Define
2 days 1 Gaith
Scheduled Business Needs
Evaluate
Manually
Existing 2 days 5 Alaa
Scheduled
Infrastructure
Manually Stakeholder
2 days 6 Zaid
Scheduled Analysis
Manually Define Vision
1 day 7 Gaith
Scheduled Document
Manually Business Modeling
0 days 8 Alaa;Gaith;Zaid
Scheduled Report
Auto Project
5 days
Scheduled Management
Manually Define Project
1 day 9 Gaith
Scheduled & System Scope
Manually Project &
2 days 11 Alaa
Scheduled Iteration Schedule
Manually Define Risks
2 days 12 Zaid
Scheduled & Feasibility study
Project
Manually
Management 0 days 13 Alaa;Gaith;Zaid
Scheduled
Report
Auto
Environment 5 days
Scheduled
Manually Select
1 day 6 Alaa
Scheduled Development Tools
Select
Manually
Development 2 days 9 Zaid
Scheduled
Process
Manually Select
1 day 6 Alaa
Scheduled Support Services
Manually Environment
Scheduled Report
Auto 31
Elaboration
Scheduled days
Define Support
Manually
Services 2 days 6 Alaa
Scheduled
Architecture Design
Manually Define 2 days 21 Alaa;Gaith;Zaid

7

Scheduled System/Software
Architectural
Design
Auto 31
Iteration E1
Scheduled days
Auto 14
Requirement
Scheduled days
Manually Gathering
3 days 22 Gaith
Scheduled Requirements
Define
Manually
Functional 2 days 25 Alaa
Scheduled
Requirements
Define Non-
Manually
Functional 2 days 25 Zaid
Scheduled
Requirements
Manually Requirement
Scheduled Report
Auto System
9 days Alaa
Scheduled Models
Manually Use Case
2 days 26 Alaa
Scheduled Model
Manually Domain
2 days 30 Alaa
Scheduled Class Model
Use Cases
Manually
Descriptions 3 days 30 Zaid
Scheduled
"Scenarios"
Activity &
Manually
System Sequence 2 days 32 Zaid
Scheduled
Models
User
Interface-
Manually
Navigational Paths 2 days 33 Gaith
Scheduled
and Screen Mock-
ups
Manually
State chart Model 2 days 31 Gaith
Scheduled
Manually System
Scheduled Models Report
Auto 31
Design
Scheduled days
Auto Services
1 day
Scheduled support design
Manually Software
1 day
Scheduled architecture design
Details
Auto
Design "Use Case 7 days
Scheduled
Realization"
Manually 3 days 33 Zaid

8

Scheduled Communication
Model
Manually Design
2 days 41 Alaa
Scheduled Class Model
Manually Package
1 day 42 Gaith
Scheduled Model
Manually
State chart Model 1 day 43 Gaith
Scheduled
Manually Details
Scheduled Design Report
Auto Database
5 days
Scheduled Design
Manually Entity
1 day 45 Alaa
Scheduled Relationship Model
System &
Manually
User Interfaces 2 days 47 Gaith
Scheduled
Design
System
Manually
Controls & Security 2 days 48 Zaid
Scheduled
Design
Manually Design
Scheduled Activities Report
Auto
Iteration E2 1 day
Scheduled
Auto Integration E1 &
1 day Gaith;Alaa;Zaid
Scheduled E2
Auto
Iteration E3 1 day
Scheduled
Auto Integration E1 &
1 day
Scheduled E2 & E3
Manually 30
Construction
Scheduled days
Auto 10
Iteration C1
Scheduled days
Auto E1 Code 10
Scheduled Generation days
Generate
Design Class
Manually
Model to Specific 1 day 50 Alaa
Scheduled
Programming
Language
Generate
Design Class
Manually
Model to Specific 1 day 50 Alaa
Scheduled
Database
Language
Manually Writing
7 days 58;59 Gaith;Zaid
Scheduled Programming

9

Algorithms
Manually Algorithms
2 days 60 Gaith;Zaid
Scheduled Unit Testing
Manually C1 Working
0 days 59;58 Alaa;Gaith;Zaid
Scheduled Prototype
Auto
Iteration C2 1 day
Scheduled
Auto Integration
1 day
Scheduled Testing C1 & C2
Auto
Iteration C3 1 day
Scheduled
Integration
Auto
Testing C1 & C2 & 1 day?
Scheduled
C3
Auto
End 0 days 62
Scheduled

Fig (1.2) Gantt chart

1.3.5.2 Project Financial Feasibility and Risk Analysis

Project Financial Feasibility

The goal of project is to Ease and a speed, to get to all Patient records more flexible and to make
the system more efficient and easy to use for other users. In addition:
Reduce the number of the employees.
Reduce the cost of traveling to the user.
More protection and safety.

Risk analysis

When we talk about risk analysis, we have to know what is the meaning is of risk analysis.
Risk analysis: Clinical and administrative activities undertaken to identify, evaluate, to reduce
the risk of loss to the organization itself. Activities include the process of making and carrying
out decisions that will prevent or minimize clinical, business, and operational risks.
Now the risks of this project, as follows:

10

Securing the communication between the home computer to the user and the central
server is also a problem.
Sometimes the internet is not available for the user.
Some people do not like or do not know the use of the Internet.

Risk Description Potential impact on Likelihood of Difficulty of timely Overall threat
project occurrence anticipation (high,medium,low)
(high,medium,low) (high,medium,low) (high,medium,low)

Users can not high medium medium high
access to the
system

Users can not high medium high high
enter data

Users can not use medium low low medium
a computer savvy

1.3.6Development Environment
1.3.6.1 Development Tools and Support Services

IBM Rational Rose 2007:

11

1- Build software architecture that supports change with a common platform that facilitates
easy roundtrip engineering and synchronization of models and code.
2- Accelerate implementation and facilitate maintenance of a service-oriented architecture
(SOA) solution, such as a web service, with tools and process guidance.
3- Use UML to ensure the numerous stakeholders within your software development
projects are continuously communicating, and use defined specifications to jumpstart
development.
4- Gain insight into distributed projects and tighter control of shared information.

Adobe Dreamweaver cs5 :
Adobe Dreamweaver CS5 is a program used to develop Websites in terms of design. There
are many sites online that were made from Dreamweaver. It's become a bit of a staple in the
industry, and the new CS5 version is no exception.

Just as is the case with most every program though, there are pros and cons to consider when
deciding whether the cost of CS5 is worth if for your particular needs and interests.

Pros:

-1-Popularity

CS5 and Dreamweaver in general, are quite widespread across the Internet. This means that
there is a lot of knowledge out there on the program. There are entire communities of
individuals devoted to Dreamweaver and CS5. This allows you to go on to those
communities and ask questions about the program there and get a quick response. So this is a
major advantage Dreamweaver and CS5 has over other programs that might not be as well
known.

The familiarity of the program will also make it easier to find anyone nearby who might
know of it and any kind of help you might get whether official or unofficial is more likely
since the program is so well known.

-2-Complete Management

Dreamweaver isn't just a tool for developing a single page. It can also develop entire
websites, integrating them all together with a variety of different integrating tools. This cuts
down on the amount of extra work you have to do, or the extra tools and programs you may

12

need. Dreamweaver CS5 allows you to use all these different tools together in a single
program.

-3-Speed and Integration

The CS5 update for Dreamweaver, which came out in April of 2010, is also known for
having good speed and web integration. Working with images on the web is easier than in
previous versions. The speed at which the program is capable of working has also been much
improved.

CS5 also integrates well with the rest of the Adobe suite, making it easier to go back and
forth between different programs for more total control over various procedures on your
computer, such as desktop publishing.

My SQL server 2008:
1- A parent Data Encryption. The ability to encrypt an entire database.
2- Backup Encryption. Executed at backup time to prevent tampering.
3- External Key Management. Storing Keys separate from the data.
4- Auditing. Monitoring of data access.
5- Data Compression. Fact Table size reduction and improved performance.
6- Resource Governor. Restrict users or groups from consuming high levels or resources.
7- Hot Plug CPU. Add CPUs on the fly.
8- Performance Studio. Collection of performance monitoring tools...etc...

Adobe Photoshop cs5:
1- Image editing and additions anddinette gratedorpictures.
2- Also add text.
3- And Web Design.
Microsoft Visio 2010:
1- Simplify complexity with a diverse set of intuitive, professional diagramming tools
2- Bring your diagrams to life with dynamic, data-driven visuals.
3- Share interactive, refreshable, data-linked diagrams with others via their Web browsers.

Microsoft project Professional 2010 plus:
1- Easily plan & manage your projects with intuitive controls and flexible team tools to help
your organization deliver the intended business value.
2- Be efficient and prioritize by aggregating everyday work, project tasks, important details,
and timelines in a visually rich and contextual interface.

13

3- Manage anywhere with tools to keep you connected with your team and on top of your
projects while you’re on the go.
4- Deliver effective presentations that offer immediate insight into task planning, resource
allocation, cost efficiencies, and the many important details of your projects etc……..

Microsoft PowerPoint 2010:
1- Manage presentations with tools that save time and simplify your work.
2- Create extraordinary presentations.
3- Work together more successfully.
4- Access and share your content from more places.

1.3.6.2 System Development Process
The Rational Unified Process (RUP) is an iterative software development process framework created by
the Rational Software Corporation, a division of IBM since 2003.RUP is not a single concrete
prescriptive process, but rather an adaptable process framework, intended to be tailored by the
development organizations and software project teams that will select the elements of the process that are
appropriate for their needs. RUP is a specific implementation of the Unified Process.

Fig (1.3) System development process

2 CHAPTER TWO: REQUIREMENTS

14

The project requirements phase is one of the most important parts of your project and
especially project. Working on a software project, you should use Software Engineering
techniques in this phase. Requirements are prepared by communicating with your customer
which is in general your advisor.

2.1 Gathering Requirements
 Interview method:
Interviewing is an important method for collecting data on information system requirement. An
information gathering way represents a directed conversation with a specific purpose that uses
question-and-answer format we met some of the staff working in the medical department of
electronic.
 Questionnaires:
have advantages over some other types of surveys in that they are cheap, do not require as much
effort from the questioner as verbal or telephone surveys, and often have standardized answers
that make it simple to compile data. However, such standardized answers may frustrate users.
Questionnaires are also sharply limited by the fact that respondents must be able to read the
questions and respond to them.

2.2 System Problem Statement
The old system was a traditional where was dealing with the documents manually, but now has
become a web application where all users of the system can interact with the system which aims to
facilitating of interaction and saving both time and effort.

In the old system, the record of patient was an available for one hospital or clinic but now all the
medical staff in country can access to his record, the current system facilitate a retrieval and access to
the data, unlike what was in the old system, the current system provides the possibility of see it
where ever you are, this system also decrease an effort placed on the patient, who was doing a
registration in ever hospital manually.

2.3 Functional, Non-Functional Requirements and System
Constraints

15

Functional Requirements:
Functional requirements are actions which the system does on behalf of the user, also it used to express
the behavior of a system by specifying both the input and output conditions that are expected to final
result.
Functions of users :

I. Administrator
- Maintain patient employee info
- Search patient
- Search employee
- Login
- Log out
- Change password

II. Doctor
- Search patient
-change all the data of the patient record
- Login
- Log out
- Change password

III. Pharmacist

-Search patient
-Maintain druginfo
- Login
- Log out
- Change password

IV. Patient

- View his patient’s history record
- Login
- Log out
- Change password

V. Medical tester

- Search patient
-Maintain Medical info tests section only.

16

- Login
- Log out
- Change password

V. Radiology

- Search patient
-Maintain Radiology info section only.
- Login
- Log out
- Change password

Non-Functional Requirements:
Non- functional requirements are conditions and constraints which the program must conform, and
the following list summarized non-functional quality attributes of a program:
Usability

Where the system must be easy to use and any user can interact with it.

Reliability

Where the system works correctly without any problems or errors.

Efficiency

Where the system executes all operations in a shorter time.

Availability
The system must be available when the user need it at any time and can get access to the
Website.

Security

In the security there is a special user name and password for each user of the system and each user
has certain privileges.

17

System constraints:

1. Financial barriers through, difficulty to pay money.
2. Unqualified medical staff.
3. Weak planning and management between pharmacist and doctor.

2.4 System Models
2.4.1Use Case Model

searchDoctor searchMedicaltester
searchPatient

<<include>>
<<include>> <<include>> <<include>>
searchRadiology

<<include>>

Admin login
<<include>>
searchPharmacist
<<include>> <<include>>

logout
changeProfile
maintlenAllUser

18

<<include>> logout
<<include>> X-rayChange

<<include>>

<<include>>
logout
login
login drugchange Radiology
Pharmacist
<<include>> <<include>>
<<extend>>
<<extend>>
changeProfile
changeProfile

forgot password
forgot password

19

<<include>>
<<include>>
logout
<<include>>
<<include>>
login
Medicaltester
<<include>> changeProfile <<include>> login Patient
<<extend>>
<<extend>>

changemedicaltester showAlltheprofiles

forgot password forgot password

<<include>>

<<include>> logout

Doctor login
<<include>>
<<extend>>
chengePatientrecord

forgot password changeProfile

2.4.2Domain Class Model
Domain class:
The class diagram is the main building block of object oriented modeling. It is used both for general
conceptual modeling of the systematic of the application, and for detailed modeling translating the models
into programming code. Class diagrams can also be used for data modeling. The classes in a class
diagram represent both the main objects and or interactions in the application and the objects to be
programmed. In the class diagram these classes are represented with boxes which contain three parts:

A class with three sections:
1-The upper part holds the name of the class
2-The middle part contains the attributes of the class

20

3-The bottom part gives the methods or operations the class can take or undertake
In the design of a system, a number of classes are identified and grouped together in a class diagram
which helps to determine the static relations between those objects. With detailed modeling, the classes of
the conceptual design are often split into a number of subclasses.
In order to further describe the behavior of systems, these class diagrams can be complemented by state
diagram or UML state machine. Also instead of class diagrams Object role modeling can be used if you
just want to model the classes and their relationships

21

2.4.3Use Cases Descriptions "Scenarios"
A Use Case Scenario is a description that illustrates, step by step, how a user is intending to use a
system, essentially capturing the system behavior from the user's point of view. A use case scenario

22

can include stories, examples, and drawings. Use cases are extremely useful for describing the
problem domain in unambiguous terms and for communicating with the potential users of a system.

Use Case Name: login
Scenario: Login to System
Triggering Event: User wants to login to the website

Brief Description: User must be a member in user database
Actors: Admin , Doctor, Pharmacist, Patient , Medical tester , Radiology
Related use case Logout
Stakeholders: Admin , Doctor, Pharmacist, Patient , Medical tester , Radiology
Preconditions: User database exists and Username, password and user type are correct.
Post conditions: Login to the web
Flow of Event: Actor System
1. User enters information. 2. Verify user
information.
3-login to the web

Exception 1.1 If incorrect data (user name, password, user type) deny access to the user
Conditions: account and display error massage.
1.2 If account is block, display error message.

Table (2. ) User login scenario

23

Use Case Name: Logout.
Scenario: Logout from System
Triggering Event: User wants to logout from website

Brief Description: User want to logout
Related use case:


Preconditions: Login to the web

Post conditions: Exit web.

1. Select logout button 2. Exit from the
system.

Exception Conditions:

Table (2. ) Logout scenario

24

Use Case Name: Change Password
Scenario: Change Password
Triggering Event: user wants to change password

Brief Description:
Related use case:
Preconditions: User writes the old password and then the new password is correct.
Post conditions: The password changed successfully
1. User enter the old password 2. verify the old password

4. system save the new
3. user enter new password and retype it password to database

Exception 1.1 If incorrect data (password) deny access to the user account and display error massage.
Conditions: 1.2 If account is block, display error message.

Table (2. ) change password scenario

Use Case Name: Forget Password
Scenario: User forget his password
Triggering Event: user wants to recover him password
Brief Description: User forget him password and want to recover it by send him password in him
e-mail
Related use case:
Preconditions:
Post conditions: The password has been sent to user e-mail
1. User enter him e-mail 2. verify the e-mail has been founded
And send the password to him e-mail

Exception 1.1 the e-mail is incorrect
Conditions: 1.2 the e-mail is not found in database

25

Table (2. ) forget Password scenario

Use Case Name: Create Account Employee
Scenario: Admin add anEmployee to the database
Triggering Event: Admin wants to add a new Employee to the database

Brief Description:
Actors: Admin
Related use case:
Stakeholders: Admin , Doctor, Pharmacist, Medical tester , Radiology
Preconditions: admin must exist
Post conditions: New Employee object must exist
1. Enter new Employee information 2. Create new Employee,
display information

3.Create new Employee,
display information

Exception 1.1 if the Employee found in the database, then give a message
Conditions:
Table (2.5) Insert Employee scenario

Use Case Name: Verify Account Admin
Scenario: Admin verify account to the database
Triggering Event: Admin wants to verify account to the database

Brief Description:
Actors: Admin
Related use case:
Stakeholders: Admin
Post conditions: Admin object must exist
1. Enter Admin information 2.Admin display

26

information

Exception 1.1 if the Employee found in the database, then give a message
Conditions:
Table (2.6) Verify Account scenario

Use Case Name: Delete Employee
Scenario: Admin delete anEmployee from database
Triggering Event: Admin wants to add a new Employee and Candidates to the database

Brief Description:
Actors: Admin
Related use case:
Preconditions: Employee must exist
Post conditions: Employee information must not exist
1. A Election officer filter the user and delete 2. System retrieve all
these Employee Employee from DB

3.DeleteEmployee
information

Exception 1.1 if the admin not found in the database, then give a message
Conditions:
Table (2.7) Delete Employee scenario

Use Case Name: Edit Employeeinformation
Scenario: Admin edit anEmployee information database
Triggering Event: User information needs to be updated

Brief Description:
Actors: Admin
Related use case:
Preconditions: admin exists
Post conditions: Employee exist

27

1. Enter Employee update 2 .Update Employee
information

Exception
Conditions:

Table (2.8) Edit Employee scenario

Use Case Name: Create Account Patient
Scenario: Admin add a Patient to the database
Triggering Event: Admin wants to add a new Patient to the database

Brief Description:
Actors: Admin
Related use case:
Stakeholders: Admin , Patient
Post conditions: New Patient object must exist
1. Enter new Patient information 2. Create new Patient,
display information

3.Create new Patient,
display information

Exception 1.1 if the Patient found in the database, then give a message
Conditions:
Table (2.9) Insert Patient scenario

Use Case Name: Verify Account Admin
Scenario: Admin verify account to the database
Triggering Event: Admin wants to verify account to the database

Brief Description:
Actors: Admin

28

Related use case:
Stakeholders: Admin
Post conditions: Admin object must exist
1. Enter Admin information 2.Admin display
information

Exception 1.1 if the Patient found in the database, then give a message
Conditions:
Table (2.10) Verify Account scenario

Use Case Name: Delete Patient
Scenario: Admin delete a Patient from database
Triggering Event: Admin wants to add a new Patient and Candidates to the database

Brief Description:
Actors: Admin
Related use case:
Preconditions: Patient must exist
Post conditions: Employee information must not exist
1. A Election officer filter the user and delete 2. System retrieve all
these Patient Patient from DB

3.Delete Patient
information

Exception 1.1 if the admin not found in the database, then give a message
Conditions:
Table (2.11) Delete Patient scenario

Use Case Name: Edit Patient information
Scenario: Admin edit a Patient information database
Triggering Event: User information needs to be updated

29

Brief Description:
Actors: Admin
Related use case:
Preconditions: admin exists
Post conditions: Employee exist
1. Enter Patient update 2 .Update Patient
information

Exception
Conditions:

Table (2.12) Edit Patient scenario

Use Case Name: SearchPatientinformation
Scenario: Admin search Patient information
Triggering Event: Admin search Patient information

Brief Description:
Actors: Admin
Related use case:
Preconditions: Admin must exist
Patient information must exist
Post conditions: None
1. Enter Patient information 2.Find and display Patient
information

Exception 1.1 if admin not found, then give a message
Conditions: 1.2 if Patient not matches, then give a message
Table (2.13) Search Patient scenario

Use Case Name: Search Employee information
Scenario: Admin search Employee information

30

Triggering Event: Admin search Employee information

Brief Description:
Actors: Admin
Related use case:
Employee information must exist
1. Enter Employee information 2. Find and display
Employee information

Conditions: 1.2 if Employee not matches, then give a message
Table (2.14) Search Employee scenario

Use Case Name: View Employee information
Scenario: Admin view Employee information
Triggering Event: Admin view Employeeinformation

Brief Description:
Actors: Admin
Related use case: Doctor, Pharmacist, Medical tester , Radiology
Employee information must exist
1. Enter Employee information 2. Find and display
Employee information

Conditions: 1.2 if Employee not matches, then give a message
Table (2. 5) viewEmployeescenario

31

Use Case Name: Show Patient table
Scenario: Admin show the Patient oftable
Triggering Event:
Brief Description:
Actors: Admin
Related use case:
Stakeholders: Admin
Preconditions:
Post conditions:
1. Admin asked system 2. System retrieve all Patient data
about Patient table

Exception
Conditions:
Table (2.16) Show Patient table scenario

Use Case Name: Show Employee table
Scenario: Admin show the Employee of table
Triggering Event:
Brief Description:
Actors: Admin
Stakeholders: Admin
Related use case:
Preconditions:
Post conditions:
1. Admin asked 2. System retrieve
system about all Employee data
Employee table
Exception
Conditions:
Table (2.17) Show Employee table scenario

32

Use Case Name: Admin add advertise
Scenario: Admin Add advertise to DB
Triggering Event:
Brief Description:
Actors: Admin
Related use case:
Stakeholders: Admin
Preconditions: --------
Post conditions: advertise add to DB
1. Admin add an advertise 2. Add the new advertise
information to DB

Exception 1.1 advertise information not completed
Conditions:
Table (2.18) Admin add ads scenario

Use Case Name: Admin advertise deletes
Scenario: Admin delete a Candidate from database
Triggering Event:

Brief Description:
Actors: Admin
Related use case:
Stakeholders: Admin , Candidate
Preconditions: Ads must exist
Post conditions: Advertise information must not exist
1. delete advertise information 2. System
retrieve all
advertise from
DB

3.Delete advertise
information

Exception 1.1
Conditions:
Table (2.19) Admin ads deletes scenario

33

Use Case Name: Insert Drug
Scenario: Insert Drug information
Triggering Event:

Brief Description:
Actors: Pharmacist
Related use case:
Stakeholders: Pharmacist
Preconditions: Drug must exist
Post conditions: Drug information must not exist
1. delete Drug information 2. delete Drug
information
Exception 2.1 if the Pharmacist
Conditions: not found in the database, then give a message
Table (2.20) Insert drug scenario

Use Case Name: Delete Drug
Scenario: Delete Drug
Triggering Event: Pharmacist wants to Drug delete from database

Brief Description:
Actors: Pharmacist
Related use case:
Preconditions:
Post conditions: Drug created
1. enter new Drug information 2.Create Drug
record and display
information
Exception
Conditions:

34

Use Case Name: Edit Drug
Scenario: Edit Drug information
Triggering Event: Drug information needs to be updated

Brief Description:
Actors: Pharmacist
Related use case:
Preconditions: pharmacist exists
Post conditions: Drug user exists
1. Enter Drug update 2. Update Drug
information
Exception
Conditions:

Use Case Name: Search Drug
Scenario: Pharmacist Search Drug information
Triggering Event:

Brief Description:
Actors: Pharmacist
Related use case:
Preconditions: Drug must exist
1. Search Drug 2. Search Drug
Exception 1. if Drug not found, then give a message
Conditions:

35

Use Case Name: Insert disease
Scenario: Insert disease information
Triggering Event:

Brief Description:
Actors: Doctor
Related use case:
Stakeholders: Patient ,Doctor
Preconditions:
Post conditions: Diseasecreated
1. enter diseaseinformation 2.Create disease
record and display
information
Exception
Conditions:
Table (2.24) Insert new disease scenario

Use Case Name: Delete disease
Scenario: Delete disease information
Triggering Event: Doctor wants to disease delete from database

Brief Description:
Actors: Doctor
Related use case:
Preconditions: disease must exist
Post conditions: disease information must not exist

1. Delete disease information 1. Delete disease
information
Exception
Conditions:
Table (2.25) Insert disease scenario

36

Use Case Name: Edit disease
Scenario: Edit disease information
Triggering Event: Disease information needs to be updated

Brief Description:
Actors: Doctor
Related use case:
Preconditions: Disease must exist
Post conditions: Disease user exists
1. Enter disease update 2. Update disease
information
Exception
Conditions:
Table (2.26) Edit disease scenario

Use Case Name: View history patient
Scenario: Patient&Employee view history patients
Triggering Event: Disease information needs to be updated

Brief Description:
Actors: Patient , Employee
Related use case:
Stakeholders: Patient , Employee
Preconditions: patient must exist
1. view history patient information 2. View history
patient information.
Exception 1. if patient&Employee not found, then give a message
Conditions:
Table (2.27) View history patient scenario

37

2.4.4Activity & System Sequence Models

 System activity model:

Is used to display the sequence of activities and show the workflow from a start point to the finish
point detailing the many decision paths that exist in the progression of events contained in the
activity.

 System sequence model:

Is a kind of interaction diagram that shows how processes operate with one another and in what
order, it is a construct of a message sequence chart, and it shows object interactions arranged in time
sequence. It depicts the objects and classes involved in the scenario and the sequence of messages
exchanged between the objects needed to carry out the functionality of the scenario.

38

user system

error message

[ not ok ]

user enter info
verify user

[ ok ]

login to the
web

39

admin system

select logout
button

Exit from the
system

40

patient system

Enter Patient
information

Find and display
Patient information

Pharmacist system

delete Drug
information

delete Drug
information

41

3 CHAPTER THREE: DESIGN
3.1 Architecture and Deployment environment Design
(Network environment)

3.2 Software Architecture Design

3.3 Sequence Models
Show your details design by giving up to 3 examples of your cases here, and add the
rest to your appendix section (don’t print it out just keep it available with your
softcopy of the project under (Appendix A: Expanded Sequence Models) section.

42

3.4 Design Class Model
3.5 Design package model (optional)
3.6 Design the database
3.6.1Design Entity-Relationship Model
3.7 Design the system and user interfaces
3.8 Design the system security

4 CHAPTER FOUR: IMPLEMENTATION
4.1 Generate Design class model to specific programming
language syntax
Show the code for each of cases you have shown in the previous chapter (section 3.3:
sequence models)

4.2 Generate Entity-Relationship model to SQL script
Show the SQL script OR the screen shot for your tables- if you have used GUI - for
each of cases you have shown in the previous chapter ( section 3.3: sequence models)

43

4.3 Building your code
This is your software program, and must be in your project CD)

5 CHAPTER FIVE: TESTING
5.1 Unit Testing
5.1.1Set cases test
You have to show where you used the requirement in your design as well as in your
implementation by conducting a test for the full system and showing the input /
process / output procedures within design and implementation stages)

44

5.2 Integration Testing

5.3 Other testing (optional)
(Performance Testing, Acceptance Testing, GUI Testing,)

6 CONCLUSIONS AND FUTURE WORK
6.1 Conclusion
6.2 Future work

45

References
Use either APA or MLA bibliography style for citation

46

7 Appendices

7.1 Appendix A

Any supporting documents

47

7.2 Appendix B
Any supporting documents

48

Table of Contents
Abstract .......................................................................................................................................... iii
Acknowledgment ........................................................................................................................... iii
Table of Contents ...........................................................................Error! Bookmark not defined.
List of Figures ................................................................................Error! Bookmark not defined.
List of Tables .................................................................................Error! Bookmark not defined.
1 CHAPTER ONE: INTRODUCTION ..................................................................................... 1
1.1 Background ...................................................................................................................... 1
1.2 Literature Review ............................................................................................................. 1
1.3 Business Model ................................................................................................................ 2
1.3.1 Business Needs ......................................................................................................... 2
1.3.2 Business Environment .............................................................................................. 2
1.3.3 Stakeholder Analysis ................................................................................................ 5
1.3.4 System Vision Document ......................................................................................... 5
1.3.5 Project Management ................................................................................................. 6
1.3.6 Development Environment ..................................................................................... 11
2 CHAPTER TWO: REQUIREMENTS ................................................................................. 14
2.1 Gathering Requirements ................................................................................................. 15
2.2 System Problem Statement ............................................................................................ 15
2.3 Functional, Non-Functional Requirements and System Constraints ............................. 15
2.4 System Models ............................................................................................................... 18
2.4.1 Use Case Model ...................................................................................................... 18
2.4.2 Domain Class Model............................................................................................... 20
2.4.3 Use Cases Descriptions "Scenarios" ....................................................................... 22
2.4.4 Activity & System Sequence Models ..................................................................... 38
2.4.5 Statechart Model (optional) .....................................Error! Bookmark not defined.
3 CHAPTER THREE: DESIGN .............................................................................................. 42
3.1 Architecture and Deployment environment Design ....................................................... 42
3.2 Software Architecture Design ........................................................................................ 42
3.3 Sequence Models............................................................................................................ 42
3.4 Design Class Model ....................................................................................................... 43
3.5 Design package model ( optional) .................................................................................. 43
3.6 Design the database ........................................................................................................ 43
3.6.1 Design Entity-Relationship Model ......................................................................... 43

49

3.7 Design the system and user interfaces............................................................................ 43
3.8 Design the system security ............................................................................................. 43
4 CHAPTER FOUR: IMPLEMENTATION ........................................................................... 43
4.1 Generate Design class model to specific programming language syntax ...................... 43
4.2 Generate Entity-Relationship model to SQL script........................................................ 43
4.3 Building your code ......................................................................................................... 44
5 CHAPTER FIVE: TESTING ................................................................................................ 44
5.1 Unit Testing .................................................................................................................... 44
5.1.1 Set cases test ........................................................................................................... 44
5.2 Integration Testing ......................................................................................................... 45
5.3 Other Testing( optional) ................................................................................................. 45
6 CONCLUSIONS AND FUTURE WORK ........................................................................... 45
6.1 Conclusion...................................................................................................................... 45
6.2 Future work .................................................................................................................... 45
References ..................................................................................................................................... 46
7 Appendices ............................................................................................................................ 47
7.1 Appendix A .................................................................................................................... 47
7.2 Appendix B .................................................................................................................... 48

50

G7 patient record system

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to G7 patient record system

Similar to G7 patient record system (20)

Recently uploaded

Recently uploaded (20)

G7 patient record system