System Analysis And Design Concepts For Cheltenham Football Club

Learning Objectives

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).

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).

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.

1. 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.

1. 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.

1. Deleting member details

Input: the user will be required to enter the player id to remove from the team

Cheltenham Football Club Information Management System

Output: a message with relevant data of the processed data

Processing: the system check if the entered information is correct before removing the player.

Figure 1: Use case Diagram

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.
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
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
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
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

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
4. The user navigates to my account where he or she can view details
5. The user can update if any need be.

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).

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 player presence.	1. Name 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 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.

Figure 4: Registration Sequence Diagram

Figure 5: 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).

Figure 6: 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).

Functional Requirements of the system

Figure 7: 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.

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.

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 Hall Press.