Cheltenham Football Club Member Management System Design

This article discusses the design principles for the Cheltenham Football Club member management system, including use cases, class diagrams, and interaction diagrams. The system will provide a well-organized set of records for all the players within the club, allowing for easy retrieval of information. The functional requirements have been clearly defined, ensuring that all stakeholders have a clear understanding of the processes involved.

System Design 1
System Analysis and Design
By [Name]
Course
Professor’s Name
Institution
Location of Institution
Date

System Design 2
Table of Contents
1.0 Introduction..............................................................................................................................4
1.1 Scope.................................................................................................................................4
1.2 Functional requirements................................................................................................4
1.3 Use case diagram.............................................................................................................6
2.0 Use case diagram documentation......................................................................................6
2.1 Use case description........................................................................................................6
3.0 Conceptual class diagram................................................................................................13
3.1 Classes............................................................................................................................13
3.2 Class descriptions and main attributes.......................................................................13
4.0 Interaction diagrams.............................................................................................................15
4.1 Sequence diagrams: Description and justification.....................................................15
4.1.1 How to register a player.............................................................................................15
4.1.2How to dismiss a player...............................................................................................16
4.2 Activity diagram; Description and justification.........................................................17
4.3 Collaboration diagrams; Description and justification.............................................18
Conclusion................................................................................................................................19
5.0 Appendix.................................................................................................................................20
References.....................................................................................................................................21

System Design 3
List of figures
Figure 1: Use case Diagram..........................................................................................................6
Figure 2: Class Diagram.............................................................................................................14
Figure 4: Registration Sequence Diagram................................................................................15
Figure 5: Sequence diagram for Dismissing a player...............................................................16
Figure 6: Activity Diagram.........................................................................................................17
Figure 7: Collaboration Diagram...............................................................................................18

System Design 4
1.0 Introduction
Due to the increasing need for the management of the recorded information within the
Cheltenham Football Club for the 5 teams being managed, there arises a need to develop a
system that will help in the running of the program in the daily activities of the club. All these
operations can be put into a well-organized record to ease the retrieval of the information. With
this in mind, this research paper ought to bring to our focus the development of the mentioned
system with the analysis and the design all combined (Dennis, Wixom and Tegarden, 2015).
1.1 Scope
The system in review will be of importance to the Cheltenham Football Club. From the general
planning phase, the system is set to provide a well-managed set of records for all the players
within the club. The maximum club boundaries are to allow the registration of new members and
update of the existing details allowing modifications of all kinds. With this noted, the team
developers need to understand the requirements of the club to ensure they meet the minimum
stated objectives (Valacich, George and Hoffer, 2014).
1.2 Functional requirements
Dooming is one major problem that can arise through the use of any given system. In order to
avoid this, every developer needs to have a true picture of what exactly the system is expected to
do and the possible ways in which it can be developed to allow more changes in the future.
According to Gruber et al., (2017), we are provided with the functional requirements of the
system as the main aspect before any development process is commenced. Given the fact that
they can’t be dropped halfway, all the stakeholders must have a clear understanding of all the
processes involved.

System Design 5
a) Adding a player
Input: the user enters all the details of the club member
Output: a message confirming the status of the added member is displayed.
Processing: the system will be able to check if there is any error in the information
entered for a player.
b) Modifying player details
Input: the system user will input the alternatives of the information being modified. For
instance, the phone number or the date the player joined the team.
Output: a confirmation message is displayed showing the result of the process.
Processing: the system checks if the details to be modified really exists. Then for an
existing player the data is updated to the new changed details.
c) Deleting member details
Input: the user will be required to enter the player id to remove from the team
Output: a message with relevant data of the processed data
Processing: the system check if the entered information is correct before removing the
player.

System Design 6
1.3 Use case diagram.
Figure 1: Use case Diagram
2.0 Use case diagram documentation
2.1 Use case description
Use case Description
Player name The match details should be added and the personal team player details.
Level In the design process of a system and the overall development, use case
diagrams falls in the sub-functional level. Once a user has fully
analyzed both the functional and the non-functional requirements, then
there is need to analyze this.

System Design 7
Primary actor The Cheltenham team player, the match coaches and the staff members.
Stakeholder The player of the team who generates an account, a member of the staff
who makes changes on the system details and the system administrator
who corrects errors and updates the system.
Main success
scenario
The user enters the login details which are then processed and
authenticated by the system. Access is then provided to the user to
access the website features.
Alternative flow In the testing process, a simple process of registration is undertaken. A
user registers an account using incorrect details which brings about an
error. The error is then instantly resolved by an expert.
Specific
requirement
The processing time for the registration and login request used by the
system should be less than one minute.
Use case for Login
Use case title Login use case
Actors Staff, players and coaches
Description The member first enters the username and the password from which the
system will grant access
Precondition The user must have an account
Flow 1. The user enters username and password
2. The system authenticates
3. Access is granted if details are correct
Use case for account creation

System Design 8
Use case title Registration use case
Actors Staff, players and coaches
Description The member provides all his or her details for an account to be created
Precondition The user must be a member of the Cheltenham football club
Flow 1. The user enters full details
2. The system validates
3. New record is created
Use case for updating players
Use case title update use case
Actors Staff
Description The member first enters the username and the password from which the
system will grant access, then the user searches for the relevant data
Precondition The staff member must have the privilege and the player must exist in
the database
Flow 1. The user enters username and password
2. The system authenticates
3. The user searches the player
4. Player details are displayed
5. The user enters the new information
Use case for Cancelling a game

System Design 9
Use case title Game cancel use case
Actors Staff and coaches
Description The member searches for the game to cancel
Precondition The user must have an account and the game should have been scheduled
to kick off
Flow 1. The user enters the game id
2. The system searches for the game
3. The game is cancelled and members notified
Use case for staff login
1. The member enters username and password
2. The system validates the user details
3. The system authenticates the user
4. The user is granted access to the system if details are correct.
Use case for player registration.
1. The player enters the system
2. The member enters his or her details
3. The system validates the user information
4. The system will keep the record of the new player
Use case for staff registration.
1. The staff member enters the system

System Design 10
2. The member enters his or her details
3. The staff member selects his or her role in the team
4. The system validates the staff information
5. The system will keep the record of the new staff member
Use case for coach registration.
1. The coach enters the system
2. The coach enters his or her details
3. The system validates the user information
4. The system will keep the record of the new player
Use case for modifying the member details
1. The staff member enters the system
2. The member first log in to the system by providing the username and password
3. The member enters the id of the club member to be modified.
4. The system displays information relating to the searched id
5. The member now enters the new data to be captured
Use case for searching a player
1. The member enters the system through login
2. The staff member enters a keyword relating to some information
3. The staff member clicks the button for search
4. The system will automatically get the list of all the items including the keyword

System Design 11
Use case for cancelling a game
1. The member enters the system
2. The member searches for the game to cancel
3. The member clicks the cancel button
4. The system will cancel the game
5. The system will update all members of the cancelled game
Use case for report generation
1. The user enters the system
2. The user searches for appropriate report
3. The system generates the report
4. The user then prints the report by clicking print button
Use case for payments
1. The player enters the system
2. The player provides the username and password
3. The player enters the monthly contribution and the admin fees
4. The system validates against the age
5. The player record is updated
Use case for viewing accounts
1. The user enters the system
2. The user enters his or her username and password
3. Access is granted

System Design 12
4. The user navigates to my account where he or she can view details
5. The user can update if any need be.

System Design 13
3.0 Conceptual class diagram
3.1 Classes
The Cheltenham Football club member management system has been developed through several
classes which display the overall structure of the system without any violation of the rules
(Shaikh et al., 2018). These are developed from the Unified Modelling language where each of
the member attribute is being described in a brief including the manner in which all the methods
are organized together to realize the overall system for the club. The classes here are displayed
together with the relationship that involves every object (Dakic et al., 2018). For us to clearly
develop well-organized class diagrams, we need to have a clear look at the algorithms in which
they require a high level of analysis. Every class diagram includes its own extension (Al-alshuhai
and Siewe, 2015).
3.2 Class descriptions and main attributes
Class name Description Attributes
Player The player can create an account, check his own
details and make the required payments.
1. The player Name
2. Age
3. Player id
Staff This class displays all the actions that can be done
by the staff member including adding new members,
deleting a member from the existing list and
generate a report for every three months.
1. Name
2. Date
3. Contact
4. Age
Coach The coach can add new game, train the players,
cancel a scheduled game and make updates for the
1. Name

System Design 14
player presence. 2. Id
3. Contact
4. age
Game This class displays all the games that are to be
played.
1. Game id
2. Game name
3. Prizes
4. Game time
Figure 2: Class Diagram
From the above we can generalize that a player can play more than one game. This is shown by
the relation [1: n]. Also, a single staff member is capable of adding, deleting several prayers by

System Design 15
the relation [n:m]. Having considered this relation, we can also relate the staff and the coach
whereby a single staff member can serve several coaches. Finally, one coach can manage more
than one game.
4.0 Interaction diagrams
4.1 Sequence diagrams: Description and justification
4.1.1 How to register a player
Figure 3: Registration Sequence Diagram

System Design 16
4.1.2How to dismiss a player
Figure 4: Sequence diagram for Dismissing a player
Every step of the sequence diagram brings a fruitful outcome, during member registration, the
staff member gets the player details, enters to the system which validate and a success message is
displayed upon complete registration. Later on, the player will proceed to the admin and the
monthly contribution. Generally, we can predict the sequence of every aspect in a scenario
through the logical process (Mythily, Valarmathi and Durai, 2018).

System Design 17
4.2 Activity diagram; Description and justification
Figure 5: Activity Diagram
From that start of the sequence, we find that the match details come as the first option from
which the staff member can check for the game availability. Once the game is validated, the
players can be approved. Through this we justify that the staff member will automatically update
the game details and print the final report. This diagram helps the system developer in
understanding of all the processes that need to be undertaken (Jena, Swain and Mohapatra,
2014).

System Design 18
4.3 Collaboration diagrams; Description and justification
Figure 6: Collaboration Diagram
The whole system of Cheltenham football club revolves around all the operations undertaken for
the success of teams and the well-being of the personnel. Through logging in, the system
validates the user which provides an assurance for the access to the other system functionalities.
All the members can be managed, updated and the queries such as the member search and the
player search come in line with the search functionalities.

System Design 19
Conclusion
As discussed above, utilize cases give a few and extremely helpful points of interest and with no
doubt it’s clear that these are intense apparatuses that each planner, frameworks investigators,
fashioners and analyzers can outfit at various phases of programming life cycle. It emerges
because of its straightforwardness and effortlessness to pass on the thoughts. Use cases ought to
be just a single of a few different ways of catching client necessities. Utilize cases are valuable in
managing useful prerequisites, and in that capacity, they assume an essential job in item
definition. Saying that "utilization cases will be utilized on the task" is along these lines an
inadequate expression, and any suggestion or process definition that just says, "utilize cases" is
fragmented.

System Design 20
5.0 Appendix
Tool
laptop
Visual Paradigm

System Design 21
References
Al-alshuhai, A. and Siewe, F., 2015. An Extension of Class Diagram to Model the Structure of
Context-Aware Systems. The Sixth International Joint Conference on Advances in Engineering
and Technology (AET-2015).
Dakic, D., Stefanovic, D., Lolic, T., Sladojevic, S. and Anderla, A., 2018, March. Production
planning business process modeling using UML class diagram. In 2018 17th International
Symposium INFOTECH-JAHORINA (INFOTECH)(pp. 1-6). IEEE.
Dennis, A., Wixom, B.H. and Tegarden, D., 2015. Systems analysis and design: An object-
oriented approach with UML. John Wiley & Sons.
Jena, A.K., Swain, S.K. and Mohapatra, D.P., 2014, February. A novel approach for test case
generation from UML activity diagram. In Issues and challenges in intelligent computing
techniques (ICICT), 2014 international conference on (pp. 621-629). IEEE.
Gruber, K., Huemer, J., Zimmermann, A., and Maschotta, R., 2017, October. Integrated
description of functional and non-functional requirements for automotive systems design using
SysML. In System Engineering and Technology (ICSET), 2017 7th IEEE International
Conference on (pp. 27-31). IEEE.
Mythily, M., Valarmathi, M.L. and Durai, C.A.D., 2018. Model transformation using logical
prediction from sequence diagram: an experimental approach. Cluster Computing, pp.1-12.
Shaikh, A., Mahoto, N.A., Saddar, S. and Shaikh, M., 2018, April. A Technique for the
Detection of Violating Property among UML/OCL Class Diagram. In 2018 5th International
Multi-Topic ICT Conference (IMTIC) (pp. 1-6). IEEE.
Valacich, J., George, J. and Hoffer, J., 2014. Essentials of systems analysis and design. Prentice

System Design 22
Hall Press.