System Analysis and Design Report: Cheltenham Football Club System

This report presents a system analysis and design for the Cheltenham Football Club's information system. It begins with an introduction, scope, and functional requirements, including the addition, modification, and deletion of player details. The core of the report details a use case diagram, use case documentation (player registration, staff registration, etc.), a conceptual class diagram with class descriptions and attributes, and interaction diagrams such as sequence, activity, and collaboration diagrams. The report utilizes UML diagrams to visualize the system's design, addressing the club's need for efficient record management across its five youth teams. The analysis covers various aspects of the system, from player and staff registration to game cancellation and report generation. The report also outlines the stakeholders involved and provides detailed descriptions of various use cases, including login, account creation, player updates, and payment processing. The diagrams provide a visual representation of the system's components and interactions.

System Analysis and Design 1
System Analysis and Design
By [Name]
Course
Professor’s Name
Institution
Location of Institution
Date
Table of Contents
List of figures...................................................................................................................................4
1.0 Introduction................................................................................................................................5
1.1 Scope.................................................................................................................................5

System Analysis and Design 2
1.2 Functional System requirements.......................................................................................5
1.3 Use case diagram..............................................................................................................8
2.0 Use case diagram documentation.........................................................................................8
2.1 Description of use case.....................................................................................................8
2.1.1 Player registration use case...........................................................................................12
2.1.2 Staff registration use case.............................................................................................13
2.1.3 Coach registration use case...........................................................................................13
2.1.4 Staff login use case.......................................................................................................13
2.1.5 Member modification use case.....................................................................................13
2.1.6 Player search use case...................................................................................................14
2.1.7 Game cancel use case...................................................................................................14
2.1.8 Report printing use case................................................................................................14
2.1.9 Payments use case.........................................................................................................14
2.1.10 Accounts use case.......................................................................................................15
3.0 Conceptual class diagram...................................................................................................16
3.1 Classes.............................................................................................................................16
3.2 Class descriptions and main attributes............................................................................16
4.0 Interaction diagrams................................................................................................................19
4.1 Sequence diagrams: Description and justification..........................................................19
4.1.1 How to register a player................................................................................................19
4.1.2How to dismiss a player.................................................................................................20
4.2 Activity diagram; Description and justification..............................................................21
4.3 Collaboration diagrams; Description and justification...................................................22
4.4 Conclusion......................................................................................................................23
References......................................................................................................................................24

System Analysis and Design 3

System Analysis and Design 4
List of figures
Figure 1: Use case Diagram.............................................................................................................5
Figure 2: Sequence Diagram.........................................................................................................14
Figure 3: Activity Diagram............................................................................................................15
Figure 4: Collaboration Diagram...................................................................................................16
1.0 Introduction
Due to the expanding requirement for the administration of the recorded inside the Cheltenham
Football Club for the 5 groups being overseen here, there emerges a need to build up a
framework that will help in the running of the program in a day by day movement of the club.
Every one of these tasks can be put into an efficient record to facilitate the recovery of the data.
In light of this examination, a paper should convey to our concentration to the advancement of
the made-reference to a framework with the investigation and the structure all consolidated.
1.1 Scope
The framework in the survey will be of significance to the Cheltenham Football Club. From the
general arranging stage, the framework is set to give a very much overseen set of records for
every one of the players inside the club. The most extreme club limits are to permit the
enlistment of new individuals, refresh the current points of interest permitting changes of various
sorts. With this prominent, the group designers need to comprehend the prerequisites of the club
to guarantee they meet the base expressed goals through the improvement of their performance
(Cox and Bobrowski, 2016).
1.2 Functional System requirements
Damning is one noteworthy issue that can emerge using any given framework. With the end goal
to maintain a strategic distance from this, each designer needs a genuine picture of what
precisely the framework is relied upon to do and the conceivable manners by which it tends to be
created to permit more changes later on. We are given the practical necessities of the framework
as the primary perspective before any advancement procedure is started. Given the way that they
can't be dropped mostly, every one of the partners must have a reasonable comprehension of the
considerable number of procedures included (Blanchette et al., 2017).

System Analysis and Design 5
a) Addition of a player
Input Processing Output
The staff member enters the
details of the member to be
registered to the system
The information entered by
the staff member is
checked for any errors. The
system should ensure error-
free information are being
captured
The status of the process is
displayed via a message as a
confirmation to the end user.
b) Player details Modification
Input Processing Output
The user is required to enter the
new data meant to replace the
already existing in the system.
The user enters details such as
the phone number of the
username which could have
been added wrongly
The system updates the
player details based on the
query used. The data is
captured to the system.
The result of the process is
displayed via a confirmation
mention.
c) Deletion.
Input Processing Output
The staff member enters
the id of the player that
needs to be removed from
The player details are
checked well before the
removal from the system
The outcome of the
deletion process is
displayed to the user

System Analysis and Design 6
the system.

System Analysis and Design 7
1.3 Use case diagram.
Figure 1: General Use case Diagram
2.0 Use case diagram documentation
2.1 Description of use case
Use case Description
Players The overall operations involve the addition of
the details of each player and the respective
game details.
Level The sub-function level of the system design is
the level in which we get the use cases. The
analysis of the use case diagram comes along
immediately the concerned personnel is done
with the analysis of the functional and the
non-functional requirements of the system.
Primary actor The use case revolves in around the team
players of the Cheltenham football club, the
staff members and the coaches.
Stakeholder The system involves three stakeholders:
a) Players- the main concern for these
stakeholders is the creation of the account
in the team record
b) The staff member- the main duty for the
staff members is the update for the details
of each and every material in the system.
c) System administrator- the administrator
takes care of all the updates to the system
and the correction of the errors that could
arise while the system is in use.
Main success The staff member, player or the system

System Analysis and Design 8
administrator provides the login credentials
which upon authentication is granted access
to the system.
Alternative flow Error correction is the main factor of concern
in this scenario. The user intentionally inputs
incorrect information to the system.
Specific requirement A successful login or a registration is
normally appropriate if the time it takes to
complete is just within seconds.
Login use case
Use case title Login
Actors All the three stakeholders the players, the
staff members, and the team coaches
Description The member is required to provide the
username and the password in which the
system will authenticate
Precondition It is a requirement that the user must have
registered into the system.
Flow 1. The user is prompted to provide the
username and the password.
2. The system validates the input data then
proceeds to the authentication process.
3. Once verification is done and the
information provided is correct, the
system grants access to the user.
Account creation use case
Use case title The registration use case
Actors All the three staff, coaches and the players.

System Analysis and Design 9
Description The stakeholders provide all the required
details required to be entered into the system
for processing.
Precondition Only the members of the club are required to
carry out the registration process. For one to
be registered he or she must be a team
member.
Flow 1. The new member enters all his or her full
details required for registration.
2. The details are validated by the system
3. The new data is saved an anew record is
added to the database.
Player update use case
Use case title Player update use case
Actors Staff members
Description The staff member enters the system and
searches the player id. Upon completion, the
player details are displayed in the fields
required for updates.
Precondition The player record must be present in the
database. For the staff member to successfully
update the information, a player must be
existing in the Cheltenham player database
table.
Flow 1. The staff member enters the player id
2. The relevant player details are displayed
3. The staff member inputs the new
information for the update.

System Analysis and Design 10
Game Cancel use case
Use case title Game Cancel use case
Actors The coaches and staff members.
Description Briefly, the stakeholders cancel a re-
scheduled game through searching.
Precondition The kick-off time for the game must have
been scheduled and the user must be logged I
to the system.
Flow 1. A game id is entered by the user
2. The game is searched through by the
system
3. The details are displayed, the game
canceled and all the members are given
the notification.
2.1.1 Player registration use case.
a) The Cheltenham team player first gets into the system
b) He or she provides the required details for registration.
c) The entered information is validated.
d) The new player details are captured and the record added.
2.1.2 Staff registration use case.
a) The staff member gets into the system
b) He or she provides the details.
c) He or she also proceeds to the selection of the role played in the team.
d) The staff information is validated by the system.
e) The new record is added to the existing staff members list.
2.1.3 Coach registration use case
a) The team coach enters into the system
b) The coach provides his or her details
c) The information is validated by the system

System Analysis and Design 11
d) The new coach details are added and kept within the system.
2.1.4 Staff login use case
a) The staff member provides the login credentials, that is, username and password.
b) The user details are validated and authenticated by the system.
c) Access is granted to the staff member once the details are verified otherwise an
appropriate information is displayed to the user.
2.1.5 Member modification use case.
a) The staff member logs into the system by providing the username and the password
b) The member is to be modified is searched.
c) The relevant information is displayed based on the id searched.
d) The new information desired is now entered into the system.
2.1.6 Player search use case.
a) The staff member provides the login credentials from which access is granted.
b) The player id is entered into the system or any name of reference based on the system
requirements for queries.
c) The search button is clicked by the staff member under operations.
d) The list of details relating to the searched player is displayed by the system
automatically.
2.1.7 Game cancel use case.
a) The staff member enters the system
b) The game in question is searched by the staff member.
c) The cancel button displayed is clicked by the user.
d) The game is eventually canceled by the system.
e) The members are given the notification about the game cancel
2.1.8 Report printing use case.
a) The system user enters the system
b) The user is provided a list of reports to be printed
c) The staff member searches for the report appropriate for the session
d) The report is generated by the system.

System Analysis and Design 12
e) The print button is clicked by the user which commands the system to print it out on
paper.
2.1.9 Payments use case
a) The Cheltenham team player enters the system
b) He or she provides the login credentials, the username, and the password
c) The player pays for the charges required, the administrative fees and the contribution.
d) The player age is validated before approval
e) The new player savings are updated in the system
2.1.10 Accounts use case
a) The system user enters the system
b) The user provides the login credentials.
c) If the details are correct then he or she is granted the access.
d) He or she is provided with a menu to view the details from.
e) In case of disparity, then the user can do the necessary updates.