System Analysis and Design PDF

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.

System Analysis and Design 13
3.0 Conceptual class diagram
3.1 Classes
The Cheltenham Football club part administration framework has been created through a few
classes which show the general structure of the framework with no infringement of the tenets.
These are produced from the Unified Modeling dialect where every one of the part traits is being
depicted in a short incorporating the way in which every one of the strategies is sorted out
together to understand the general framework for the club. The classes here are shown together
with the relationship that includes each question. For us to plainly built up an efficient-classes
outline then we need a reasonable take a gander at the calculations in which they require an
abnormal state of examination. Each class outline incorporates its very own augmentation (Cabot
et al., 2014).
3.2 Class descriptions and main attributes
Class name Description Attributes
Player This class displays what a player can do, for
instance, the creation of an account, checking
and updating details and make the required
payments example the admin fees and the
monthly contribution
a) The player id
b) Player Age
c) Player Name
Staff This class shows every one of the activities that
should be possible by the staff part including
new individuals, removing apart from the
current rundown and create a report for at
regular intervals.
a) Name
b) Age
c) Date
d) Contact
Coach The coach can add the new game to the existing
game lists, get all the players under a training,
do the game cancellation to an already scheduled
game, updates the attendance list of the players.
a) Coach Name
b) Coach Id
c) Contact number
d) Coach age
Game The game schedules are displayed here in this
game class. All the details are recorded here.
a) Game id
b) Game name

System Analysis and Design 14
c) Prizes won and
d) Game playing time
From the above, we can sum up that a player can play in excess of one diversion. This is
appeared by the connection [1: n]. Additionally, a solitary staff part is equipped for including,
erasing a few petitions by the connection [ n:m]. Having thought about this connection, we can
likewise relate the staff and the mentor whereby a solitary staff part can serve a few mentors. At
long last, one Coach can oversee in excess of one gameplay.

System Analysis and Design 15
4.0 Interaction diagrams
4.1 Sequence diagrams: Description and justification
4.1.1 How to register a player
Figure 2: Registration Sequence Diagram

System Analysis and Design 16
4.1.2How to dismiss a player
Figure 3: Sequence diagram for Dismissing a player
Each progression of the arrangement graph brings a productive result, amid part enlistment, the
staff part gets the player points of interest, enters to the framework which approves and a
winning message is shown upon finish enrollment. Later on, the player will continue to the
administrator and the month to month commitment. For the most part, we can anticipate the
arrangement of each perspective in a situation through a consistent procedure.

System Analysis and Design 17
4.2 Activity diagram; Description and justification
Figure 4: Activity Diagram
From that beginning of the arrangement, we find that the match points of interest come as the
principal alternative from which the staff part can check for the diversion accessibility (Jena,
Swain and Mohapatra, 2014). When the amusement is approved, the players can be endorsed.
Through this, we legitimize that the staff part will consequently refresh the diversion points of
interest and print the last report. This graph helps the framework engineer incomprehension of
the considerable number of procedures that should be embraced (Linzhang et al., 2017).

System Analysis and Design 18
4.3 Collaboration diagrams; Description and justification
.
Figure 5: Collaboration Diagram
The entire arrangement of Cheltenham football club rotates around every one of the activities
embraced for the achievement of groups and the prosperity of the workforce. Through signing in,
the framework approves the client which gives an affirmation to the entrance to the next
framework functionalities. Every one of the individuals can be overseen, refreshed and the
questions, for example, the part seek and the player look to come in accordance with the inquiry
functionalities.

System Analysis and Design 19
4.4 Conclusion
From the above discussion, we can conclude that the use cases and the diagrams explain all the
goals of the system in any problem. It develops clear results in any given problem. User cases
should be only a solitary of a couple of various methods for getting customer necessities. Use
cases are significant in overseeing valuable requirements, in that limit they accept a basic
occupation in the definition. All the systems will never be compared with the human capacity of
doing work, the operational use of the system gathers all the stakeholders into one group to form
an integral section for the engineering processes.