A WEB-BASED SYSTEM FOR STADIUM TICKETING

Student ID: 100341

BBIT 4A

An Information System Project proposal submitted to the Faculty of Information

Technology in partial fulfilment of the requirements for the award of the Bachelor’s
Degree in Business Information Technology of
Strathmore University

Faculty of Information Technology

Strathmore University
Nairobi, Kenya
 Declaration
I declare that this work has not been previously submitted and approved for the award of a
Bachelor’s degree by this or any other University. To the best of my knowledge and belief, the
proposal contains no material previously published or written by another person except where
due reference is made in the proposal itself.

Student’s signature:

………………………………….………….. [Signature]

………………………………….………….. [Date]

Approval
The Information System Project proposal was reviewed and approved (for examination) by:

Supervisor’s signature:

………………………………….………….. [Signature]

………………………………….………….. [Date]

ii
 Abstract
The problem identified is the absence of a Stadium ticketing system to assist the clients and
spectators in the process of ticketing. This comes along with problems such as fake tickets,
poor security and overcrowding at the gates. The proposed solution is to develop a web-based
system to help in management of the stadiums during games. The proposed system will have
features such as a log in page, a sign-up page, a home page and a contact us page where the
users can reach out in case of a problem. To avoid fake tickets, the system will have the
purchased tickets sent to the spectators’ emails as soon as the purchase is complete. Thereafter,
during entry into the stadium, the tickets will be verified and the spectators will go in. The
system design approach for this proposed system is Object Oriented Analysis and Design, and
the methodology is Rapid Application Development (RAD); this methodology allows for
feedback from the user. It also allows the system to be developed in modules. The programming
language used is PHP as it is a web-based application system. MySQL has been used for the
database due to its reliable speed and compatibility with web development.

iii
 Table of Contents
Declaration .................................................................................................................................ii
Abstract .................................................................................................................................... iii
List of figures ...........................................................................................................................vii
List of tables........................................................................................................................... viii
List of abbreviations ................................................................................................................. ix
Chapter 1: Introduction ............................................................................................................ 10

1.1 Background .................................................................................................................... 10

1.2 Problem Statement ......................................................................................................... 11
1.3 Aim ................................................................................................................................ 12
1.4 Specific Objectives ........................................................................................................ 12
1.5 Justification .................................................................................................................... 12
1.6 Scope and Limitations.................................................................................................... 12

Chapter 2: Literature Review ................................................................................................... 13

2.1 Introduction .................................................................................................................... 13

2.2 Current ticketing system in Kenya ................................................................................. 13

2.2.1 Challenges experienced with the current ticketing process ............................... 13

2.3 Examples of modern ticketing systems in use worldwide ............................................. 14

2.3.1 Gig event management system .......................................................................... 14

2.3.2 Ticketsasa event management system ............................................................... 15

2.4 Gaps in the existing systems .......................................................................................... 17

2.5 The Proposed System ..................................................................................................... 17
2.6 Conceptual Framework .................................................................................................. 18

Chapter 3: System Development Methodology ....................................................................... 19

3.1 Introduction .................................................................................................................... 19

3.2 System design approach ................................................................................................. 19
3.3 System Development Methodology ............................................................................... 19

3.3.1 Requirements planning ...................................................................................... 20

3.3.2 User design......................................................................................................... 21
3.3.3 Rapid Construction ............................................................................................ 21
3.3.4 Cutover............................................................................................................... 21

iv
 3.4 Application requirements ............................................................................................... 21

3.4.1 Functional requirements..................................................................................... 22

3.4.2 Non-Functional requirements ............................................................................ 22

3.5 Design Diagrams ............................................................................................................ 23

3.5.1 Class diagram ..................................................................................................... 23

3.5.2 Database schema ................................................................................................ 23
3.5.3 Sequence diagram .............................................................................................. 23
3.5.4 Use case diagram ............................................................................................... 23

3.6 Development tools ......................................................................................................... 23

3.7 Domain of execution ...................................................................................................... 23
3.8 Proposed modules and system architecture ................................................................... 23

Chapter 4: System Analysis and Design .................................................................................. 25

4.1 System Analysis ............................................................................................................. 25

4.1.1 Requirements .......................................................................................................... 25

4.2 System Designs .............................................................................................................. 26

4.2.1 Use case diagram ............................................................................................... 26

4.2.2 Class diagram ..................................................................................................... 27
4.2.3 Sequence diagram .............................................................................................. 28
4.2.4: Database Schema ................................................................................................... 29
4.2.5: Entity Relationship Diagram ................................................................................. 30

Chapter 5: System Implementation and Testing. ..................................................................... 31

5.1 Graphical user interface design ................................................................................. 31

5.1.1 Registration page ............................................................................................... 31

5.1.2 Home Page ......................................................................................................... 32
5.1.3 Report generation ............................................................................................... 33
5.1.4 Payment.............................................................................................................. 34
5.1.5 Events page ........................................................................................................ 35

5.2 Testing ....................................................................................................................... 36

5.2.1 Test Environment ............................................................................................... 36

5.2.2 Test Cases .......................................................................................................... 37

v
 5.2.3 Test Results ........................................................................................................ 38

Chapter 6: Conclusion and Recommendations for Future Work ............................................. 39

6.1: Conclusion .................................................................................................................... 39

6.2: Recommendations for Future Work ............................................................................. 39
6.3: Deliverables .................................................................................................................. 40

References ................................................................................................................................ 41
Appendix A: Timeline of activities.......................................................................................... 43

vi
 List of figures

Figure 2.1 home page

Figure 2.2 Home page
Figure 2.3 Ticket verification page
Figure 2.4 Conceptual Framework
Figure 3.1 Rapid application development
Figure 3.2 Gantt Chart

vii
 List of tables
Table 5.1 Server-side specifications
Table 5.2 Test Cases
Table 5.3 Test Results

viii
 List of abbreviations
GUI – Graphical User Interface
IDE – Integrated development environment
OOAD – Object Oriented Analysis and Design
PHP – Hypertext Preprocessor
RAD – Rapid application development
SSAD – Structured system analysis and design
SQL – Structured query language

ix
 Chapter 1: Introduction
1.1 Background
A stadium is a venue for outdoor sports, or other events and has a field or stage surrounded by
seats or structures made to look like seats to allow spectators to sit and view the event. (Sports
venue. n.d.)
The first stadium originated in the VIII century BC in Greece. (Spampinato, 2006). According
to Spampinato, it was based on an athletic track shaped as an elongated “U”. It had a 192 m
long and 32 m wide track. The starting and finish line were on two ends. This stadium had the
capacity of 45000 spectators. This stadium was mainly for athletic activities due to its
architecture. As sports became more popular, stadia were built in many Greek towns alongside
with hippodromes. These had similar characteristics and dimensions but they were used for
horse and chariot racing. These sports facilities soon started to play key roles within the "polis".
There are still vestiges in Delphi, Ephesus and most of all in Athens, where in 331 BC
Panathenaic stadium was built. It was then rebuilt for the first modern Olympic Games of 1896
and was recently renovated for the Olympic Games of Athens 2004.
In Kenya, the first stadium to be constructed was the City Stadium which was constructed in
the 1930s and was first known as African Stadium. (Kiruga, 2013). Other major stadia were
built in the 1980s including Nyayo and Moi International Sports Centre Kasarani. Nyayo
stadium has a capacity of 30,000 while Kasarani has a capacity of 60,000 people.
There is currently a total of 28 stadia in the country which offer both track and pitch activities
such as athletics and football. The stadia are also used for events that are not sports oriented.
An example is the matter heart run which is a charity walk that is done to help children with
heart problems.
Since the opening of the first stadium in Kenya in the 1930s, there has never been an automated
system in place to deal with the issue of ticketing to ensure smooth running of activities during
games. (Atingo, n.d.).
The current body in charge of managing stadia in Kenya is Sports Kenya. It is a state
corporation established by the Sports Act, 2013 and given the responsibility to carry out
functions formally performed by Sports Stadia Management Board and the Department of
Sports.
The system in Kenya is manual which has not been efficient. Cases of overcrowding at the
gates where the tickets are issued have been reported. This overwhelms the limited number of
security officials which in turn leads to chaos.

10
According to Nyende (2011), Gor Mahia football club lost its Super Sport Limited sponsorship
which terminated live broadcast of matches involving Gor Mahia football club over safety
concerns, citing the incident of 23rd October 2010, where five Kenyan fans were trampled to
death and tens injured in a stampede as the venue (Nyayo National Stadium) and security got
overwhelmed by a near-capacity turnout. This also led to banning the venue from hosting future
events by Federation of International Football Association (FIFA).
Cases of fraud are also witnessed where some spectators come into the stadium and fail to pay
for their tickets due to their relationship with the officials at the ticketing station.
In 2014, Gor Mahia Chairman Ambrose Rachier cancelled Moi Stadium, Kisumu as a home
venue for the club, citing low gate collection returns due to fraud. (Okello, 2015)
With the rapid increase of leagues in the country, it is time to introduce an automated system
which will be able to generate and deliver electronic tickets to its users who are in this case
both Sports Kenya and the spectators.

1.2 Problem Statement

There is a rapid increase of leagues in the country which has made it difficult for stadia to
manage the crowds that come to spectate. Nyende (2011)
The problem identified is the absence of a Stadium ticketing system to assist the clients and
spectators in the process of ticketing. This comes along with problems such as fake tickets and
mix-up of seat numbers hence causing great confusion. This problem makes some of the fans
opt to stay in their homes and watch the games from the televisions.
The current system is manual and it lacks transparency. The system is susceptible to fake
ticketing and the issue of corruption where the officials at the gate allow their friends to access
the games without tickets.
Therefore, there is need for an information web-based system to help curb all this and make it
easy for both the Sports Kenya board and the spectators as tickets will be purchased and issued
online. This way, acquiring tickets for the spectators will be easy and management of the
stadium facilities will be improved.

11
1.3 Aim
The proposed solution is to develop a system to help in management of the stadia during games.
The proposed system will have features such as a log in page, a sign-up page, a home page and
a contact us page where the users can reach out in case of a problem. The system will aim to
give a unique seat number to each spectator in order to prevent confusion like the manual
system.

1.4 Specific Objectives

(i). To evaluate the problems facing the stadium ticketing process
(ii).To analyse the requirements for developing the proposed system.
(iii). To design and develop a web-based system to facilitate electronic ticketing for
spectators entering the stadia.
(iv). To test the developed system in order to ensure all proposed functions were met.

1.5 Justification
The proposed system will be of great help to the involved parties, both Sports Kenya and the
spectators themselves. The system aims to give a unique seat number to each spectator in order
to prevent confusion like the manual system. To avoid fake tickets, the system ensures the
purchased tickets are available on the reserved tickets tab as soon as the purchase is complete.
Thereafter, during entry into the stadium, the tickets will then be verified and the spectators
will go in.

1.6 Scope and Limitations

The web-based system allows the games organisers to add games and remove. This in turn
allows the spectators to select the games they would wish to attend. In order to have access to
the tickets, the users are required to sign up. This includes providing their full name, email
address, phone number and a password for their account. The system allows the users to
purchase the available tickets after signing up. After the purchase has been confirmed, the users
will receive an email with their ticket attached to it.
However, the system is only limited to Kenya and is not for use in other countries.

12
 Chapter 2: Literature Review
2.1 Introduction
This chapter aims at analysing the current situation in the ticketing sector and identifying the
challenges facing the ticketing process and their attempted solutions
In this literature review the focus is on the different ticket issuing systems that are currently in
place and the challenges that affect those systems.

2.2 Current ticketing system in Kenya

In Kenya, the system in place is manual. The tickets are printed and sold to the spectators at
the gates before every match. The price of the tickets may vary depending on the game that is
being played.
Sports Kenya faces problems such as fake tickets, poor security and mix-up of seat numbers
which causes great confusion. Fake tickets come about when malicious people decide to make
their own tickets and sell them to the public at a lower price. According to Lawrence, (2016)
the concept of cheaper tickets attracts most of the spectators and they end up buying fake
tickets.

2.2.1 Challenges experienced with the current ticketing process

Loss making due to fake Tickets. In 2016, during an interview, Football Kenya Federation
President outlined that they had established that a loss was made during a game between Kenya
and Guinea Bissau. This was attributed to fake tickets. (Mwendwa,2016)
The issue of corruption comes about when the officials at the ticketing booths allow some
spectators to attend the matches without paying.
In 2014, Gor Mahia Chairman Ambrose Rachier said they experienced low gate collection
returns due to fraud. (Okello, 2015)
The manual process is slow and it tends to cause long queues. This brings about overcrowding
at the gates which overwhelms the security personnel stationed there.
On 23rd October 2010, five Kenyan fans were trampled to death and tens injured in a stampede
at the Nyayo National Stadium. The security got overwhelmed by a near-capacity turnout.
Nyende (2011)

13
2.3 Examples of modern ticketing systems in use worldwide
2.3.1 Gig event management system

Gig provides event organizers with a simple way of engaging attendees and getting insights
from any kind of event such as Meet-Ups, Expos, Corporate Events, Concerts, Activations or
Fashion Events.
This system requires a user to create an account which has to be verified. After verification,
the user can go ahead and see the available events and select them. Event organizers can also
pay a fee and publish their events on the site after which customers will be able to buy the
tickets.
It offers a wide range of services such as;
RSVP and check-in – This enables users to register and check in for events online. Ticketing
where attendees can purchase event tickets via MPESA or VISA. Event analysis and reports
where the event organisers are able to get instant reports and analysis of attendees such as:
demographics and attendance. Digital event engagement where the organisers can digitally
engage their attendees before, during and after the event. Event feedback which ensures event
organisers are able to get feedback from the event attendees including suggestions for
improvement.

Strengths of Gig event management system

This platform analyses attendee’s demographics and attendance and generates reports of the
analysis after an event. This enables the event organizers in planning for future events to ensure
maximum returns.
This system gives the organizers a platform where they can engage their attendees digitally
during and after the event. This involves sending of emails regarding the event and asking for
feedback after the event.

Weaknesses of Gig event management system

According to the developers, Gig event management system is meant for expos, meet-ups,
concerts and fashion events. It is therefore not suitable for use in the stadium ticketing process
which is the point of focus.

14
Figure 2.1 home page (Gig, 2018)

In this page, the users are able to view the various functionalities and create accounts in order
to use the system.

2.3.2 Ticketsasa event management system

Ticketsasa is a broad system that provides a platform for event organisers to sell their tickets
market their events.
It offers services such as;
Ticketing where attendees can purchase event tickets via Mpesa, Visa, Mastercard and Airtel
money. It has partnerships with various airlines to get the customers affordable tickets for
holidays. Hotel booking where users are able to search for cheap hotels and get good rates to
suit their budget. Ticket verification which allows its users to check the status of their tickets
and verify that they are legitimate.

Strengths of Ticketsasa System

This system has managed to create partnerships with corporates for example airlines and hotels.
This gives the users a wide range of deals which tend to be pocket friendly.
Ticketsasa has a ticket verification module where after the purchase of a ticket, the users can
verify if their tickets are legitimate

15
Weaknesses of Ticketsasa System
The structure of ticketsasa does not suit the stadium ticketing process. Ticketsasa is a broad
system which offers many services but it does not solve the issue of stadium ticketing.

Figure 2.2 Home page (ticketsasa 2018)

Figure 2.3 Ticket verification page (ticketsasa 2018)

On this page, the users get to verify that their purchased tickets are legitimate.

16
2.4 Gaps in the existing systems
The main challenge experienced with the current automated systems mentioned above in
relation to the issue of stadium ticketing is that they do not suit the structure of a stadium. The
systems are not built in a structure that suits the stadiums hence they do not solve the problems
faced by stadiums in Kenya.

The main shortcoming of the manual system is lack of transparency. There is no record keeping
and this does not guarantee accountability. As seen before, cases of corruption, fake tickets and
overcrowding have been reported.

2.5 The Proposed System

The proposed system has a sign-up module to register users into the system, a sign in module
to verify the users’ credentials after signing up, a homepage where the users can view the
available events and navigate to get tickets. It also includes a Contact us module where the user
is able to get in touch with the system managers in case of any clarification or complains.
For payments, the users are able to use Mpesa for secure payment of their tickets. When
spectators buy tickets, the administrators are able to generate a copy of how many tickets have
been bought per game for analytical purposes.

17
2.6 Conceptual Framework

Figure 2.4 Conceptual Framework

The system works in such a way that the user inputs details for registration. The admin has a
different platform from the user as both have different features. The data stored in the database
is the user details and the event details.

18
 Chapter 3: System Development Methodology
3.1 Introduction
This chapter focuses on the methodology that the system uses. The design methodology that
the system follows in relation to how the modules have been developed. It also highlights the
functional and non-functional requirements in the system

3.2 System design approach

The proposed approach for this project is the Object-Oriented Analysis and Design. It is a
procedure of identifying the requirements and developing specifications in accordance to
objects of the system. Its functions and data are modelled after real-world objects that the
system interacts with. It allows the reuse of functions which saves on time and makes the code
more maintainable. When an error occurs, it is easy to rectify as it does not affect the whole
system but rather the module which has the error.
Methods in OOAD allow developers to create a set of objects that work collectively to produce
software that brings out the problem in question as a real-world problem that systems
developed by Structured Systems Analysis and Design (SSAD). Mukherjee (2016).

3.3 System Development Methodology

The project uses Rapid application development (RAD). Morse (2016) describes it as a method
of software development which heavily emphasizes rapid prototyping and iterative delivery. It
is a software development methodology technique used in software application development.
When compared to other software development models, rapid application development varies
by a considerable amount, the major difference is how rapid application development focuses
on speed, when compared to other models which usually focus on bringing a working product
to the customer. Morse (2016)
The advantages of using RAD are, this methodology encourages and prioritises user feedback.
This is a major step in development because the end goal is for the users to benefit from the
system. Requirements of RAD can also be changed at any time hence making it easy for
corrections in case there was an error in the first declaration of requirements.
In RAD the development time is drastically reduced hence giving the developers a short time
to come up with a working system.

19
This methodology uses prototyping techniques and tools to come up with software applications.
It comprises of a graphical user interface (GUI) development environment. This allows the
developers to choose their desired software application components.
One of the disadvantages of RAD is that it needs user requirements at every stage of
development. This requires the developers to keep going back to the users and review their
requirements. Morse (2016).

Figure 3.1: Rapid application development (kissflow, 2019)

3.3.1 Requirements planning

During this stage, the developers and the clients define the goals and expectations for the
project.
The steps in this stage include, researching the current problem that is causing need for a
system, defining the requirements for the project, coming up with each stakeholder’s
conclusion and approval from the parties involved

20
3.3.2 User design
User feedback is gathered with great emphasis on determining the system architecture. This
allows initial modelling and prototypes to be created. This step is repeated as the project
evolves. Prototypes are converted into working models. Developers then gather feedback from
users to tweak and improve prototypes and create the best possible product.

3.3.3 Rapid Construction

Once the basic system and user design has begun, the construction phase follows. This is where
coding, testing and integration takes place. Just as the user design, the rapid construction phase
is repeated when necessary. This is because new components might be required to meet the
end goal of the project.
The steps in this stage include, preparation of necessary tools for construction, system
construction, generation of test data to be used in the system and transition preparation where
stakeholders look into ways of transitioning to the new system.

3.3.4 Cutover
This is the final stage and it gives the developer time to move components to a live production
environment, where testing or team training can take place. This stage includes the finalization
of features, functions and everything else related to the project. Interfaces between various
modules are then tested.
User training is done to familiarise the various users with the functionalities of the system. A
changeover to the new system is then conducted where the old system will be phased out. The
developers will continue to look for bugs while the users report any bugs they come across.

3.4 Application requirements

These include the functional and non- functional requirements for the system. Functional
requirements are the functionalities and services that will be provided by the system for it to
achieve its purpose. Non-functional requirements describe how well the system supports the
functional requirements.

21
3.4.1 Functional requirements
Authentication
There is a login page to ensure that only those who have signed up can get access to the system.

Fans/Customer module
After authentication, the customer then proceeds to a page where the tickets for the various
games are.
In this module, the user should be able to view the list of games which are available. The
customer selects the game of choice and buys the ticket.

Administrator panel/module
There is a panel for the administrator where games will be added for the clients to purchase the
tickets. Only the administrator can update new games. The customers have view only rights.

Payment module
Before the spectators get their tickets, they will be required to pay via Mpesa for purposes of
processing.

Report module
After tickets have been purchased, the administrators will be able to generate a pdf with all the
spectators who attended a particular game for analysis purposes.

3.4.2 Non-Functional requirements

Security
The system should ensure data stored in the database is secure from unauthorized parties.

Usability
The system should be easy for the clients to use.

Reliability
The system should be available at any time to avoid unnecessary inconveniences.
Performance
The system should be able to perform all the tasks it was set to do in the minimum time possible.

22
3.5 Design Diagrams
The following diagrams will be used.

3.5.1 Class diagram

It shows the different objects, their relationship, behaviours, and attributes. (Elgabry, 2017)

3.5.2 Database schema

A database schema is a collection of data that shows the relationship between objects and
information in a database. (Elgabry, 2017)

3.5.3 Sequence diagram

It shows the interactions between the different objects in the system, and between actors and the
objects in a system. (Elgabry, 2017)

3.5.4 Use case diagram

It shows the interaction between a system and its environment (users or systems) within a
particular situation. (Elgabry, 2017)

3.6 Development tools

The IDE used for development was Visual studio as it is a full-fledged environment with
numerous tools. The programming language is PHP as the system is a web application with
Laravel as the framework. MySQL has been used for the database as it offers superior
performance, reliability and greater scalability.

3.7 Domain of execution

The system is web based to make it easy for clients to access the system from any device,
provided they have a browser installed on the device.

3.8 Proposed modules and system architecture

The proposed system comprises of the following modules;

Sign-up module, the user can create an account in order to sign in and get access to the full
functionalities of the system.

23
Sign in module, the user is required to input his credentials as registered in the sign-up module.
The details will be verified and if they match the ones in the database, the user will be granted
access to the system.
Fans/ Customer module, the user is able to view all the events coming up and get access to
the tickets.
Contact us Module, in this module, the user is able to get in touch with the system managers
in case of any clarification or complains.

24
 Chapter 4: System Analysis and Design
4.1 System Analysis
The functional and non-functional requirements are outlined in this chapter
4.1.1 Requirements

Requirement ID Requirement Category Requirement

Description
FRQ1 Functional The system should allow
the user to create an
account
FRQ2 Functional The system should accept
the clients’ credentials.
These include the email,
phone number and name.
FRQ3 Functional The system should also
allow the storage of
records in a database.
FRQ4 Functional The system should sort the
records such that events
that have already
happened are separated
from those that are yet to
take place.
NON-FUNCTIONAL REQUIREMENTS
URQ1 Usability The system should be
secure, all financial
records should be kept
private.
RRQ1 Reliability The system should allow
the users to give feedback
RRQ2 Reliability The system should notify
the admin when a user
contacts them

25
 URQ2 Usability The system should notify
the user of any payments
made.

4.2 System Designs

This section shows the graphical representation of data as it flows in the system in all levels.
4.2.1 Use case diagram

Figure 4.1 Use case diagram

26
 4.2.2 Class diagram

Figure 4.2 Class diagram

27
 4.2.3 Sequence diagram

Figure 4.3 Sequence diagram

28
4.2.4: Database Schema

Figure 4.4 Database schema

29
 4.2.5: Entity Relationship Diagram

Figure 4.5 Entity relationship diagram

30
 Chapter 5: System Implementation and Testing.

5.1 Graphical user interface design

This is the design of the interfaces for the web-based system. For simplicity the interface
involves icons and tabs that make it easier for one to navigate through the system.

5.1.1 Registration page

Figure 5.1 Registration page

31
 5.1.2 Home Page

Figure 5.2 Home page

32
 5.1.3 Report generation

Figure 5.3 Report generation page

This is a simple pdf generation on the admin panel that shows all the customers who
bought tickets of a particular game and how many they bought.

33
 5.1.4 Payment

Figure 5.4 Payment page

34
 5.1.5 Events page

Figure 5.5 Events page

35
5.2 Testing
The tests carried out on the system were;

Module testing: The registration module and payment module were tested independently
to ascertain whether they fulfil their requirements.
System testing: The system was tested to see if it meets the functional and non-functional
requirements.

5.2.1 Test Environment

The following requirements have to be met for the system to work at its best:
a) Server-side specifications.
Operating System Windows 10 64-bit OS

Primary memory 4.00 GB (3.86 usable)

Processor Intel Core i3-6006U CPU

@2.00 GHz
Database management system MySQL Workbench 6.3 CE

Table 5.1 Server-side specifications

b) Client-side requirements
Browser environment: Google Chrome

36
 5.2.2 Test Cases

Test Requirements Inspection Pre-Condition Test data Priority

ID Check level

R1 The system Does the The user must Data from the High
should validate system validate be registered database
login input login input? with the
system

R2 The system Does the The users’ Users’ High

should register system allow personal personal
users users to details are credentials
register? required

R3 Displaying Does the The system The High

games available system display administrator administrator’s
to the users games for the must have
users to select? added all the
games
available
R4 System should Does the The user must Users’ High
allow users make system allow be logged into personal
payments users to make the system details
payments?

Table 5.2 Test Cases

37
 5.2.3 Test Results
Test ID Expected Results Actual Results Status Remarks

R1 The system The system Pass Fast system login

should allow a allows the user
user to log in to log in
R2 The system The system Pass Fast user registration
should register allows users to
users register
R3 The system The system Pass All games are displayed
should display displays games
games available available to the
to users users

R4 The system The system fail Payment methods are

should allow allows users available but require
users to make make payments integration
payments

Table 5.3 Test Results

38
 Chapter 6: Conclusion and Recommendations for Future Work
6.1: Conclusion
The online stadium ticketing System has contributed greatly in solving problems associated
with access to game tickets and mismanagement of funds from the sale of the tickets the system
was also able to get rid of the manual system of cash that was in place before.
The major problem eliminated was the mishandling of tickets at the gate. This has been
eliminated through providing the tickets to the spectators via email after a payment has been
made.
Seat confusion has also been eliminated. The system allocates seat number to a specific ticket
which is given to the users of the system.

6.2: Recommendations for Future Work

Adoption of web application systems is highly recommended as it would reach many users.
However, this system did not fully solve the issues identified hence some things can be
improved in future such as;
i. Notifying both clients and server via email when a payment is successful.
ii. Integrating the system with a universal method of payment such as PayPal.
iii. Expanding the system to be used by other event organizers and not only stadiums.

39
6.3: Deliverables
The following are the modules that were developed at the end of the project;
1. Registration module: The module will be used to register users into the system.
2. Login module: This will be used to authenticate users that have already registered with
the system.
3. Events module: This is where the available events are viewed by the users of the
system for them to choose.
4. Payment module: The system has a provision to integrate with Mpesa as a method of
payment for the tickets.
5. A database of MySQL: this was developed to enable the storage of data that is keyed
into the system.
6. User manual document: This is a document that shows how to use the stadium
ticketing system. This document is to be used mainly by the end users of the system to
assist them in knowing how the system works.

40
 References
Atingo, P. (n.d.). Effects of risk management strategies on triple bottom line of football
events in Nairobi County, Kenya. 103.

Elgabry, O. (2017, October 23). Object-Oriented Analysis And Design - Introduction (Part
1). Retrieved from https://medium.com/omarelgabrys-blog/object-oriented-analysis-and-
design-introduction-part-1-a93b0ca69d36

Kiruga, M. (2013, October 6). Kenya's famous sports stadia. Retrieved from
https://mobile.nation.co.ke/lifestyle/Kenya-famous-sports-stadia/1950774-2020834-format-
xhtml-v29338z/index.html

Lawrence, J. (2016, April 9). Fake ticket cartels raid Football Kenya Federation, pinch cash.
Retrieved from https://www.sde.co.ke/thenairobian/article/2000197646/fake-ticket-cartels-
raid-football-kenya-federation-pinch-cash

Mosman, A. B., Mostafa, S. A., Mustapha, A., Shamsudin, A. U., Ahmed, M., & Hassan, M.
H. (n.d.). An Optimized Method for Automated Stadium Attendance Management System.
International Journal of Engineering, 8.

Mukherjee, M, Object-Oriented Analysis and Design (December 31, 2016). International

Journal of Advanced Engineering and Management Vol. 1, No.1, PP. 1-11, December 2016.
Available at
SSRN: https://ssrn.com/abstract=2905481 or http://dx.doi.org/10.2139/ssrn.2905481

Powell-Morse, A. (2017, November 2). What Is Rapid Application Development (RAD) and
How Do You Use It? Retrieved from https://airbrake.io/blog/sdlc/rapid-application-
development

Nyende, C. Gor Mahia drive on violence wins back Super Sport. Daily Nation, 21st July,
2011, pp. 63

41
Okello, N., & Okello, N. (2019, September 17). Gor Mahia Reveal Reasons for Abandoning
the Moi Stadium Ahead of Chemelil Date. Retrieved from
http://www.sportsplug.co.ke/soccer/gor-mahia-reveal-reasons-for-abandoning-the-moi-
stadium-ahead-of-chemelil-date/

PROTTI, J. (2019). Facility management and stadia: San Siro stadium case.

Sports venue. (n.d.) American Heritage® Dictionary of the English Language, Fifth Edition.
(2011). Retrieved May 20 2020 from https://www.thefreedictionary.com/Sports+venue

42
 Appendix A: Timeline of activities

Figure 3.2 Gantt Chart

43