WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTEMENT OF INFORMATION TECHNOLOGY

PROJECT TITLE: WEB BASED SPORT COMMISSION

MANAGEMENT SYSTEM FOR WOLKITE TOWN

Prepared By:

1. Fasil Desalegn ……..…..NSR/0829/13

2. Haylie Adugna ………...NSR/1116/13

3. Woinshet Gashaw …..…NSR/2141/13

Advisor Name: Mr. Minichil A

January 25, 2024

Wolkite University, Wolkite, Ethiopia

Approval
This is to confirm that the project proposal entitled web-based Sport commission
management system for wolkite town submitted to Wolkite University, College of
Computing and Informatics Department of information technology by:

Name ID Signature

1. Fasil Desalegn NSR/0829/13 …………………

2. Haylie Adugna NSR/1116/13 …………………

3. Woinshet Gashaw NSR/2141/13 …………………

Advisor Name Signature Date

--------------------------------- ------------------------- -----------------------

Department Head Name Signature Date

---------------------------------- ------------------------- -----------------------

Examiner 1 Name Signature Date

--------------------------------- ---------------------------- -----------------------

Examiner 2 Name Signature Date

---------------------------------- -------------------------- ----------------------

Examiner 3 Name Signature Date

i
--------------------------------- ---------------------------- --------------------

Table of Contents
Acknowledgement...................................................................................................................vii

List of abbreviations...............................................................................................................viii

Abstract.....................................................................................................................................ix

Chapter one................................................................................................................................1

1 Introduction.............................................................................................................................1

1.1 Background of the organization.......................................................................................1

1.2 Statement of problems.....................................................................................................2

1.3 Objective of the project...................................................................................................3

1.3.1 General objective......................................................................................................3

1.3.2 Specific objective the project....................................................................................3

1.4 Seasibility analysis...........................................................................................................3

1.4.1 Technical feasibility..................................................................................................4

1.4.2 Operational feasibility..............................................................................................4

1.4.3 Economic feasibility.................................................................................................4

1.4.4 Political feasibility....................................................................................................4

1.5 Scope and limitations of the project.................................................................................5

1.5.1 Scope of the project..................................................................................................5

1.5.2 Limitation of project.................................................................................................5

1.6 Significance of the project................................................................................................5

1.7 The main beneficiaries of the project..............................................................................6

1.8 Methodology of the project.............................................................................................7

1.8.1 Data gathering methodology.....................................................................................7

1.8.2 System development methodology...........................................................................8

ii
 1.9 Tools used to develop the system....................................................................................8

Chapter two..............................................................................................................................10

Requirement analysis description............................................................................................10

2.1 Introduction....................................................................................................................10

2.2 Users of existing system................................................................................................10

2.3. Major functions of the existing system.........................................................................11

2.4. Forms and other documents of the existing systems (if any).......................................11

2.5. Drawbacks of the existing system................................................................................12

2.6. Business rules of the existing system...........................................................................13

Chapter three............................................................................................................................15

Proposed system......................................................................................................................15

3.1 Functional requirements................................................................................................15

3.2 Non-functional requirements.........................................................................................16

3.2.1 User interface and human factors...........................................................................16

3.2.2 Hardware consideration..........................................................................................16

3.2.3 Security issues........................................................................................................16

3.2.4 Performance consideration.....................................................................................16

3.2.5 Error handling and validation.................................................................................17

3.2.6 Quality issues..........................................................................................................17

3.2.7 Backup and recovery..............................................................................................17

3.2.7 Physical environment..............................................................................................17

3.2.8 Resource issues.......................................................................................................18

3.2.9 Documentation........................................................................................................18

Chapter four.............................................................................................................................19

System analysis........................................................................................................................19

4.1System model..................................................................................................................19

iii
 4.1.1 Use case model.......................................................................................................19

4.2 Object model..................................................................................................................36

4.2.1 Normal class diagram.............................................................................................36

4.2.2 Data dictionary........................................................................................................37

4.3 Dynamic model..............................................................................................................40

4.3.1 Sequence diagram...................................................................................................41

4.3.2 Activity diagram.....................................................................................................49

4.3.3 State chart diagram of proposed system.................................................................56

Chapter five.............................................................................................................................58

System design..........................................................................................................................58

5.1 Introduction....................................................................................................................58

5.2 Design goals...................................................................................................................58

5.3 Current system architecture...........................................................................................59

5.4 Proposed system architecture........................................................................................59

5.4.1 Subsystem decomposition and description.............................................................60

5.4.2 Hardware/software mapping...................................................................................61

5.4.3 Detailed class diagram............................................................................................62

5.4.4 Persistent data management....................................................................................62

5.4.5 Access control and security....................................................................................63

5.5 Packages.........................................................................................................................65

5.6 Algorithm design...........................................................................................................66

5.7 User interface model......................................................................................................69

References................................................................................................................................72

Appendixes..............................................................................................................................73

iv
 LIST OF TABLES

Table iv System Use Case Description for Create account...........................................................

Table v System Use Case Description for Create project..............................................................

Table vi System Use Case Description for Prepare Schedule.......................................................

Table vii System Use Case description for Search........................................................................

Table viii System Use Case Description for maintain Fixture or schedule...................................

Table ix System Use Case Description for View News................................................................

Table x System Use Case Description for Submit comment........................................................

Table xi System Use Case Description for View comment.........................................................

Table xii System Use Case Description for Register players........................................................

Table xiii System Use Case Description for Add of Game statistics............................................

Table xiv System Use Case Description for View schedule........................................................

Table xv System Use Case Description for Maintain User account..............................................

Table xvi System Use Case Description for Confirm comment....................................................

Table xvii System Use Case Description for Generating report....................................................

Table xviii System Use Case Description for Add Announcement..............................................

Table xix attribute description for user..........................................................................................

Table xx: attribute description for account....................................................................................

Table xxi attribute description for schedule..................................................................................

Table xxii attribute description for news.......................................................................................

Table xxiii attribute description for game statistics.......................................................................

Table xxiv attribute description for player....................................................................................

Table xxv attribute description for report......................................................................................

Table xxvi attribute description for announcement.......................................................................

v
 LIST OF FIGURES

Figure i sport commission management system general use case diagram...................................

Figure ii normal class diagram......................................................................................................

Figure iii Sequence diagram for Create account............................................................................

Figure iv Sequence diagram for Maintain User account...............................................................

Figure v Sequence diagram for Prepared Schedule.......................................................................

Figure vi Sequence diagram for Search.........................................................................................

Figure vii Sequence diagram for Maintain Schedule....................................................................

Figure viii Sequence diagram for Submit Comment.....................................................................

Figure ix Sequence diagram for Register game statistics..............................................................

Figure x Sequence diagram for View schedule.............................................................................

Figure xi Sequence diagram for Confirm comment......................................................................

Figure xii Activity diagram for login use case..............................................................................

Figure xiii Activity diagram for create account.............................................................................

Figure xiv Activity diagram for prepare schedule use case...........................................................

Figure xv Activity diagram for search use case.............................................................................

Figure xvi activity diagram for add game statistics use case.........................................................

Figure xvii Activity diagram for register player use case..............................................................

Figure xviii Activity diagram for view comment use case............................................................

Figure xix state chart diagram login form.....................................................................................

Figure xx state chart diagram for game registration form.............................................................

Figure xxi state chart diagram for generate report.........................................................................

Figure xxii: the proposed system architecture...............................................................................

Figure xxiii: deployment diagram.................................................................................................

vi
Figure xxiv Detailed Class Diagram..............................................................................................

Acknowledgement
First we would like to thank God for helping us through this project because nothing could be
possible without his free will and the completion of this project is supported by him. We are
really thankful of several others for their constant encouragement and inspiration until we
finish our project. Our project will not be successful without those scarify their time, share
their experience and support with ideas. We are also grateful for our advisor Mr Minichil
Aboye who taken his time and effort to accurately review our project and make helpful
comment and suggestion. We are also like to express our warmest blessing and appreciation
to all graduating class students of Information technology department. Finally, it would be
impossible to say enough about our friends who were there on every corner offering their
hands for help when we needed it.

vii
LIST OF ABBREVIATIONS
BR…………………………………. Business Rule

CD ……………………………… Compact Disk

CPU………………………………. Central Processing Unit

CSS ……………………………... Cascade Sheet Style

HTML ………………………. …. Hypertext Mark-up Language

HTTP …………………………… Hyper Text Transfer Protocol

INFO………………..…................... Information

JS ………………………………… Java Script

MS………………………................ Microsoft

MySQL ……………………. ……. My Structured Query Language

OOM……………………………… Object Oriented Methodology

OS……………………..................... Operating System

PHP………………………….......... Hypertext Pre-processor

RAM ……………………………… Random Access Memory

REQ…………………………………. Requirement

SCMS………………………...........Sport Commission Management System

SW…………………........................... Software

UCI ………………………………. Use Case Id

UI ………………………………… User interface

UML ……………………………… Unified Modelling Language

WTSCMS ………………………. Wolkite Town Sport Commission Management System

viii
 ABSTRACT

The main objective of this project is to develop a web-based Sport Commission Management
System for the Wolkite Town Sport Commission. The system will manage information
related to sports events, athlete registration, team management, and communication between
different sports clubs and individuals. It will serve as a centralized platform for facilitating
planning, organizing, and monitoring of various sports activities.

This project designed to address the operational challenges faced by the Wolkite Town
Sports Commission in Ethiopia. Currently relying on a manual system, the commission
encounters issues related to communication, data management, and overall efficiency. This
project proposes the development of a web-based system to streamline operations, improve
accessibility to real-time information, and enhance communication with fans and
stakeholders. Utilizing an object-oriented system analysis and design methodology, the
project aims to identify and analyze existing problems, define requirements, and implement a
user-friendly system. The expected outcome includes increased efficiency, improved
transparency, enhanced fan engagement, and overall optimization of the commission's sports
management activities.

ix
 CHAPTER ONE

1 INTRODUCTION
Nowadays, the new information system is increasing at an alarming rate to bring radical
change to the existing manual system, improve the performance of other systems, and solve
difficulties. Even though this technology is new to Ethiopia and most other developing
countries, with this in mind, our project aims to support the wolkite town sports commission
office with a computerized or network-based sports commission management service.
Because there is no organized sports management system in the city, the sports commission
gives this service a manual way of gathering and documenting information. There is no
reliable communication between different places, and there is no optimized way to facilitate
the service. So, we are initiating the development of a new web-based system for the wolkite
town sports commission. Motives to develop a web-based system for the wolkite town sports
commission for example, in wolkite town, until now, there has been no web-based sports
commission management system. For this reason, so many problems happen, especially in
management systems, among people who participate in sports, and among audiences. As
well, we are motivated to improve our knowledge regarding how to develop systems. Hence,
this chapter describes the project background, problem statements, objectives, scopes, project
significance, and methodology.

1.1 BACKGROUND OF THE ORGANIZATION

Wolkite town sport commission was established in around 1990 to improve sports
participation in the region and promote interaction with others Mr. Yidnekachew, the
commission officer, shared this information with us, and we think it's pretty cool.
However, the commission has been using a manual system to manage its activities, which
can be time-consuming and inefficient. That's why our project focuses on developing a
software system that simplifies and streamlines the management of the commission. We call
it the Wolkite Town Sport Commission Management System (WTSCMS).
In today's world, many countries use computers and the internet for their day-to-day
activities, and the WTSCMS will be no exception. The system will handle internal

1
communication, store documents, and generate timely and need-based reports. It will also
manage the daily activities of the sport commission.

1.2 STATEMENT OF PROBLEMS

Wolkite Town Sports Commission has multiple sports clubs and projects, with football,
handball, basketball, and athletics being the primary ones. However, the overall functioning
of the organization is not supported by information technology, leading to several problems.
The following are the significant issues with the existing system:
 Sports fans are often distanced from up-to-the-minute information about the sport,
such as schedules, goal scorers, and match results, especially from the match
stadium-like football games, volleyball, and so on.
 New employees cannot easily access data about events that happened before they
joined the organization or the current status of the event that is controlled by the
Commission.
 Promoting sports events and initiatives to engage the community and attract
sponsors can be a specific challenge for sports commissions, and manual systems
may not offer integrated marketing tools.
 Limited access to real-time player performance data makes it difficult to make
timely decisions for the team.
 Inefficient manual processes for squad selection led to a suboptimal lineup and
decreased team performance.
 Lack of effective communication channels with fans results in reduced fan
engagement and support for the team.
 Difficulty adapting to last-minute fixture changes or scheduling conflicts, impacting
match preparedness
 Unorganized or player information and staff profiles, leading to challenges in
managing team personnel effectively.
 Complex and time-consuming paperwork processes for player transfers and contract
renewals, causing delays and potential disputes.
 Inaccurate ticket sales and attendance data hinders revenue forecasting and fan
engagement efforts.

2
1.3 OBJECTIVE OF THE PROJECT

1.3.1 GENERAL OBJECTIVE

The objective of this project is to develop a web-based Sports Commission Management
System for Wolkite Town.

1.3.2 SPECIFIC OBJECTIVE THE PROJECT

The specific objective of the project is to achieve the general objective mentioned above by
performing individual tasks. The project is designed to:

 Gather information about the existing system.

 Identify and define the problems that the existing system has and then analyze the
system.
 Identify functional and non-functional requirements, and system design.
 To develop a system that provides up-to-date Collective Records of the sport
commission.
 To develop a system that will provide easy Query to all related details of sports
activity and generate any kind of report and search records, Records can be
exported to excel.
 To develop a system that provides Database Backup and Recovery.
 Prepare documentation and train the users.
 Coding, testing and implementing the new system.

1.4 FEASIBILITY ANALYSIS

The feasibility [1] of our project can be examined based on different categories:
 Technical Feasibility
 Operational Feasibility
 Economic Feasibility
 Political Feasibility

3
1.4.1 TECHNICAL FEASIBILITY

The project is developed within latest technology. Through the technology may become
obsolete after some period of time, due to the fact that never version of same software
supports older versions, the system may still be used. So, there are minimal constraints
involved with this project. It also easily accessible by the people who have basic computer
knowledge. The system is self-explanatory and does not need any extra sophisticated training
because the system has been built by concentrating on the graphical user interface concepts.
The system has been developed using PHP the project is technically feasible for
development.

1.4.2 OPERATIONAL FEASIBILITY

The system will provide adequate through put at desire time to the user and give the need
information in a timely usefully formatted way. The system also has security to gives access
privilege providing account for an authorize person. This system provides help description to
the user about how to use the system. In addition, the developers do other technical
modification on the system. So, the system will be operationally feasible or it will be
operationally acceptable to users. The system gives better user interface registration form and
storage of user information, easy updating, deletion and modification etc.

1.4.3 ECONOMIC FEASIBILITY

As cost/benefit analysis, show the new system will be developed using minimum cost and it
give many benefits such as advancing the services of the system, decreasing the workload of
the users. The organization does not use any advertising media to announce its services and
requirements because it makes information online and every one can get the information
from the site. The proposed web-based sport management system is economically feasible
because:
 The system requires very less human power.
 The system will provide fast and efficient automated environment.
 The system will have excellent and easily understand user interface and very less
user training is required to learn it.
 The cost of the proposed system is almost negligible when compared to the
benefits gained.

4
1.4.4 POLITICAL FEASIBILITY
The proposed system has no any conflict with any government directives, because it gives
Services for the people effectively and efficiently so the organization is profitable and the
system is politically feasible.

1.5 SCOPE AND LIMITATIONS OF THE PROJECT

1.5.1 SCOPE OF THE PROJECT

In this project our team will handle the following range of works:

 Player performance analysis: - through goals, assists, passes, tickets,

 Prepare squad selection and lineup: - consider injuries (player availability), performance
data.
 Fan management: - ticket sale, fan feedback and fan engagement during matches and
events.
 To review fixtures, entry of results, news and output of all this operation.
 Update league table, statistics and produce readable output.
 Player and staff profile: -personal details, contact information, contacts and medical
records.
 Transfer and contract management: - involves the processes and activities related to
player transfers, contract negotiations, and the management of player and staff
agreements within a sports organization.

1.5.2 LIMITATION OF PROJECT

In general, our proposed system is limited to perform the following tasks.
 Not conserved on employees monthly and daily salary.
 The project is not including budget of the commission, and the relationship of the
commission with other sectors.

1.6 SIGNIFICANCE OF THE PROJECT

5
The existing system is not computerized rather it is manual. Therefore, the web-based system
is playing an important role by simplifying the complicated work. The main benefits of this
system as it is computerized web-based system:
 The system allows control overall activities done in the system easily. For instance,
the sport commission manager starts to register new clubs/project and employees of
the office easily without any kind of confusion, wastage of time and interruption.
 Allow easily getting report related information. I.e. the problem associated with
manual processing is minimized and the quality of work and services became
improved.
 Achieves an increase in the satisfaction of users from the new system. For instance,
guest users are not expected to be going to sport commission to view schedule
information, announcement.
 The system simplifies tasks, unifies participants, and enhances the activities
surrounding playing sports.
 Allows coaches and analysts to assess the performance of individual players and the
team as a whole easily.
 Helps coaches and team managers in making informed decisions about which players
to include in the squad and in determining the starting lineup. This can improve team
performance and increase the chances of winning games.
 Engaging and managing fans is crucial for a sports organization's success. This
system can help in marketing, ticket sales, fan engagement, and building a loyal fan
base, which contributes to the team's income.

 Obtains a higher level of user satisfaction as a result of the new system.

for example, Users are unlikely to visit the Sport Commission to access
schedule details or announcements.

 Reduce data redundancy and data loss of the commission.

 Provides a platform for players, fans, and coaches to simplify tasks and enhance the
sports experience.

1.7 THE MAIN BENEFICIARIES OF THE PROJECT

6
Transitioning from a manual system to a web-based sports commission management system
can benefit various stakeholders involved in sports management in Wolkite town. The main
beneficiaries are:
 WTSCMS and staff is the main beneficiary of this project through
 Improve accuracy in handling or managing data.
 It will save time and will increase the productivity of their employees with this
system.
 Improved transparency
 Minimize time delay
 Fast decision making
 Game officers
Record officers/ game officer are beneficiaries of the new system through
 Highly initiated to the work.
 Better confidence in tasks that they perform.
 Effective use of time.
 Creation of error almost eliminated,
 The system development team (for us)
 Gets experience of working in real world environment
 Improve skill and knowledge.
 User
 It clearly known user will get fast and reliable, clear-cut service because the
system will do all this thing as they intend to get the service.

1.8 METHODOLOGY OF THE PROJECT

1.8.1 DATA GATHERING METHODOLOGY

Data gathering methodology will encompass various techniques, including observation,
interviews, and document analysis [1].
Observations: will be conducted to understand the workflow of the current system, with the
aim of comprehending the actual events taking place within the organization. During these
observations, team members will document and note down the events as they unfold.

7
Interviews: will be conducted with key personnel, such as the organization's manager, and
employees, to obtain the necessary data.

Additionally, document analysis will be employed to review written documents that detail
the rules, regulations, and constraints of the existing system, providing valuable insights for
the design of the new system. Furthermore, other relevant documents will be thoroughly
reviewed to inform and support the development of the project.

1.8.2 SYSTEM DEVELOPMENT METHODOLOGY

In this section, we are going to discuss about system development methodology that we
follow to develop our system and the method we used to collect data. In this project, the
team members decide to use object-oriented system analysis and design to develop our
system because of the following reason [2]:
 It can be easily maintained: It supports the design and representation of the system
using UML diagram like, use case, sequence and activities.
 It allows breaking down complicated system into smaller, clear and more
manageable part.
 Increase extensibility: means make modification on some part of the code will not
affect the other.
 It facilitates change in the system at low cost: by developing manual documentation
of our system so the object-oriented development methods help us to overcome this
problem.
 Increase reuse of component: the object oriented provides opportunities for reuse of
code or component through the concepts of inheritance, polymorphism, and
encapsulation.
 It makes our system more usable and more productive
 One of the approaches in object-oriented technique that we used to develop our
system is iterative. Because it used as fast development and delivery of high-quality
system at relatively low cost. We improve the sub system until the complete version
is reached.

1.9 TOOLS USED TO DEVELOP THE SYSTEM

8
To develop our system, we are going to use different tools.
Hardware tools:
 Personal computer (PC): For every activity of the project.
 Flash disc: To store files.
 Camera: To capture pictures which are necessary for developing the website.
 Printer: To print the document
Software tools: We will use the following tools to develop the web-based system:
 Front-End Technologies
 HTML: to define the content of web pages.
 CSS: to specify the layout of web pages.
 JavaScript: to program the behavior of web pages.
 Bootstrap: to develop responsive website.
 Back-end technologies
 Apache Server: to compile the sever side scripting language.
 MYSQL DBMS: server to compile SQL queries and store data.
 PHP: for server-side scripting language.
 Other software tools: Microsoft office word 2019, Microsoft power point and
draw.io

9
 CHAPTER TWO

2 REQUIREMENT ANALYSIS DESCRIPTION

2.1 INTRODUCTION

The existing sport commission management system in Wolkite Town is currently a manual-
based system that involves several steps. Initially, sports organizations and commissions
collect and maintain information about athletes, coaches, and various sporting events
manually, using paper-based records. This process involves the creation of physical
documents, such as registration forms and event schedules.
Athletes and coaches typically submit their details through hard-copy forms, which are then
manually processed and recorded by the sports commission staff. Event planning, scheduling,
and coordination are also conducted through traditional paperwork, with organizers relying
on printed documents to communicate details and updates.
Moreover, the manual system involves the physical storage of records in filing cabinets,
making retrieval and management of data time-consuming and prone to errors.
Communication within the sports community often relies on traditional methods such as
phone calls and physical notices.
In essence, the current manual-based sport commission management system in Wolkite lack
of efficiency and speed that a digitalized system could provide. Transitioning to a more
technologically advanced and automated system would likely streamline processes, enhance
data accuracy, and improve overall communication and coordination within the sports
community.

2.2 USERS OF EXISTING SYSTEM

In the existing sport commission management system in wolkite, various users play distinct
roles in managing and overseeing different aspects of sports activities. These users include:
10
1. Athletes: are key users who interact with the system by submitting their personal and
performance-related information during the registration process. They may also use the
system to access schedules, event details, and updates.
2. Coaches: utilize the system to register their teams, providing information about training
sessions, athlete performance, and team details. They may also rely on the system for
accessing competition schedules and relevant communications.
3. Sports Commission Staff: Staff members within the sports commission are responsible for
managing and maintaining the system. Their tasks include data entry, record keeping, and
ensuring the accuracy of athlete and event information. They may also generate reports and
communicate with athletes and coaches.
4. Event Organizers: Individuals responsible for organizing sports events using the system to
plan and schedule competitions. This includes inputting details about venues, dates, and
participating teams. Event organizers rely on the system to communicate updates and
changes to athletes, coaches, and other stakeholders.
5. Administrators: System administrators oversee the overall functioning of the sport
commissions.
6. Referees: involved in sports competitions use the system to access match schedules, team
information, and relevant rules and regulations. They may also use the system for reporting
match results and recording any incidents during competitions.

2.3. MAJOR FUNCTIONS OF THE EXISTING SYSTEM

The existing manual-based Sport Commission Management System encompasses several

major functions to facilitate the administration and coordination of sports-related activities.
includes athlete registration and tracking, where administrators manually record and manage
participant information. Event management is a crucial aspect, involving the planning,
organization, and execution of sports events, with manual scheduling and result recording.
The system oversees membership and accreditation processes, ensuring compliance with
participation requirements. Financial management, such as budgeting and expense tracking,
is carried out manually.

2.4. FORMS AND OTHER DOCUMENTS OF THE EXISTING SYSTEMS (IF ANY)

11
2.5. DRAWBACKS OF THE EXISTING SYSTEM
12
The existing System faces several drawbacks that are:
 Reliance on paper-based athlete registration and tracking poses challenges in terms of
data accuracy, retrieval, and storage.
 Event management, including scheduling and result recording, is susceptible to errors
and delays due to manual handling.
 The system's dependency on traditional communication methods hinders real-time
updates and efficient collaboration between administrators, coaches, and athletes.
 Membership and accreditation processes, particularly related to verifying participant
eligibility and compliance with specific sports regulations.
 Financial management, conducted manually, may encounter difficulties in budget
allocation and expense tracking for sports events.
 Performance evaluation process, often relying on subjective assessments, may lack
standardized criteria, leading to inconsistencies.
 Manual system may face cultural and linguistic barriers where various languages and
traditions exist. This diversity can complicate communication and coordination within
the sports commission.

2.6. BUSINESS RULES OF THE EXISTING SYSTEM

The existing system has a business rule which is effectively an operating principle or policy
that it must satisfy. Therefore, the existing system has the following business rules.

BR 1: - The information prepared and posted system should be checked /updated by Game
officer of the commission.

BR 2: -The user’s comment should be necessary and not affect sport society and us culture.

BR 3: -The team must be training before they go to the game.

BR 4: -The coach always controls and training his/her players.

BR 5: -Each player should play in his /her position.

BR 6: -Each match contains at list the whole player according to the sport needs.

BR 7: -There is not isolate conflicts player with referees and also team and referees during
the match as well as out of the match.

13
BR 8: -Each game contains the whole referees in competition time.

BR 9: -Each game done according to the given time /schedule.

BR 10: -Each project/club wear different uniform during the competition time.

BR 11: The players should first register before play in the different club or project.

BR 12: Each player should be given a unique number by the respective club or project.

BR 13: The game officer of sport commission should assign a referee before they participate
in the different clubs and projects.

BR 14: The game officer sport commission should schedule a Schedule before they
participate in the different clubs and projects.

BR 15: The referee must announce the game statistics after they accomplished their game.

BR 16: schedules should be checked, before posted.

14
 CHAPTER THREE

3 PROPOSED SYSTEM
3.1 FUNCTIONAL REQUIREMENTS

These are the statement of service that the system should provide. It explains how the system
should react to particular input and how the system should behave in a particular situation.
Functional requirement captures the intended behavior of the system. The proposed system is
design to do the following functionalities [4]

Functional Requirements for Sports Commission Management System:

 The system should allow the administrator to create accounts for project manager and
game officer, and also give role for users.
 The system should enable game officer to register sports events and tournaments.
 The system should allow the manager to generate reports on participant performance
and event outcomes.
 The system is intended to help sports officials record and manage scores and results.
 The system should allow officials to input and update information related to sports
teams and individual athletes.
 The system should provide athletes with the ability to search for upcoming events and
tournaments.
 The system should allow athletes to submit requests for participation in specific sports
events.
 Users should be able to provide feedback on events, facilities, and overall sports
management.
 The system should allow administrators to view and analyze user feedback.
 Users should have the capability to update and modify their own profiles.
 The system should register and maintain a record of sports teams, athletes, coaches, and
officials in the database.
 The system should facilitate the scheduling of training sessions and practices for sports
teams
 The system should enable the commission to manage and allocate resources for

15
 different sports events.
 Users should be able to access information on upcoming sports events, including
schedules and venues.
 The system should provide a platform for coaches to submit performance reports for
their athletes.
 The system should allow for the creation and management of sports committees for
specific events.

3.2 NON-FUNCTIONAL REQUIREMENTS

Non-functional Requirements for the Sports Commission Management System:

3.2.1 USER INTERFACE AND HUMAN FACTORS

The system should provide an intuitive and user-friendly interface suitable for users with
varying levels of expertise in sports management. The user interface should be responsive
and optimized for both desktop and mobile devices. Accessibility features should be
implemented to ensure inclusive. More over the system has support multiple languages.

3.2.2 HARDWARE CONSIDERATION

The system should be compatible with common hardware configurations, and specific
requirements should be documented.

3.2.3 SECURITY ISSUES

To ensure secure access, the system will incorporate user authentication and authorization
mechanisms, allowing only authorized personnel to interact with sensitive data. All sensitive
information will be encrypted to protect it from unauthorized access or data breaches.
Regular security audits and updates will be integral components of the system's maintenance
strategy, aiming to proactively identify and address potential vulnerabilities. This
commitment to ongoing security assessments will contribute to the overall resilience and
integrity of the system, instilling confidence in users regarding the protection of their data.

3.2.4 PERFORMANCE CONSIDERATION

System is designed to support an unlimited number of concurrent users, ensuring scalability

and accommodating a large user base without any predefined limitations. Performance
benchmarks will be established to ensure that the system maintains optimal responsiveness
16
and efficiency even under high user loads, providing a seamless experience for all users,
regardless of the scale of simultaneous interactions.

3.2.5 ERROR HANDLING AND VALIDATION

The system handles many exceptions like inserting empty string to the database and inserting
alphabetic value in integer text field and displays an appropriate message for each error.
Login error: the system shall handle an attempt to login with incorrect username and
password and display appropriate message.

3.2.6 QUALITY ISSUES

Since the system to be developed is web based and used different latest software when it will
develop, the system should give a fast and efficient service to all users. Adaptability,
availability, flexibility, and reliability are the key issues of this requirement. Use suitable
software and hardware to develop system, will able to achieve this requirement.
 Availability: -the system shall be available at any time for those who want to use it
but it may be out of use when the power is turn off and if there is no connection.
 Usability: -By training users to become familiar with the system and by designing
user friendly interface, the end users are able to place an order within few response
times.
 No Redundancy: -The proposed system can be avoided repetition of data anywhere in
the database.

3.2.7. BACKUP AND RECOVERY

System will adhere to a proactive data management strategy by conducting regular backups
of system data at predefined intervals. This precautionary measure aims to ensure the
availability of up-to-date information and facilitate a swift recovery process in the event of
system failures or data loss. Additionally, a comprehensive and documented recovery plan
will be established, outlining the step-by-step procedures to be followed in restoring the
system and recovering data effectively. This commitment to systematic backup and recovery
practices will enhance the system's resilience and minimize potential disruptions.

3.2.7 PHYSICAL ENVIRONMENT

17
This Sport commission is affected by weather condition when the hardware and software
available for our system may be crash. The system is affected by weather conditions like
earthquake and electronic shock.

3.2.8 RESOURCE ISSUES

Server Minimum hardware requirements for Apache server are:
CPU: 32 bit or 64-bit Cores: single (single core 2Hz or higher dual core 2GHz or higher is
recommended). Display resolution: 1360X768(or higher).
Client: CPU: 32 or 64 bits
RAM: 512 Mb or higher Editor Notepad++ or notepad
Adobe Photoshop (for editing an image)

3.2.9 DOCUMENTATION
Documentation will help the project team to have basic knowledge and also used for users to
guide how to operate the system. Therefore, it is a necessary requirement and it helps for
maintenance purpose. This documentation includes proposal, project report, and final
document.

18
 CHAPTER FOUR

4 SYSTEM ANALYSIS
4.1 SYSTEM MODEL
The system model for a Sport Commission Management System is a comprehensive
representation that illustrates the functionality, structure and interactions within the software.
It involves various diagrams and representations.
System modeling is creating a diagram for the System. This diagram helps us understand
how the system works and what it needs to do. It's like a blueprint [5] that guides the design
of the system.
 Use case diagrams depict the interactions between a system and its external actors,
showcasing various use cases and the relationships among them.
 Class diagrams represent the structure and relationships of classes within a system.
 Sequence diagrams illustrate the dynamic behavior of a system by showing the
sequence of interactions between different objects or components over time
 Activity diagrams represent the workflow or flow of activities within a system or a
specific process.
 State chart diagrams depict the various states that an object or a system can exist in
and the transitions between these states.
4.1.1 USE CASE MODEL
To construct the use case model which graphically represents the interaction of the system
with the external environment. The major actors that play major role out of the system are: -

Actor identification that will participate in the system are listed below:

 Game Official: Responsible for maintaining game schedules, adding

announcements, fixtures, and game statistics. Also responsible for adding referees,
news updates, generating reports, managing accounts, creating user accounts and
assigning roles.

19
  Coach: Responsible for handling player complaints, selecting players, and
communicating player status updates.
 Sport Commission Manager: are used to create project, confirm comment, add
announcement and view complain with in the sport commission.
 User (General Stakeholder): Represents any other stakeholder or user interacting
with the system. May include accessing information, viewing different events like
schedule, fixture, game statics and also, they submit comment.
 Club Manager: Responsible for player registration, club management, generating
reports, maintaining accounts, creating user accounts, and assigning roles within the
club.
 Project Manager: Responsible for managing projects, generating reports,
maintaining accounts, creating user accounts, and assigning roles within the project.
 Player: Players have similar responsibilities to users, but they also have their own
specific tasks such as submitting complaints and viewing training schedule.
Use case identification
The use cases incorporated in the system are: - Manage Account, Generate Report, Manage
Club, Manage Project, Confirm Comment, add announcement, View Complain, Submit
Comment, view, maintain Schedule, Generate News, Give Complain, Select Player, Notify
Player Status, and more, each contributing to the overall functionality of the sports
commission management system.

4.1.1.1 USE CASE DIAGRAM

The following figure specifies the use case model of the system

20
Figure i. sport commission management system general use case diagram

21
4.1.1.2 U SE C ASE D ESCRIPTION

use case events to determine the requirement use cases as described in the following section.

Use Case Name Create Account

Use case id UCI-1

Description This use case is to create account.

Precondition Sport Commission Manager, game officer, club manager, project manager has
privileges to create accounts.

Actors Manager

Entry Condition The Manager needs to create system users and category.
1. The Manager select the create account.
Flow of Events
2. The system display creates account interfaces open.
3. The Manager adds necessary information of a new user of the system
specifying his/her corresponding category and sub system that he/she can
use via create account screen.
4. The system is sending a message to the Manager if the creating account is
created or not.
5. The system will create and store new account on Database.
6. End use case.

Post Condition A new User is created and associated with his/her category. The new user can
now use the sub systems that he/she is assigned to.

Alternate Flow In case the Manager inserts incorrect data.

 The system promotes the manager to insert correct data.

 Flow returns to primary flow step 3.
Table i. System Use Case Description for Create account

Use Case Name Create project

Use case id UCI-2

Description This use case is to create project with category

22
Precondition Sport Commission Manager has privileges to create project.

Actors Manager

Entry Condition The Manager needs to create project.

1. 1. The Manager select the create project.
Flow of Events2. 2. The system display creates project interfaces open.
3. 3. The Manager adds necessary information about new project.
4. 4. The system is sending a message to the Manager if the creating account is
created or not.
5. 5. The system will create and store new project on Database.
6. 6. End use case.

Post Condition A new project is created with own category. The new project now use the sub
systems that is assigned to.

Alternate Flow In case the Manager inserts incorrect data.

 The system promotes the manager to insert correct data.

 Flow returns to primary flow step 3.

Table ii System Use Case Description for Create project

Use Case Name Add Schedule

Use case id UCI-3

Description Game officer prepare a Schedule based on the competition is specify dates and
register clubs or players according to sport type.

Pre-condition View manual notional and regional league schedule to scheduling.

Actor’s Game officer

Entry Condition The Game officer wants to Prepare fixture or Schedule.

23
 1. Game officer clicks on prepare schedule link.
Flow of Events
2. The system displays the schedule registration/prepares form.
3. Game officer prepare new schedule time and click save button.
4. The system checks the input and displays it is successfully saved or not.
5. If the game officer inserts new schedule different from old schedule.
6. The system adds the schedule in to system database.
7. Use case ends.

Post condition Arrange the prepared schedule of the competition

Alternate Flows If the game officer enters the same schedule as before.

 The system display error message and ask to insert new schedule.
 Back Step 3
 Use case ends.
Table iii. System Use Case Description for Prepare Schedule

Use Case Name Search

Use case id UCI-4

Description Display available information in the system.

Precondition The information must exist in the system.

Actors All the actors participating in the system utilize search.

Entry Condition User needs to search information.

1. User clicks on search link.
Flow of Events
2. The User input parameter to the system via search screen.
3. The system verifies whether the information is available.
4. The system displays result screen which indicate the available
information.
5. End use case.

24
 Post Condition The User search information.

Alternate Flows In case the User can’t find the information, he wants.

 The system determines the information is not available in the system.

 The system informs to User the information is not found via result
screen.
 End use case.

Table iv. System Use Case description for Search

Use Case Name Maintain Fixture or schedule

Use case id UCI-5

Game officer delete or modify the time or other attributes of the fixture time
Description

Precondition Input the id to search the schedule to be delete or update

Actors Game officer

Includes Search

Entry Condition The Game officer wants to maintain Fixture or schedule.

1. Game officer clicks on maintain schedule link.
Flow of Events
2. System opens maintain schedule page.
3. Game officer insert old schedule id to maintain.
4. The system displays old schedule to maintain.
5. The game officer inserts delete or update schedule.
6. System checks the delete or modify data and display it is successfully
maintaining or failed.
7. The system stores delete or update schedule in to system database.
8. End use case.

Post Condition Delete or update the prepared schedule date

25
Alternate Flows If the game officer enters wrong old schedule id.

 The system displays not found message

 Back to step 3
 Use case ends
Table v. System Use Case Description for maintain Fixture or schedule

Use Case Name View announcement

Use case id UCI-6

Description user of the system can view announcement that posted by sport commission
and other manager.

Precondition Go in to the home page of the commission

Actors user

Entry Condition The User wants to View announcement.

1. Gust user open commission home page.
Flow of Events
2. System displays the home page
3. Select a link to view the news.
4. The system displays you selected link address.
5. End use case.

Post Condition View the posted news by commission management office.

Alternate Flows N/A

Table vi. System Use Case Description for View News

Use Case Name Submit comment

Use case id UCI-7

Description The users give any comment or feedback to the system.

Precondition View the report, schedule and other information posted by concerned body

26
Actors Gust user

Entry Condition The user wants to Submit comment.

1. The gust user opens the system
Flow of Events
2. System displays the home page
3. Read information posted by body commission and click submit comment
button.
4. System display writing window form.
5. The gust user enters email, name, comment and click send button.
6. The system checks validation of the data.
7. System stores gust user information and comment in system database.
8. End use case.

Post Condition Give suggestion to the commission function.

Alternate Flows If the gust user enters wrong name and email.
 The system display error message.
 Back to step 5.
 Use case ends.

Table vii. System Use Case Description for Submit comment

Use Case Name View comment

Use case id UCI-8

Description After manager views the comment and they respond thank u alert to gust
users.

Precondition The user comments must be existing in the data base and confirmed by the
manager.

Actors Gust user

Entry Condition The system users want to view comment.

27
 1. The user opens the system
Flow of Events
2. system display the home page
3. Gust user clicks on view Comment menu.
4. System opens View comment page.
5. System display given comment from system database.
6. End use case.

Post Condition Gust user view confirm comment.

Alternate Flows If there is no comment in the database the system display “Comment empty
till Now”.
Table viii. System Use Case Description for View comment

Use Case Name Register players

Use case id UCI-9

Description The coach registers the player’s information.

Precondition None

Actors Coach

Entry Condition The Coach wants to Register player’s information.

1. The coach clicks on the registration link
Flow of Events
2. A system displays the new account form.
3. The coach fill and click create button
4. The system checks for the validity of the registration form.
5. The system registers to the database.
6. End use case.

Post Condition The players successfully registered to system.

Alternate Flows In case Coach input invalid information.

 System prompts game officer to enter correct data.

 Flow returns to primary flow step 3.
Table ix. System Use Case Description for Register players

28
Use Case Name Add Game statistics

Use case id UCI-10

Description This use case is registration of game statistics.

Precondition There must be new game statistics

Actors Game officer

Entry Condition The game officer wants to Add game statistics.

1. The game officer clicks on the statistics registration link.
Flow of Events
2. The system displays the registration page.
3. The game officer fills the form and click register.
4. The system successfully registers the game statistics to the database.
5. End use case.

Post Condition The game statistics successfully registered.

Alternate Flows If the Game officer put Invalid information to the database

 System displays error message.

 Flow returns to primary flow step 3.
Table x. System Use Case Description for Add of Game statistics

Use Case Name View schedule

Use case id UCI-11

Description The use case is use to view schedule for each sport type

Precondition The user must open the website.

Actors Gust user

Entry Condition The gust user wants to view schedule.

29
Flow of Events Step 1. The gust user opens the system.

Step 2. System displays the home page.

Step 3. Gust user clicks on schedule link (menu).

Step 4. System fetches the data from database and display schedule.

Step 5. Use case ends.

Post Condition The view schedule successfully Viewed.

Alternate Flows N/A.

Table xi. System Use Case Description for View schedule

Use Case Maintain user accounts

Name

Use case id UCI-12

Description Sport Commission Manager can add or remove Game officer, Coach’s, club
manager, project managers account.

Precondition Sport Commission Manager has privileges to Maintain accounts.

Actors Manager

Entry Condition The Manager wants to Maintain user account.

1. The manager chooses Maintain account link.
Flow of Events
2. The system display Maintain account page
3. The manager clicks Maintain account button.
4. The system display Create account or Maintain account page.
5. Sport Commission manager enters required information via create or
Maintain account page.
6. The system cheeks that all the entered information is valid.
7. System displays different message accordingly.
8. Use case ends.

Post Condition The Manager will Maintain user accounts.

30
Alternate Flows
If the Manager enters incorrect information

 The system determines the entered information is invalid.

 The system displays message “the entered information is invalid” return to
step 5
 Use case ends.

Table xii. System Use Case Description for Maintain User account

Use Case Name Confirm comment.

Use case id UCI-13

Description This use case is to approve comment requested by the user

Precondition The user comment must exist.

Actors Manager

Includes view comment

Entry Condition If the Manager user needs to approve comment request.

1. The manager click comment link.
Flow of Events
2. The manager checks if comment request is appropriate via view comment
screen.
3. The system will send an approval confirmation comment to the system.
4. Use case ends.

Post Condition Comment request will be confirmed.

 If the comment request is not appropriate the request is denied, the
Alternate Flows comment process is terminated.
 The system will send a denial confirmation to the requester.
 The use case ends.
Table xiii. System Use Case Description for Confirm comment

Use Case Name Generating report

31
Use case id UCI-15

Description The manager generate report regarding the sport commission under the
process

Precondition The report is already in database.

Actors Manager

Entry Condition If the Manager user needs to generate report.

1. The manager the system clicks on the generate report link
Flow of Events
2. The system display register report form.
3. the manager selects the report type and click generate button
4. The system checks if there is data.
5. The system displays “report generated”.
6. Use case ends.

Post Condition The report successfully generated

Alternate Flows If there are no any data displays” there is no to generate”

Table xiv. System Use Case Description for Generating report

Use Case Name Add Announcement

Use case id UCI-17

Description This use case is posting announcement for example for the manager post
announce for vacancy.

Precondition None

Actors Manager

Entry Condition If the Manager user needs to Add Announcement.

32
 1. The manager clicks on add announcement link.
Flow of Events
2. The system display adds announcement page
3. Enter the message to be announced
4. Enter the End date
5. click post announcement button
6. The system Validate message and date entered
7. Display announcement posted message.
8. Use case ends.

Post Condition Announcement database added.

Alternate Flows If the message field is empty or invalid and if the End date has passed,
system displays error message.

Table xv. System Use Case Description for Add Announcement

4.1.1.3 U SE CASE S CENARIO OR USE CASE REALIZATIONS

Use Case: Manage Account

Scenario: User Registration
 User accesses the Sport Commission system.
 User selects the "Register" option.
 System prompts the user to provide their personal information (e.g., name, email,
password).
 User enters the required information.
 System validates the entered information.
 System creates a new user account.
 System sends a registration confirmation email to the user.
 User receives the email and verifies their account.
Use Case: Generate Report
Scenario: Performance Report Generation
 Manager accesses the Sport Commission system.
 Manager navigates to the reporting section.
 Manager selects the "Generate Performance Report" option.
 System prompts the manager to select the desired month and year.

33
  Manager provides the month and year inputs.
 System retrieves the performance data for the selected month and year.
 System generates a performance report based on the retrieved data.
 System presents the generated report to the manager for review and download.
Use Case: Manage Club
Scenario: Create New Club
 Administrator accesses the Sport Commission system.
 Administrator navigates to the club management section.
 Administrator selects the "Create New Club" option.
 System prompts the administrator to enter the club details (e.g., name, contact
information).
 Administrator provides the necessary information.
 System validates the entered information.
 System creates a new club in the system.
 System displays a success message confirming the creation of the new club.
Use Case: Manage Project
Scenario: Update Project Status
 Project manager accesses the Sport Commission system.
 Project manager navigates to the project management section.
 Project manager selects the desired project from the list.
 System displays the project details and current status.
 Project manager selects the "Update Project Status" option.
 System presents a list of available status options (e.g., planning, ongoing,
completed).
 Project manager selects the new status for the project.
 System updates the project's status accordingly.
 System notifies the project team members of the updated status.
Use Case: Add Announcement
Scenario: Publish Announcement
 Administrator accesses the Sport Commission system.
 Administrator navigates to the announcement management section.

34
  Administrator selects the "Add Announcement" option.
 System prompts the administrator to enter the announcement details (e.g., title,
content).
 Administrator provides the necessary information.
 System validates the entered information.
 System publishes the announcement on the Sport Commission platform.
 System notifies users about the new announcement.
Use Case: Submit Comment
Scenario: User Comment Submission
 User accesses the Sport Commission platform.
 User navigates to the desired section of the platform.
 User finds the relevant content or discussion.
 User submits a comment expressing their opinion or asking a question.
 System validates the comment and associates it with the corresponding content.
 System displays the comment on the platform for other users to see.
Use Case: Select Player
Scenario: Player Selection for a Team
 Coach accesses the Sport Commission system.
 Coach navigates to the player selection section.
 Coach views the list of available players.
 System displays player profiles including their skills and performance.
 Coach analyzes the player profiles and selects the desired players.
 Coach adds the selected players to the team roster.
 System updates the team's player list with the selected players.
Use Case: Notify Player Status
Scenario: Sending Player Status Update
 Administrator accesses the Sport Commission system.
 Administrator navigates to the player management section.
 Administrator selects the desired player from the list.
 System displays the player's details and current status.
 Administrator selects the "Send Player Status Update" option.

35
  System presents a notification form to enter the status update.
 Administrator provides the necessary information regarding the player's status
(e.g., injury, availability).
 System sends a notification to the player regarding their updated status.
4.2 OBJECT MODEL
4.2.1 NORMAL CLASS DIAGRAM

Figure ii. normal class diagram

4.2.2 DATA DICTIONARY

36
In this section we will describe the attribute of an object.

Object Attribute Description Type

User First name This describes the first name of user Varchar

Last name This describes the last name of user Varchar

User_Id This describes the unique identification number of varchar

admin

Email This describes the email address of user varchar

Phone This describes the phone number of user Int

number

Table xvi. attribute description for user

Object Attribute Description Type

account user_name This describes the user’s name of any admin Varchar

account_Id This describes the unique identification number of int

accounts

Role This describes the role. Varchar

Password This describes the password Varchar

Table xvii. attribute description for account

Object Attribute Description Type

schedul game_type This attribute describes the type of game scheduled. Varchar
e

37
 schedule_no This attribute represents the schedule number of the int
game.

schedule_date This attribute represents the date of the scheduled date

game.

club This attribute represents the club associated with the Varchar
scheduled game.

Table xviii. attribute description for schedule

Object Attribute Description Type

News_type This attribute represents the type or category of news. varchar

Table xix. attribute description for news

Object Attribute Description Type

game date This attribute represents the date of the game for date
statistics which the statistics are recorded.

match_result This attribute describes the result of the game. Varchar

Penality_card This attribute represents the penalties or cards given Varchar

during the game.

Table xx. attribute description for game statistics

Object Attribute Description Type

Player Player_id This attribute represents the unique identification of Varch

the player. ar

Player_name This attribute describes the name of the player. Varch

ar

38
 age This attribute describes the age of the player. int

gender This attribute describes the gender of the player. Varc

har

Sport_name This attribute describes the name of the sport that the Varch
player is associated with. ar

Club_name This attribute represents the name of the club or team Varc
that the player belongs to. har

Table xxi. attribute description for player

Object Attribute Description Type

Report Report_typ This attribute describes the type or category of the report. Varchar
e

Report_no This attribute represents the unique identification number int

of the report.

Report_date This attribute represents the date when the report was date
generated.

Table xxii. attribute description for report

Object Attribute Description Type

announcement announcement_id This attribute represents the unique identification int

number of the announcement.

Announcement_type This attribute describes the type or category of Varchar

the announcement.

announcement This attribute contains the content or message of Varchar

the announcement.

39
 expire_date This attribute represents the expiration date or Varchar
validity period of the announcement.

Table xxiii. attribute description for announcement

4.3 DYNAMIC MODEL

In this section we will discuss about sequence and state chart diagram to visualize the
interactive behavior of the system and to describe some type of interactions among the
different elements in the model.

4.3.1 SEQUENCE DIAGRAM

Sequence diagram in a unified modeling language (UML) 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. Sequence diagrams are typically associated with use case
realizations in the logical view of the system under development.

Sequence diagram for Create account

40
 Figure iii. Sequence diagram for Create account

Sequence diagram for Maintain User account

41
 Figure iv. Sequence diagram for Maintain User account

Sequence diagram for Prepared Schedule

42
 Figure v. Sequence diagram for Prepared Schedule

Sequence diagram for Search

43
 Figure vi. Sequence diagram for Search

Sequence diagram for Maintain Schedule

44
Figure vii. Sequence diagram for Maintain Schedule

45
Sequence diagram for Submit Comment

Figure viii. Sequence diagram for Submit Comment

46
Sequence diagram for Register game statistics

Figure ix. Sequence diagram for Register game statistics

47
Sequence diagram for View schedule

Figure x. Sequence diagram for View schedule

48
Sequence diagram for Confirm comment

Figure xi. Sequence diagram for Confirm comment

4.3.2 ACTIVITY DIAGRAM
Activity diagram is basically a flow chart to represent the flow from one activity to another
activity. Activity diagrams are graphical representations of workflows of stepwise activities.
An activity diagram shows in overall flow of control. Activity diagrams are constructed from
a limited number of shapes, connected with arrows. The most important shape types are
rounded rectangles represent actions, diamonds represent decisions, a black circle represents
the start (initial state) of the workflow, an encircled black circle represents the end (final
state).

49
Figure xii. Activity diagram for login use case

50
Figure xiii. Activity diagram for create account

51
Figure xiv. Activity diagram for prepare schedule use case

52
Figure xv. Activity diagram for search use case

53
Figure xvi. activity diagram for add game statistics use case

54
Figure xvii. Activity diagram for register player use case

55
 Figure xviii. Activity diagram for view comment use case

4.3.3 STATE CHART DIAGRAM OF PROPOSED SYSTEM

Figure xix. state chart diagram login form

56
Figure xx. state chart diagram for game registration form

Figure xxi. state chart diagram for generate report

57
 CHAPTER FIVE
5 SYSTEM DESIGN
5.1 INTRODUCTION

In this phase the overall procedures, activities and methods of execution during the
implementation phase of the project are included. The following subtopics are discussed in
this phase. These are component diagram, deployment diagram, and persistence diagram and
user interface prototype of the project
5.2 DESIGN GOALS
Design goal primarily emerged from non-functional requirement of the system and the
objectives of the design goal are to model a system with high quality. The nature of the
design is created by the designer and it is more important for the programmer to implement a
high quality and error free system. The Design goals are used to describe the qualities of the
system that developer should have to optimize to satisfy users non-functional requirements of
the system. The system must be failure free for supporting the dependability issue. And
finally, efficiency and satisfaction must be specified with interactive and easily system
usability. To the severe it should consider.
Security: All records in a database are secured no one can have access other than the
authorized persons. The system is able to identify which user name and address belongs to
the authorized users and don't allow any unknown login requests.
Simplicity: The system is simple to use by any user who can understand English language.
Since it is a web-based system some features of the system, like news, comments for better
communication.
Efficiency: The system is efficient it helps users to finish their task at a limited time. It takes
less time and less amount of resource when developed.
Well-defined User Interface: The user interface of the system is easy to use by each user of
the system. It contains different buttons in a better layout to guide the user what to do
accessing the web.

58
Maintainability: During normal execution, if something wrong occurs on the system it can
make a successful repair action. The system maintainability measures the ease and speed
with which a system can be restored to operational status after a failure occurs.
Availability: The system is available at any time and everywhere in which Internet
connection is available.
Fault Tolerance: The system should be able to give response (error message) when the user
enters incorrect input. To do this, we will apply validation using java script.
Portability: The system can work in different platforms, for there could be platform shifting
in the future and the work to have the acceptance of different institutes having the different
platforms.

Dependability: the system needs to highly dependable as it is expected to be used by non-IT

professionals and the system should be robust and fault tolerance.

5.3 CURRENT SYSTEM ARCHITECTURE

The existing system of the Wolkite town sport commission management system is manual
system and hence there is no Existing software architecture that will be considered. As a
result, we only describe the software architecture of the newly proposed system

5.4 PROPOSED SYSTEM ARCHITECTURE

In our system we will use three tier architectures these are presentation tier, application tier
and database tier.
Presentation Tier: - consists of the user interface. This user interface is often a graphical one
accessible through a web browser or web-based application and which displays content and
information useful to an end user. This tier is often built on web technologies such as HTML,
JavaScript, and CSS and communicates with others layers through API calls.
Application Tier: Also called the middle tier, logic tier, business logic or logic tier, this tier
is pulled from the presentation tier. It controls application functionality by performing
detailed processing.
Data Tier: Houses database servers where information is stored and retrieved. In our system
we will use three tier architectures these are presentation tier, application tier and database
tier.

59
 Figure xxii. the proposed system architecture
5.4.1 SUBSYSTEM DECOMPOSITION AND DESCRIPTION

The subsystems can be considered as packages holding related classes/objects. These

subsystems are further decomposed into other subsystems. Users are classified in to roles.
The “Login” subsystem authenticates a user to grant access based on the role of the user. The
major subsystems identified are

 Manager module subsystems

 Information management module subsystem

 Registering sub-system

 Login subsystem

 Coach module subsystem

 Scheduling fixture sub system

60
5.4.2 HARDWARE/SOFTWARE MAPPING
Deployment diagrams are used for describing the hardware components where software
components are deployed.

Figure xxiii. deployment diagram

61
5.4.3 DETAILED CLASS DIAGRAM

Figure xxiv. Detailed Class Diagram

5.4.4 PERSISTENT DATA MANAGEMENT

Persistence modeling is used to communicate the design of the database, usually the data
base to both the users and the developers. It is also used to describe the persistence data

62
aspect of the system. The following tables indicate the persistence data management of the
system.

Figure xxv. Persistent Data Management

5.4.5 ACCESS CONTROL AND SECURITY

Access control is way of limiting access to a system or to physical or virtual resources. In

computing, access control is a process by which users are granted to access and certain
privileges to systems, resources or information.

63
Functions Commiss Game Club Coach Project Player ` user
ion officer Manager manager
manager

Login       

Manage   
Account

View player     
information

Register coach 

Generate   
Report

Manage  
club/project

Register 
referee

Register sport 

Prepare 
schedule

64
 Generate news 

Add score 

View
 
comment

Manage

player

Select player


Register

player
viewTraining
 
schedule
PACKAGES
A package diagram in the UML depicts the arrangement, organization and dependencies
between the packages that make up a model.

Package: a general proposed mechanism for organizing model statements into groups. It
provides an encapsulated name space within which all the names must be unique. It is used to
group semantically related elements.

The subsystems can be divided into three packages

 Interface package layer is client tier that is user interface.
 Application package layer is middle tier that contain subsystem.
 Database package layer is data tier that is that stores system information.

Package diagram for the system is illustrated below.

65
 FIGURE XXVI . PACKAGE DIAGRAM

5.5 ALGORITHM DESIGN

Elements in Architectural Design:

 User Authentication:

Algorithm: Pseudo code for user authentication might look like this:

function authenticateUser(username, password):

if username and password are valid:

grant access

else:

deny access

 Data Storage and Retrieval:

66
 Algorithm: Pseudo code for storing and retrieving data might involve CRUD operations
(Create, Read, Update, Delete) on a database:

function storeData(data):

return success or failure

function retrieveData(query):

return data

 Data Processing:

Algorithm: Pseudo code for data processing could involve algorithms for computations or
analysis:

function processData(data):

return processedData

 User Permission Management:

Algorithm: Pseudo code for managing user permissions might involve checking roles or
permissions:

function checkPermission(user, action):

if user has permission for action:

perform action

else:

deny action

User Interface Design:

Logical Characteristics of Interfaces:

67
 GUI Standards: Following industry-standard GUI principles for a clean and intuitive
interface.

 Screen Layout Constraints: Design screens for consistency and usability, ensuring
elements are logically placed.

 Standard Buttons & Functions: Include common functions like 'Save', 'Cancel', 'Help',
'Settings', etc., ensuring consistency across screens.

 Error Message Display: Standardize error messages for clarity and helpfulness.

Software Components Requiring User Interface:

 User Login Interface: Username, password fields, and authentication buttons.

 Data Entry Forms: Input fields, submit buttons.

 Dashboard Interface: Displaying statistics, graphs, and navigation elements.

 Settings Interface: User preferences, configurations.

68
5.6 USER INTERFACE MODEL

69
70
Figure xxvii User Interface model

71
REFERENCES

[1] https://www.business.qld.gov.au/starting-business/starting-buying/
planning/feasibility-analysis/.

[2] (http://www.people.uwec.edu/pierech/researchmethodes/datacollection) .

[3] https://en.wikipedia.org/wiki/Software_development_process.

[4] https://www.geeksforgeeks.org/functional-vs-non-functional-
requirements/.

[5] https://www.ibm.com/docs/en/dmrt/9.5?topic=diagrams-uml-models.

APPENDIXES
72
Interview questions

 When the organization was established?

 Who is the manager of the organization? What he does?
 What are the organization services?
 Do you have business rule? If yes, what are those?
 How the organization stored record?
 What are the problems on their works?
 Is the Organization currently uses computer system?
 What is the organization plan for the future?
 What is the organization structure?
 Who is the controller of information flow?
 Who is scheduling the game?
 In what way do you register new player?
 In what way does the information stored in the office?
 What is the responsibility of sport commission manager, game office, club manager,
project manager and coach?
 Who is register office workers and who is post announcement?

73