TAJUK

NAMA PELAJAR

FSKTM

UNIVERSITI TUN HUSSEIN ONN MALAYSIA

FSKT M
 UNIVERSITI TUN HUSSEIN ONN MALAYSIA
PENGESAHAN STATUS LAPORAN PROJEK SARJANA MUDA
TAJUK PROJEK
ACADEMIC SESSION: 2015/2016

I, NAME, agree to allow this Undergraduate Project Report to be kept at the Library under the
following terms:
1. This Undergraduate Project Report is the property of the Universiti Tun Hussein Onn
Malaysia.
2. The library has the right to make copies for educational purposes only.
3. The library is allowed to make copies of this report for educational exchange between higher
educational institutions.
4. ** Please Mark (√)
CONFIDENTIAL (Contains information of high security or of great
importance to Malaysia as STIPULATED under the
OFFICIAL SECRET ACT 1972)

RESTRICTED (Contains restricted information as determined by the

Organization/institution where research was conducted)

FREE ACCESS

FSKT M

Approved by,

(WRITER’S SIGNATURE) (SUPERVISOR’S SIGNATURE)

Permanent Address:
NOX, JALAN Y
4, TAMAN Z,
83000 BATU PAHAT,
JOHOR

Date: _________________________ Date: _________________________

Note:
** If this Undergraduate Project Report is classified as CONFIDENTIAL or
RESTRICTED, please attach the letter from the relevant
authority/organization stating reasons and duration for such classifications.
 TITLE

NAME

A project report submitted in partial

fulfilment of the requirement for the award of the
FSKT M

Degree of Bachelorof Computer Science (Software Engineering) with Honours

Fakulti Sains Komputer dan Teknologi Maklumat

Universiti Tun Hussein Onn Malaysia

MAY 2016
 ii

I hereby declare that the work in this project report is my own except for quotations and
summaries which have been duly acknowledged

Student : ......................................................................

NAME

Date : ......................................................................

FSKTM

Supervisor : .....................................................................

NAME
 iii

<DEDICATION TEXT>

FSKTM
 iv

ACKNOWLEDGEMENT

<Text>

FSKTM
 v

ABSTRACT

Text ….

FSKTM
 vi

ABSTRAK

Teks…..

FSKTM
 vii

CONTENTS

TITLE i
DECLARATION ii
DEDICATION iii
ACKNOWLEDGEMENT iv
ABSTRACT v
ABSTRAK vi
CONTENTS vii
LIST OF FIGURES x
LIST OF TABLES xi
LIST OF APPENDIX FSKTM

xii
CHAPTER 1 INTRODUCTION 1
1.1 Project Background 1
1.2 Problem Statement 1
1.3 Objective 1
1.4 Scope 1
1.5 Expected Result 1
1.6 Project Significance 2
1.7 Chapter Summary 2
1.8 Report Organization 2
CHAPTER 2 LITERATURE REVIEW 3
2.1 <Related Concepts to your systems> 3
2.2 <Related Concepts to your systems> 3
2.3 <Related Concepts to your systems> 4
2.4 <Related Concepts to your systems> 4
2.5 Study of <Current process of your title> 4
 viii

2.6 Study of Existing Related Systems 4

2.6.1 <Name of System 1, Sistem E-Klinik Panel SIRIM Berhad> 5
2.6.2 <Name of System 2, C-MagSys: Clinic Management System> 5
2.6.3 <Name of System 3,Sistem E-Klinik Panel USM> 5
2.7 Comparison with the Existing Systems 5
2.8 Chapter Summary 6
CHAPTER 3 METHODOLOGY 7
3.1 Prototyping Model 7
3.1.1 Planning Phase 7
3.1.2 Analysis Phase 7
3.1.3 Design Phase 8
3.1.4 Implementation Phase 8
3.1.5 Testing Phase 8
3.2 System Development Workflow 8
3.3 Chapter Summary 9
CHAPTER 4 ANALYSIS AND DESIGN 10
4.1 System Requirement Analysis
FSKTM

10
4.1.1 DFD Context Diagram (DFD CD) Error! Bookmark not
defined.
4.1.2 DFD Level 0 Error! Bookmark not defined.
4.1.3 Requirement Traceability Matrix 12
4.1.4 Entity Relationship Diagram 13
4.2 Design 13
4.2.1 Interface Design 13
4.2.2 Schema Table 15
4.3 Chapter Summary 16
CHAPTER 5 IMPLEMENTATION AND TESTING 17
5.1 Implementation 17
5.1.1 Create Medical Form Interfaces 17
5.1.2 Manage Users Details Interfaces 17
5.1.3 Manage Patients Details Interfaces 18
5.2 Testing 18
5.2.1 Test Cases 18
 ix

5.2.2 Test Case Result of Create Medical Form 19

5.2.3 Test Case Result of Manage Users Details 19
5.2.4 Overall Result 19
5.3 Chapter Summary 19
CHAPTER 6 CONCLUSION 20
6.1 System Advantages 20
6.2 System Disadvantages 20
6.3 Recommendations 20
6.4 Summary 21
REFERENCES 22
APPENDIX 23
VITA

FSKTM
 LIST OF FIGURES

4.1 Data Flow Diagram Context Diagram (DFD CD) 10

4.2 Data Flow Diagram Level 0 (DFD 0) Error! Bookmark not defined.
4.3 Login interface (Process Create Medical Form) 14

FSKTM
 LIST OF TABLES

3.1 Software development activities and their task 8

4.1 Requirements traceability matrix 12
4.2 User table 15
5.1 List of test cases 18

FSKTM
LIST OF APPENDIX

FSKTM
 1 CHAPTER 1

INTRODUCTION

1.1 Project Background

<Text>

1.2 Problem Statement

FSKTM

<Text>

1.3 Objective

<Text>

1.4 Scope

<Text>

1.5 Expected Result

<Text>
1.6 Project Significance

<Text>

1.7 Chapter Summary

<Text>

1.8 Report Organization

<Text>

FSKTM
 2 CHAPTER 2

LITERATURE REVIEW

<Intro>This chapter will discuss on literature review that had been done for the system
and the current system that being used by the clinic. Section 2.1 will discuss about the
management system. Then, in Section 2.2 will discuss about the patient management and
in Section 2.3 will discuss about the inventory management. Moreover, the technology
that used in the system will be discussed further in Section 2.4. Besides that, three types
of existing system had been study and compared with the developed system in Section
FSKTM

2.5. Finally, the summary of this chapter was explained in Section 2.7.

2.1 <Related Concepts to your systems>

<Text consists of>

<What is><What are common features?><How the features relate to your
project>
<A statement that link to the following section>

2.2 <Related Concepts to your systems>

<Text consists of>

<What is><What are common features?><How the features relate to your
project>
<A statement that link to the following section>

2.3 <Related Concepts to your systems>

<Text consists of>

<What is><What are common features?><How the features relate to your
project>
<A statement that link to the following section>

2.4 <Related Concepts to your systems>

<Text consists of>

<What is><What are common features?><How the features relate to your
project>
<A statement that link to the following section>
FSKTM

2.5 Study of <Current process of your title>

<Text>
<Followed by flow chart(s)/ business model (as-is model)/ activity diagram(s) of
current process>
<If there are hard copy forms/ reports that referred by your text, please include as
an attachment>
<A statement that link to the following section>

2.6 Study of Existing Related Systems

<Text>
2.6.1 <Name of System 1,Sistem E-Klinik Panel SIRIM Berhad>

<What are the functions offered by System 1? Recall the functions that relate to your
proposed/ developed system>
<How they (the functions) relate to your system?
<What are (1) advantages of System 1 that can be/ will be/ were applied to your
proposed/ developed system (2)extended/ modified functions?>

2.6.2 <Name of System 2, C-MagSys: Clinic Management System>

<What are the functions offered by System 2? Recall the functions that relate to your
proposed/ developed system>
<How they (the functions) relate to your system?
<What are (1) advantages of System 2 that can be/ will be/ were applied to your
FSKTM

proposed/ developed system (2)extended/ modified functions?>

2.6.3 <Name of System 3,Sistem E-Klinik Panel USM>

<What are the functions offered by System 2? Recall the functions that relate to your
proposed/ developed system>
<How they (the functions) relate to your system?
<What are (1) advantages of System 2 that can be/ will be/ were applied to your
proposed/ developed system (2)extended/ modified functions?>

2.7 Comparison with the Existing Systems

<Statement that summarize features in existing systems and proposed system>

<Depicts the summarization in a Table>
 Features/System Name of System Name of System Name of System Name of
1 2 3 Proposed System
Log Masuk √ user id and √ thumb print √ √
psswd
Process Order √ X √ √
List of main
processes/ features.
Tally with scope/
process/ use case
and their
techniques

<A statement that summarize your findings>

2.8 Chapter Summary

<Text>
<Summarize what have been discussed in Chapter 2>
<A statement that mention on what is the topic for Chapter 3>

FSKTM
 3 CHAPTER 3

METHODOLOGY

This chapter explain the use of prototype model in this project and the activities that had
been carried out in each phase.

3.1 Prototyping Model

<What is Prototyping Model> FSKTM

<Why it is chosen?>
<What are the phases? Support with a figure.>
<A statement that link to the following section>

3.1.1 Planning Phase

<Purpose of this phase><What are sub activities for this phase?><What is/are
technique(s)/ tool(s) used>
<State if there is Appendix that relate to this activity>

3.1.2 Analysis Phase

<Purpose of this phase><What are sub activities for this phase?><What is/are
technique(s)/ tool(s) used>
 <State if there is Appendix that relate to this activity>

3.1.3 Design Phase

<Purpose of this phase><What are sub activities for this phase?><What is/are
technique(s)/ tool(s) used>
<State if there is Appendix that relate to this activity>

3.1.4 Implementation Phase

<Purpose of this phase><What are sub activities for this phase?><What is/are
technique(s)/ tool(s) used>
<State if there is Appendix that relate to this activity>

3.1.5 Testing Phase

FSKTM

<Purpose of this phase><What are sub activities for this phase?><What is/are
technique(s)/ tool(s) used>
<State if there is Appendix that relate to this activity>

3.2 System Development Workflow

There are total of nine phases from the prototype model. As shown in Table 3.1, each phase
has its own assignment and output that need to produce during the entire project
development. Besides that, the output had been completed within the specific days that have
been given.

Table 3.1: Software development activities and their task

Phase Task Output
Planning Proposed the project Project proposal
Determine the project Develop Gantt chart
schedule, activities and
output
Analysis

3.3 Chapter Summary

<Text>
<Summarize what have been discussed in Chapter 3>

FSKTM
 4 CHAPTER 4

ANALYSIS AND DESIGN

4.1 System Requirement Analysis

<text>

4.1.1 Use Case Diagram

FSKTM

<text>
<Use Case Diagram>

Figure 4.1: Use case diagram for <Name of system>

<text>

4.1.2 Use Case Specification

<text>

4.1.2.1 Use Case Create Medical Form (SRS_REQ_100)

<text- overview of Create Medical Form>. <Use case specification attached in

Appendixn>

FSKTM

Figure 4.2: Use case Create Medical Form

4.1.2.2 Use CaseManage Users Details (SRS_REQ_200)

<text- overview of Manage Users Details >. <Use case specification attached
in Appendixn>
4.1.2.3 Use Case<name of use case> (SRS_REQ_n00)

<text- overview of the use case>. <Use case specification attached in Appendixn>

4.1.3 Requirement Traceability Matrix

Based on the process specification in 4.1.2, the requirements of this system were listed in
Table 4.1.

Table 4.1: Requirements traceability matrix

Allocated Descriptions
REQ_100 << Use Case Name 1>>
FR01-01 The system shall be able to show asset registration form to BSI Unit.
FR01-02 The system shall get the next available tracking number.
FR01-03 The system should display the details of the asset to BSI Unit.
FR01-04 The system shall save details of the new asset.
FR01-05 The system shall be able to handle exceptions.
FR01-06 The system shall provide BSI Unit with the ability to enter details of the new
FSKTM

asset.
CR01-01 The system shall not allow BSI Unit to change tracking number.
CR01-02 While tracking number is full. The system will not save the new asset data.
CR01-03 The system shall not allow BSI Unit to submit asset registration form if the form
is incomplete.
QR01-01 While exception occurs. The system shall return to previous state.
QR01-02 The system shall be able to inform BSI Unit for a sustained period of time every
5 minutes.
REQ_n00 << Use Case Name n>>
4.1.4 Class Diagram

<text>
<Class diagram>

Figure 4.3: Class diagram

<text>

4.2 Design

<text: Example: After all the users requirements were successfully analyze, the project will
FSKTM

proceed in design phase. In this phase, both interface and database had been designed in
order to help visualize the system before proceed with the coding the system.>

4.2.1 Interface Design

<text: Example: The following are the interfaces that have been designed based on each
process in Figure 4.2. They are designed by using Macromedia Dreamweaver 2010.>

4.2.1.1 Create Medical FormInterfaces

<text: Example: In this process, User need to log into system by providing the correct
username and password by using login interface as shown in Figure 4.10. The system will
then validate the username and password. If both username and password are correct, the
system will redirect User to the main page. If one of the username or password is incorrect,
the system will automatically display an error message. After that, the system will request
User to re-enter the correct username and password. >

Figure 4.4: Login interface (Process Create Medical Form)

<text: Example: After successfully log in, the system will display the main menu
interface as shown in Figure 4.11. The Current Patient group box will display all patients
name that still not received any treatment from the doctor. In addition, Doctor will select the
FSKTM

patient name from the list box and clicking Select Current Patient button that will display the
medical form interface that will be used by Doctor to enter all the treatment information that
the patients received.
However, the Treated Patient group box will list all patients name that have already
been treated. Moreover, the assistants will select from list box given and click Select Treated
Patient button and this will open the medical form interface for patient that have already
been treated.>

4.2.1.2 Manage User interfaces

<text>

<figure>

<text>

<figure>

Note: A process/ use case should have more than one interface
4.2.1.3 <name of use case>interfaces

<text>

<figure>

<text>

<figure>

4.2.2 DataDictionary/ Schema Table

<text: Example: The following are the tables from the database that have been designed
and extracted from the class diagram. They were created using Microsoft SQL Server 2014.
>

4.2.2.1 UserTable

<text: Example: User table as shown in Table 4.2 was used to store all the users’
FSKTM

information includes IC number, name, address and salary. The table was implemented in
use case Create Medical Form, Manage Users Details, Manage Patients Details,
Manage Patients Records and Manage Inventory. On the other hand, EMP_IC_NO
was used as a primary key and to identify the specific user’s information. >

Table 4.2: User table

Attributes Data Type Size Key Descriptions
EMP_ADDRESS VARCHAR 50 None User full
address
EMP_POST_CODE BIGINT -2^63 None User post
code
EMP_CITY VARCHAR 50 None User city
EMP_STATE VARCHAR 50 None User state
EMP_HP_NO_1 VARCHAR 50 None User
mobile
phone 1
EMP_HP_NO_2 VARCHAR 50 None User
mobile
phone 2
EMP_HOME_NO VARCHAR 50 None User home
phone
EMP_SALARY DECIMAL 18, 2 None User
 monthly
salary
EMP_ATTRIBUTES VARCHAR 50 None User
attributes/roles
EMP_USERNAME VARCHAR 50 None Username
EMP_DATE_ADD DATE Date None Added date
EMP_DATE_UPDATE DATE Date None Updated date

4.3 Chapter Summary

<text>

FSKTM
 5 CHAPTER 5

IMPLEMENTATION AND TESTING

5.1 Implementation

<text>

5.1.1 Create Medical FormInterfaces

FSKTM

<text>
<Create Medical FormInterfaces>

<text>
<Create Medical Formcode segment>

Note: A process/ use case should have more than one interface

5.1.2 Manage Users Details Interfaces

<text>
<Manage Users DetailsInterfaces>

<text>
<Manage Users Details code segment>
5.1.3 Manage Patients Details Interfaces

<text>
<Manage Patients DetailsInterfaces>

<text>
<Manage Patients Detailscode segment>

5.2 Testing

<text>

5.2.1 Test Cases

<text><Details for each use case in Appendix>

Table 5.1: List of test cases
FSKTM

No. Test Cases Description

TEST_100
1. TEST_100_001 Launch the VMCS Customer panel and press drink brand
that the quantity is not equal to 0 in drink container
(drinks.txt file).
2. TEST_100_002 Launch the VMCS Customer panel and press drink brand
that the quantity is equal to 0 in drink container (drinks.txt
file).
3. TEST_100_003 Launch the VMCS Customer panel, press drink brand and
then insert coins. Accumulated coins will display next to
“Total Money Inserted” caption.
4. TEST_100_004 Launch the VMCS Customer panel, press drink brand and
then insert coins. The coins will update coins denominator.
5. TEST_100_005 The system will check between payment and price, and
Return the change if payment exceed.
6. TEST_100_006 The system will dispense selected drink by a customer after
payment is exceeded.
7. TEST_100_007 Launch the VMCS Customer panel, press drink brand, insert
coins then press Cancel button. Coins are returned.
8. TEST_100_008 The box “Coins not Valid” will flash if invalid coins are
input.
9. TEST_100_009 When maintainer doing his/ her operation, customer
transaction will be terminated and money will be refunded.
TEST_200
1.
2.
5.2.2 Test Case Result of Create Medical Form

<text>
<a pie chart indicates % of pass and fail for Create Medical Form>
<text>

5.2.3 Test Case Result ofManage Users Details

<text>
<a pie chart indicates % of pass and fail for Manage Users Details>
<text>

5.2.4 Overall Result

<text>
FSKTM

<a pie chart indicates overall % of pass and fail>

<text>

5.3 Chapter Summary

<text>
 6 CHAPTER 6

CONCLUSION

<Text>
.

6.1 System Advantages

<Text>
i. <Advantages 1> FSKTM

ii. <Advantages 2>

iii. <Advantages n>

6.2 System Disadvantages

<Text>
i. <Disadvantages1>
ii. <Disadvantages2>
iii. <Disadvantagesn>

6.3 Recommendations

<Text>
i. <Recommendation1>
ii. <Recommendation2>
iii. <Recommendationn>
6.4 Summary

<Text>

FSKTM
REFERENCES

FSKTM
 APPENDIX n (Use Case Specification.

n.1 Use Case Specification for Register New Assets

History Log 1.0.0 1. Create initial use case

1.0.1 1. Fixed alternative flow in normal flow
2. Changed ID for alternative flow and
exceptions.
3. Changed preconditions.
2.0.0 1. Added history log.
2. Version control is applied.
3. Functional requirements are added
4. Constraints are added.
5. Quality requirements are added.
Version 2.0.0
Use Case ID UC-1 FSKTM

Use Case Name Register New Assets

Created By Noraini Ibrahim Updated By Noraini Ibrahim
Date Created 19 September Last Revision 19 November
2016 Date 2016
Actors BSI Unit
Description A BSI Unit accesses the inventory system to enter details
of asset and register the asset in inventory system.
Preconditions BSI Unit must login to the system first. The BSI Unit selects
function “add asset”.
Post conditions The new details of asset are successfully saved by the
system.
Normal Flow 1.0 Register new asset
1. Enter the details of assets and select “done” button.
(See A.1)
 2. The system checks the next available tracking number
and assign to the asset.
3. The system displays the tracking number along with the
details that being displayed.
4. The system saves details of the new asset. ( See E.1)
Alternative flow A.1 Cancel register new asset.
1. The transaction is cancelled.
2. Back to main menu.
A.n
1.
n.
Exceptions E.1 Fail to add new asset into system
1. The system informs BSI Unit error occurs and the error
name in adding a new asset.
2. System restarts, use case.
Related ID FSKT M
Requirement Priority
requirement FR01-01 The system shall be able to show Basic
asset registration form to BSI
Unit.
FR01-02 The system shall get the next Excitement
available tracking number.
FR01-03 The system should display the Performance
details of the asset to BSI Unit.
FR01-04 The system shall save details of Basic
the new asset.
FR01-05 The system shall be able to Basic
handle exceptions.
FR01-06 The system shall provide BSI Performance
Unit with the ability to enter
details of the new asset.
CR01-01 The system shall not allow BSI Basic
 Unit to change tracking number.
CR01-02 While tracking number is full. The Basic
system will not save the new
asset data.
CR01-03 The system shall not allow BSI Performance
Unit to submit asset registration
form if the form is incomplete.
QR01-01 While exception occurs. The Performance
system shall return to previous
state.
QR01-02 The system shall be able to Basic
inform BSI Unit for a sustained
period of time every 5 minutes.
Activity Diagram

FSKTM

Figure n.1: <caption>

Sequence Diagram

Figure n.2: <caption>

FSKTM

n.m Use Case Specification for <use case name>

History Log 1.0.0 2. Create initial use case

1.0.1 4. Fixed alternative flow in normal flow
5. Changed ID for alternative flow and
exceptions.
6. Changed preconditions.
2.0.0 6. Added history log.
7. Version control is applied.
8. Functional requirements are added
9. Constraints are added.
10. Quality requirements are added.
Version 2.0.0
Use Case ID UC-1
Use Case Name Register New Assets
Created By Noraini Ibrahim Updated By Noraini Ibrahim
Date Created 19 September Last Revision 19 November
2016 Date 2016
Actors BSI Unit
Description A BSI Unit accesses the inventory system to enter details
of asset and register the asset in inventory system.
Preconditions BSI Unit must login to the system first. The BSI Unit selects
function “add asset”.
Post conditions The new details of asset are successfully saved by the
system.
Normal Flow 1.0 Register new asset
5. Enter the details of assets and select “done” button.
(See A.1)
6. The system checks the next available tracking number
and assign to the asset.
FSKT M

7. The system displays the tracking number along with the

details that being displayed.
8. The system saves details of the new asset. ( See E.1)
Alternative flow A.1 Cancel register new asset.
3. The transaction is cancelled.
4. Back to main menu.
A.n
1.
n.
Exceptions E.1 Fail to add new asset into system
3. The system informs BSI Unit error occurs and the error
name in adding a new asset.
4. System restarts, use case.
Related ID Requirement Priority
requirement FR01-01 The system shall be able to show Basic
 asset registration form to BSI
Unit.
FR01-02 The system shall get the next Excitement
available tracking number.
FR01-03 The system should display the Performance
details of the asset to BSI Unit.
FR01-04 The system shall save details of Basic
the new asset.
FR01-05 The system shall be able to Basic
handle exceptions.
FR01-06 The system shall provide BSI Performance
Unit with the ability to enter
details of the new asset.
CR01-01 The system shall not allow BSI Basic
Unit to change tracking number.
CR01-02 While tracking number is full. The Basic
FSKT M

system will not save the new

asset data.
CR01-03 The system shall not allow BSI Performance
Unit to submit asset registration
form if the form is incomplete.
QR01-01 While exception occurs. The Performance
system shall return to previous
state.
QR01-02 The system shall be able to Basic
inform BSI Unit for a sustained
perio

d of time every 5 minutes.

Activity Diagram

Figure n.k: <caption>

Sequence Diagram FSKTM

Figure n.l: <caption>

FSKTM