System Analysis and Design Solution Template for Desklib

This solution template provides a detailed analysis of the system design for a football club. It includes use case diagrams, class diagrams, and interaction diagrams. The template also covers functional requirements, such as member registration, fee payment, and match recording. The solution is suitable for students studying system analysis and design.

System Analysis and Design Solution Template
Academic year and term: 2017/2018 – Semester-2, Year 1
Module title: System Analysis and Design
Module code: QAC020C154S
Module Convener: Hassan Baajour
Module Tutor: PLEASE ENTER YOUR TUTOR NAME HERE
Student Id: PLEASE ENTER YOUR STUDENT ID HERE
Deadline: 16-07-18 (no later than 2pm)
Coursework 1: System Design
1

Use case diagram
1.1 Functional requirements
 The information system shall automatically record the information of the members joining
the club. The details captured by the system shall include the first, middle, and last name of
the member, phone number, email address, address, role, date of joining, leaving date, and
likewise.
 Ability to the users to add, modify, or delete the member details, such as first, middle, and
last name of the member, phone number, email address, address, role, date of joining,
leaving date, and likewise.
 The system shall automatically calculate the admin fee and monthly contribution for the
new players joining as members and under 18 years. The admin fee in this case shall be £50
along with £25 as the monthly contribution (Alsaleh and Haron, 2016).
 The system shall automatically calculate the admin fee and monthly contribution for the
new players joining as members and over 18 years. The admin fee in this case shall be £75
along with £50 as the monthly contribution.
 Ability to the system to validate the status of the monthly contribution made by every player
as the member of the club. The status of the player shall be suspended if the monthly
contribution for the last month is not made. The status of the player shall be dismissed if the
contribution is not made for three consecutive months.
 Ability to the system to record and store that details of the match including the demographic
information of the players involved, date of the game, time of the game, type, home/away,
result of the match, prizes, and the additional information.
 Ability to the members to view and modify the account information, such as their name,
contact information, etc. The change history shall be maintained by the system (Beimel and
Kedmi-Shahar, 2018).
 Ability to the system to implement the changes in the match details in case of the match
being cancelled or postponed. The system shall send automated notifications and alerts to
the associated players regarding the changes.
 Ability to the system to send automated alerts to the respective coaches and managers
when the players do not attend the game or the training sessions.
 Ability to the users to search for a specific player, a game, or other information on the
system.
 Ability to the system to generate automated reports from the portal regarding the match
2

details or players or any other activity performed by the football club.
1.2 use case diagram
There are several system behaviour and interaction diagrams that have been defined and are used in
the process of system analysis and design. One such diagram is the use case diagram which is based
on the Unified Modeling Language (UML) concepts. It is the system behavioural diagram in which the
system users are the entities that are represented in the diagram as the actors and each of these
actors are mapped with the use cases which are the actions that are performed by the actors on the
system (Broeze et al., 2004). The use case diagram of the information system being develeoped for
the football club is as shown below.
3

2) use case diagram documentation
Primary use case 1: Validate Member Record
Use Case Name: Validate Member Record
Scenario: The system shall validate the member record to determine the status of
the monthly contribution made by them.
Triggering Event: Pay monthly payment
Brief Description: The monthly contribution to be paid by the members under 18 years is
4

£25 and for the members over 18 years is £50. The system shall ensure
that the monthly contribution is made by the members every month. The
failure to make the contribution shall be highlighted by the system by
changing their status to suspended or dismissed (Bhuiyan, Haque and
Shabnam, 2018).
Actor: Member, System
Related use cases: Suspend Member, Dismiss Member, Pay Monthly Payment
Stakeholders: End system users
Preconditions: The player shall be registered as a member in the club
Post-conditions: The status of the member shall be updated after the validation of the
member record.
Flow of Activities: Actor System
1. Open the system
2. Validate member record by
entering the member id
3. Change the status (A1)
4. Send notification (A2)
Home screen of the system shall
come up
The payment status shall be
displayed
The member status shall be
updated
The member shall be notified
about the change in the status
Alternate Path A1: The member status shall be suspended if the monthly contribution for
the previous month is not made and shall be dismissed if the contribution
for three consecutive months is not made.
A2: The notification shall not be sent to the members if they have made
the monthly contribution.
Primary use case 2: Attend Session
Use Case Name: Attend Session
Scenario: The system shall maintain the record of the session attended or not
attended by the members.
Triggering Event: System validation on the member details
Brief Description: The system shall notify the managers and the coaches regarding the
member if the training session or the game is not attended by the member
5

(Lee and Youn, 2016).
Actor: Member, System
Related use cases: Notify Manager
Stakeholders: End System Users
Preconditions: The member shall be registered on the system
Post-conditions: The notification shall be sent to the manager and the coaches if the
session is missed by the member
Flow of Activities: Actor System
1. Open the system
2. Validate session record of the
member
3. Send notification to the manager
and coach (A1)
Home screen of the system shall
come up
Session details shall be displayed
Notification shall be sent to the
manager and coach
Alternate Path A1: The notification shall be sent to the manager and the coach of the
member if the session or the game is not attended by the member. The
notification shall not be sent otherwise.
10 use cases - brief description
Register Member: The system shall allow the players to register themselves on the information
system. The details captured by the system shall include the first, middle, and last name of the
member, phone number, email address, address, role, date of joining, leaving date, and likewise.
The payment to be made at the time of the registration shall be decided on the basis of the age of
the member. If under 18 years, the admin fee for registration shall be £50 and monthly contribution
as £25. If over 18 years, the admin fee for registration shall be £75 and monthly contribution as £50.
Update Member: The system shall allow the members registered to make changes in their
information stored on the system, such as first, middle, and last name of the member, phone
number, email address, address, role, date of joining, leaving date, and likewise.
Delete Member: The system shall have the capability to delete a member from the records if the
member is no longer associated with the club and has the status as dismissed.
Pay Monthly Payment: The members shall be provided with the ability to make online payments to
make monthly contributions. These payments shall be regulated on the basis of the age of the
member. The monthly contribution to be made by a player less than 18 years of age shall be £25
6

and it shall be £50 for the players over 18 years (Tsarmpou and Tambouris, 2015).
Notify Manager: The manager and the coaches shall be informed by the system regarding the
attendance of the member in the game or the training session. If the player misses the game or the
training session, an automated notification shall be sent to the coach and the manager to inform
them about the same.
Suspend Member: The member status shall change as per the status of the monthly contribution
made by the member. If the monthly contribution of the previous month is not made, then the
status shall be suspended.
Dismiss Member: The member status shall change as per the status of the monthly contribution
made by the member. If the monthly contribution of three consecutive months is not made, then
the status shall be dismissed.
Record Match: The system shall be able to record and store that details of the match including the
demographic information of the players involved, date of the game, time of the game, type,
home/away, result of the match, prizes, and the additional information. The changes in the game
details shall also be made on the system.
Cancel Match: The admin shall have the ability to make alterations in the details of the match and
the alerts must be shared with the members if the match is cancelled.
Postpone Match: The admin shall have the ability to make alterations in the details of the match
and the alerts must be shared with the members if the match is postponed.
Generate Report: The system shall provide the admin with the ability to generate automated
reports from the system comprising of the match details, player details, and other information. The
filter options shall also be allowed to be applied by the admin during the generation of these
reports (Magableh, Shukur and Ali, 2013).
7

3) Class diagram including conceptual classes and associations, generalization, aggregation and/or
composition if applicable with a brief description
Class Diagram - It depicts the structure of the proposed football club system in the form of the
system classes along with their respective attributes, operations and relationships with other system
classes.
8

Class Description
MEMBER It is the system class which stores all the information regarding a member
of the club: Attributes are as follows:
 memberID
9

 mFirstName
 mLastName
 age
 address
 role
 status
 clubLeavingDate
 dateOfsuspension
 phoneno
 email
FEES It is the system class which stores all the information regarding the fees
submitted/pending member of the club: Attributes are as follows:
 memberID
 amountPaid
 paymentDate
 monthlyFees
TEAM It is the system class which stores all the information a team of the club:
Attributes are as follows:
 teamID
 teamName
 dateOfTeamFormation
TRAINING_SESSION It is the system class which stores all the information a training session of
the club: Attributes are as follows:
 trainingID
 trainingDateTime
MATCH It is the system class which stores all the information a match of the club:
Attributes are as follows:
 matchID
 matchName
 venue
 matchType
 matchDate
 prizes
 result
PLAYER_SESSION and TEAM_MATCH are two associative classes.
4) Interaction diagram
Sequence Diagram
10

11

Sequence Diagram - Sequence diagram depicts processes, lifelines of different objects and messages
exchanged among them. In the member suspension sequence diagram, administrator sends the
member details to the system. The system checks whether the monthly fees is pending fro 3 or more
months. If so, then the system sends the return message to confirm the suspension action.
Administrator confirms the suspension action. Then system updates the status of the member in the
backend.
Collaboration Diagram
12

Collaboration Diagram: Collaboration diagram depicts the relationships and illustration among the
objects of the proposed system’s member registration process. The admin’s instance starts with
sending the details of new user to be registered. The system’s instance checks whether the member
is already registered. The system calls createMember() method on MEMBER’s object which in turn
13

calls addMember() method to uniquely generate a memberID. It is then returned to the admin.
Flowchart/Activity Diagram
14

15

Flowchart Diagram Description and Justifications
The activity diagram depicts the flow from one activity to another activity. In this activity diagram,
suspension of member has been done if he/she founds to have not submitted monthly fees for 3 or
more consecutive months. The flow starts with administrator who enters the member ID in the
system. System checks whether the given member ID is a defaulter. If it is not then system displays
the status and asks member enter another member ID. If the entered member ID is a defaulter, then
administrator confirms the suspension message and system updates the status of this member ID at
the backend.
16

Appendix
17

References
Alsaleh, S. and Haron, H. (2016). The Most Important Functional and Non-Functional Requirements
of Knowledge Sharing System at Public Academic Institutions: A Case Study. Lecture Notes on
Software Engineering, 4(2), pp.157-161.
18

Beimel, D. and Kedmi-Shahar, E. (2018). Improving the identification of functional system
requirements when novice analysts create use case diagrams: the benefits of applying conceptual
mental models. Requirements Engineering.
Bhuiyan, M., Haque, F. and Shabnam, L. (2018). Integration of Organisational Models and UML Use
Case. Journal of Computers, 13(1), pp.1-17.
Broeze, H., Samplson, M., Lagarde, R. and Davis, P. (2004). 9.3.3 The value of UML Use-case
modeling in Product Life-Cycle context. INCOSE International Symposium, 14(1), pp.1926-1934.
Lee, C. and Youn, C. (2016). Dynamic Impact Analysis Method using Use-case and UML Models on
Object-oriented Analysis. Journal of KIISE, 43(10), pp.1104-1114.
Magableh, A., Shukur, Z. and Ali, N. (2013). Systematic Review on Aspect-oriented UML Modeling: A
Complete Aspectual UML Modeling Framework. Journal of Applied Sciences, 13(1), pp.1-13.
Tsarmpou, P. and Tambouris, E. (2015). Using learning analytics to enhance UML use case diagrams
assimilation in a distance education course. International Journal of Learning Technology, 10(4),
p.274.
19