MALAYSIAN INSTITUTE OF INFORMATION TECHNOLOGY

JULY 2020 SEMESTER

IEB20703 OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN

PROJECT
SYSTEM EASYGUARD

PREPARED BY:

NO. NAME STUDENT ID NO.

1. SYAZA NADHIRAH BINTI MOHAMAD SOLLEH 52213219121
2. NUR ALIA HUSNINA BINTI MOHD FATHIL 52218219095
3. NOR DALILA BINTI MOHD TAIB 52213219068
4. FATIN NABILA BINTI JALIL 52218219011
5. MUHAMMAD SYAFIQ BIN KAMARUL BAHARI 52218118531

PREPARED FOR:
MADAM WAN HAZIMAH BINTI WAN ISMAIL
Table of content
1. Information Gathering .................................................................
a. Gather detailed information about the system:
1.1 Current problem domain
1.2 Fact-findings
1.3 Observation
1.4 Interview

b. Review, analyze and structure the information gathered

c. Non-functional requirement:

2. Modeling ................…....................................................................

3. General Constraints .....................................................................

Information Gathering
a. Gather detailed information about the system:

Current problem domain:

To overcome traditional way which most residence area had to use books to records visitor’s
information and to overcome unorganized personal visitor’s data. Next is to emphasize the use
of technology among residence. At the same time, to secure visitor’s personal stuffs such as
identification card and license since the traditional way needs visitor to leave their personal
stuffs to guards in order to visit the residence. This traditional way sometimes led to unexpected
event such as guard misplaced or lost the visitor identification card or license card.

What is fact-findings?

As for the Easy Guard System, the technique that have been used is observation and
interview.

Observation

Management join to observe the situation based on the traditional ways which is guard need to
register all the visitor and at the same time they need to keep an eye on the residential area.
The management found out that the traditional way sometimes a bit difficult for the guard
because of limited workforce and time. At certain time, the number of visitors increase and it is
hard for the guard to keep track what did the visitors do (drop off, pickup, overnight or delivery).
The other problem is management discover that visitor’s information is not secure due visitors
need to left license or identification card to the guard in order to enter the residential area.
Sometimes it led to unexpected event such as guard misplaced or lost the visitor identification
card or license card.
Interview

The interview method is used to gather all the information from the residence about what do
they think about the old system which is, the traditional way. The traditional way causes so
many problems towards the residence. Most of them said, that their parking lot was always
been blocked or doubled park by the visitors. Both the guards and the residence cannot do
anything besides wait for the visitors to finish their business and move their car out of the way
since there is no contact number was left by the visitors. People also complained that when they
went out, their parking lot was frequently taken by the visitors too. Many of the guards cannot do
much next but listen to the residence nagging to them.

b. Review, analyze and structure the information gathered to develop and overall
understanding of the new system’s functional requirements (activities that the new
system must perform).

1. The visitor registration should be using owner account.

2. The system should be able to record the registry information about the owner.

3. The system should be able to record the history of the owner at the residential area.

4. The system should allow the owner to share the QR Code for their visitor.

5. The system cannot associate one account with multiple users.

c. Non-functional requirement:

a. Reliablity

The system will consistently perform its intended function. This also specifies the factors
required to establish the required reliabilty of the software system at time of delivery.

b. Reusability

The system can be reused in any organization or site of the same group, by defining the
organization master definition under software licenses agreement.
 c. Efficiency

Unnecessary data will not be transmitted on the network and database server will be property
connected.

d. Availability

The system may be available for the whole time, the maintenance process may not take a long
period of time.

e. Integrity

Only System Administrator has rights to access the database, not every user can access all the
information. Each user will be having rights to access the modules.

f. User friendliness

The system is easy to learn and understand. A native user can also use the system effectively,
without any difficulties.

g. Standards compliance

There shall be consistency in variable names within the system. The graphical user interface is
designed to have consistency look and feel.
Modelling
Functional Modeling
2.1 Use Case Diagram
 2.1.1 Use Case Description

Use case name: Create Resident account

Scenario: Create Resident account in application
Triggering event: New Resident wants to set up account in application
Brief description: Resident creates Residence account in application by entering
basic information and then following up with house unit number.
Actors: Resident
Related use cases:
Stakeholders: Administration
Preconditions: Resident house unit number must be authorized by the
Administration
Postconditions: Resident must be created and saved.
House unit number information must be validated.
Account must be created and saved.
House unit number and Account must be associated with
Resident.
Flow of activities: Actor System
1. Resident needs to create 1.1 System creates a new
residence account in order to resident.
use the apps. 1.2 System prompts for
resident basic information.

2. Resident enters basic resident 2.1 System creates basic

information. information.
2.2 System prompts for house
unit number.

3. Resident enters house unit 3.1 System creates account.

Exception condition:
number. 3.2 System verifies authorization
for house unit number.
3.3 System associate resident,
house unit number and
account.
3.4 System returns valid residence
account details.
1.1 Basic resident data are incomplete.
2.1 The house unit number isn’t valid.
Use case name: View Resident account
Scenario: View Resident account in application
Triggering event: Admin wants to view Resident account
Brief description: Admin wants to view Resident account in order to check
Residence information and Residence house unit number
Actors: Admin
Related use cases: Might be invoked by the Create account use case
Stakeholders: Administration
Preconditions: Resident account must be available.
House unit number list must be available.
Postconditions: Resident account must be created and saved.
Resident account must be validated.
House unit number must be validated.
Flow of activities: Actor System
1. Admin wants to view Resident 1.1 System prompts for house unit
account. number.

2. Admin enter house unit 2.1 Systems validate house unit

number. number.
2.2 System validate Resident
information.
2.3 System return valid Residence
account details.
Exception condition: 1.1 The house unit number isn’t valid.
2.1 The resident information isn’t valid.
Use case name: Login Resident account
Scenario: Login resident account in application
Triggering event: Resident wants to login their account
Brief description: Resident wants to login their resident account in order to use the
application
Actors: Resident
Related use cases: Might be invoked by the Create account use case
Stakeholders: Administration
Preconditions: Resident account must be available.
Postconditions: Resident account must be created and saved.
Resident account must be validated.
House unit number must be validated.
Flow of activities: Actor System
1. Resident wants to login into 1.1 System prompts for email and
their residence account. password.

2. Resident enters email and 2.1 System validate email and

password. password.
2.2 System return valid Residence
account details.
Exception condition: 1.1 Email isn’t valid.
2.1 Password isn’t valid.
Use case name: Register Visitor
Scenario: Register visitor in application
Triggering event: Resident or Admin wants to register visitor in application
Brief description: Resident or Admin registering visitor information in application in
order to let visitor visit the residence area
Actors: Resident, Admin
Related use cases: Might be invoked by the Login Resident account use case
Stakeholders: Administration
Preconditions: House unit number must be available.
Resident must be available.
Postconditions: Resident account must be validated.
House unit number must be validated.
Visitor information must be created and saved.
Visitor information must be validated.
Flow of activities: Actor System
1. Resident or Admin want to 1.1 System prompts visitor
register visitor. information form.

2. Resident or Admin enter 2.1 System validate visitor

visitor information in the information.
form. 2.2 System return valid visitor
information details.
Exception condition: 1.1 Resident did not register the visitor, Admin will register the
visitor.
Use case name: View Visitor
Scenario: View Visitor list in application
Triggering event: Resident and Admin wants to view residence Visitor list in
application
Brief description: Resident and Admin wants to view Residence Visitor list in
application in order to check visitor’s information that coming in
and out from the resident house unit number
Actors: Resident, Admin
Related use cases: Might be invoked by the Register Visitor use case
Stakeholders: Administration
Preconditions: Resident account must be available.
House unit number list must be available.
Visitor information must be available.
Postconditions: Resident account must be created and saved.
Resident account must be validated.
House unit number must be validated.
Visitor information must be validated.
Flow of activities: Actor System
1. Resident and Admin wants to 1.1 System validate resident
view visitor list information. account.
1.2 System prompts house unit
number for Admin.

2. Resident view visitor list 2.1 System return valid visitor

information. information details.

3. Admin enters house unit 3.1 System return valid visitor

number. information details.
Exception condition: 1.1 The house unit number isn’t valid.
Use case name: Make Resident complaint
Scenario: Make resident complaint in the application
Triggering event: Resident wants to make a complaint in the application
Brief description: Resident wants to make a complaint in the application regarding
residential matter
Actors: Resident
Related use cases: Might be invoked by the Login Resident account use case
Stakeholders: Administration
Preconditions: House unit number must be available.
Resident must be available.
Postconditions: House unit number must be validated.
Resident must be validated.
Resident complaint must be created and saved.
House unit number and complaint must be associated with
Resident.
Flow of activities: Actor System
1. Resident wants to make a 1.1 System prompt complaint
complaint in the application. form.

2. Resident make a complaint in 2.1 System validate resident

the form. complaint.
2.2 System return valid resident
complaint details.
Exception condition: 1.1 The house unit number isn’t valid.
Use case name: View Resident complaint
Scenario: View Resident complaint in application
Triggering event: Resident and Admin wants to view Resident complaint in
application
Brief description: Resident and Admin wants to view Resident complaint in
application in order to check and resolve Resident complaint.
Actors: Resident, Admin
Related use cases: Might be invoked by the Make Resident complaint use case
Stakeholders: Administration
Preconditions: Resident account must be available.
House unit number list must be available.
Resident complaint must be available.
Postconditions: House unit number must be validated.
Resident must be validated.
Resident complaint must be validated.
House unit number and complaint must be associated with
Resident.
Flow of activities: Actor Flow of activities:
1. Resident and Admin wants to 1.1 System validate resident
view resident complaint. account.
1.2 System prompts house unit
number for Admin.

2. Resident view resident 2.1 System return valid resident

complaint. complaint details.

3. Admin enters house unit 3.1 System return valid resident

number. complaint details.
Exception condition: 1.1 The house unit number isn’t valid.
Structural Modeling
2.2 Domain Class Diagram
Behavioral Modeling

Create account activity diagram

Register Visitor activity diagram
 Complaint activity diagram

2.3 Activity Diagram

General Constraints

1. Time Constraint
 While planning the goals, equipment or steps to be taken to accomplish this project, we took a
long period of time and faced so many problems.

2. Quality Constraint

 We make too many errors; we took so much time rectifying them.

3. Scope Constraint

 At the beginning, the scope of our project had not been fully defined or understood.