CHAPTER THREE

ANALYSIS
3.1. DATA ANALYSIS
Requirements analysis is an important phase in a software development process. The
quality of software delivered often depends on how well the activities of this phase are
carried out. It involves identifying and eliciting, describing and specifying and
validating system requirements. Another important aspect of this phase of the software
development project is the identification of people who will use the system and what
their roles will be.

3.1.1. CURRENT SYSTEM ANALYSIS

Question 1 What is your gender?

Objective This question aims to know how many the respondents who participate to
answer the questions.
Tabulation

Frequency Percent Valid

Percent
Male 35 58 58
Female 25 42 42
Total 60 100.0 100.0
Chart

42%
58%

male
female

Observation In the first question, the result that indicate majority of the respondents
are male than female
Question 2 Which is your age?

Objective This question aims to find out who many among the elders and young
people will answer the questions
Tabulation

Chart

Observation The most of respondents age range between 18-25years

Question 3 What is your education level

Objective This question aims to know the education level of respondent

Tabulation

Frequency Percent Valid

Percent
PhD 0 0 0
Masters 6 28 28
Degree 30 53 53
Diploma 16 10 10
Certificate 5 9 9
None of the 0 0 0
above
Total 60 100 100

Chart

Observatio The result show that majorities of degree appear more than other education
level.
n
Question 4 Have you ever heard about Online Ship or Ferry Ticket Reservation System?

Objective To know how many respondents have ever heard about Online Ship or Ferry
Ticket Reservation System

Tabulation

Chart

23%

Observatio The result shows that the most of the respondents have heard about Online Ship
or Ferry Ticket Reservation System
n
Question 5 How do you consider your experience in using the Online Ship or Ferry Ticket
Reservation System you have used?

Objective To know the experience of respondents’ experience in using the Online Ship or
Ferry Ticket Reservation System

Tabulation

Chart

8%

42%

50%

Observatio Many respondent consider the Online Ship or Ferry Ticket Reservation System
as a normal experience.
n
3.2. SEQUENCE DIAGRAM OF PROPOSED SYSTEM
3.3. USE CASE ANALYSIS
A use case is a list of actions or event steps typically defining the interactions between
a role (known in the Unified Modeling Language (UML) as an actor) and a system to
achieve a goal. The actor can be a human or other external system. In systems
engineering, use cases are used at a higher level than within software engineering,
often representing missions or stakeholder goals. The detailed requirements may then
be captured in the Systems Modeling Language (SysML) or as contractual statements.

It is also called behavioral UML diagram. It gives a graphic over-view of the

actors involved in a system directly. It shows how different functions needed by
the actors how they are interacted.

Below is the “USE CASE DIAGRAM” of the new proposed system.

3.4. DESIGN
3.4.1. CONTEXT DIAGRAM
According to Chris Adams (2012) the Context Diagram shows the system under
consideration as a single high-level process and then shows the relationship that
the system has with other external entities (systems, organizational groups,
external data stores, etc.).
Another name for a Context Diagram is a Context-Level Data-Flow Diagram or
a Level-0 Data Flow Diagram. Since a Context Diagram is a specialized version
of Data-Flow Diagram, understanding a bit about Data-Flow Diagrams can be
helpful.
3.4.2. ENTITY RELATIONSHIP DIAGRAM
According to Jacqueline Biscobing, (2009) an entity relationship diagram (ERD),
also known as an entity relationship model, is a graphical representation that
depicts relationships among people, objects, places, concepts or events within an
information technology (IT) system. An ERD uses data modeling techniques that
can help define business processes and serve as the foundation for a relational
database.
3.5. FUNCTIONAL REQUIREMENTS SPECIFICATION

 Sell tickets for trips on specific dates and times.

 Passenger tracking by name (to allow for accurate passenger manifests)

 Passenger check-in at time of boarding (scanning tickets).

 Real-time vessel occupancy when selling tickets and while boarding.

 Sell tickets for cargo (accompanied and unaccompanied).

 System configuration to allow for route scheduling, vessel assignment, max

seating capacity, ticket fares etc.

 The system will be designed for the sale of ferry tickets only (i.e. no food or

beverage items).

 Extensive reporting and the ability to create custom reports using industry

standard reporting tools.

3.6. REQUIREMENT DETERMINATION
3.6.1. FUNCTIONAL REQUIREMENTS OF PROPOSED SYSTEM
I. Route This is the combination of a departure point and a destination. For

example, “Provo – North”, “North – Provo”, or “Provo – South”. That is,

the route is something you could draw as an arrow on a map.

II. Run This is a regularly scheduled trip of a vessel on a specific Route at a

specific time. For example, there will always be a 6:30am Run on the

Provo-North Route on Wednesdays.

III. Leg This represents the actual sailing of a Vessel on a specific Route, Date

and Time. It is against a Leg that Tickets can be sold. A passenger manifest

will be available for any Leg.

3.6.2. NON FUNCTIONAL REQUIREMENTS OF PROPOSED SYSTEM

I. Usability. This measures characteristics such as consistency and aesthetics

in the user interface. Consistency is the constant use of mechanisms

employed in the user interface while aesthetics refers to the artistic, visual

quality of the user interface. It is the ease at which the users operate the

system and make productive use of it.

II. Reliability. Users have to trust the system even after using it for a long

time. The system should be able to retain data that is used a number of

years without the data being changed by the system. Also, it has to contain

the requirements that will make it easier to monitor the system

performance.

III. Performance. The system has to meet the agreed response time

performance targets. What should system response times be, as measured

from any point, under what circumstances?

Are there specific peak times when the load on the system will be

unusually high? All these have to be made sure they reach the agreed

measurements.