Software Requirements Specification For: COMSATS University Islamabad, Park Road, Chak Shahzad, Islamabad Pakistan

COMSATS University Islamabad,
Park Road, Chak Shahzad, Islamabad Pakistan
SOFTWARE REQUIREMENTS
SPECIFICATION
(SRS DOCUMENT)
for
Footy Arena
Version 1.0
By
Daniyal Afzal Janjua CU/FA15-BCS-103/ISB
Moazzam Abbas CIIT/FA15-BCS-107/ISB
Supervisor
Ms. Saneeha Amir
Bachelor of Science in Computer Science (2015-2019)

Software Requirements Specification for Footy Arena Page ii
Table of Contents
Revision History ........................................................................................................................... iv
1. Introduction ..............................................................................................................................1
1.1 Purpose ........................................................................................................................................ 1
1.2 Scope ........................................................................................................................................... 1
2. Overall description...................................................................................................................1
2.1 Product perspective ..................................................................................................................... 1
2.2 Operating environment ................................................................................................................ 1
2.3 Design and implementation constraints ....................................................................................... 2
3. Requirement identifying technique ........................................................................................2
3.1 Use case diagram ......................................................................................................................... 2
3.2 Use case description .................................................................................................................... 4
4. Functional Requirements ......................................................................................................24
4.1 Sign-Up...................................................................................................................................... 24
4.2 Log-In ........................................................................................................................................ 25
4.3 Sign-Up With Facebook ............................................................................................................ 25
4.4 Sign-Up With Gmail.................................................................................................................. 26
4.5 Sign-In With Facebook.............................................................................................................. 26
4.6 Sign-In With Gmail ................................................................................................................... 26
4.7 Edit Profile................................................................................................................................. 27
4.8 Player Rating ............................................................................................................................. 27
4.9 Send Message ............................................................................................................................ 27
4.10 Upload Match (Ground Manager) ............................................................................................. 28
4.11 Upload Match (Player) .............................................................................................................. 28
4.12 Join Match ................................................................................................................................. 29
4.13 Create Tournament .................................................................................................................... 29
4.14 Send Request ............................................................................................................................. 29
4.15 Accept Request .......................................................................................................................... 30
4.16 Reject Request ........................................................................................................................... 30
4.17 Book Ground ............................................................................................................................. 30
4.18 Create Team............................................................................................................................... 31
4.19 Create Match ............................................................................................................................. 31
4.20 Payment ..................................................................................................................................... 32
4.21 View Newsfeed ......................................................................................................................... 32
4.22 Ground Rating ........................................................................................................................... 33
4.23 Player Feedback......................................................................................................................... 33
4.24 Ground Feedback....................................................................................................................... 33
4.25 Delete Match ............................................................................................................................. 34
4.26 Leave Match .............................................................................................................................. 34
4.27 Show Ground Location.............................................................................................................. 34
4.28 Report Player ............................................................................................................................. 35
4.29 Report Ground Management ..................................................................................................... 35
4.30 Fetch Leagues Data ................................................................................................................... 36
4.31 Get Location from Google API ................................................................................................. 36
4.32 Gmail Authentication for Sign-Up/Login via Passport ............................................................. 36
4.33 Facebook Authentication for Sign-Up/Login ............................................................................ 37
4.34 Check Account Information ...................................................................................................... 37
4.35 Logout........................................................................................................................................ 38
5. Non Functional Requirements ..............................................................................................38
5.1 Usability .................................................................................................................................... 38
5.2 Security ...................................................................................................................................... 38
5.3 Reliability .................................................................................................................................. 38
6. References ...............................................................................................................................39
Software Requirements Specification for Footy Arena Page iii
Software Requirements Specification for Footy Arena Page iv
Revision History
Name Date Reason for changes Version
Software Requirements Specification for Footy Arena Page v
Application Evaluation History
Comments (by committee) Action Taken

*include the ones given at scope time both in doc and
presentation
Fix formatting issues
Avoid use of informal language
Supervised by
Ms Saneeha Amir
Signature______________
Software Requirements Specification for Footy Arena Page 1
1. Introduction
The following document states the system requirements for Footy Arena, an online web portal and
Android application that will be the new medium for gathering football enthusiasts keep up to date
with the latest news of local Football. This document defines the functionality, design constraints,
scope and the overview of the project.
1.1 Purpose
Footy Arena, a social platform (comprising of a web portal and a mobile application) that enables
local football players and enthusiasts to discover, organize, and join football games. This platform
will provide its user to make their football profile, add friends, create team with friends and create
matches or tournaments. As users will be able to post their matches location, time and slots
availability, in this way every other user will be updated regarding football activities and events
going around the area. In this way Footy Arena will bring all football lovers closer.
1.2 Scope
A separate platform only for football players where they can create, discover and join football
events near them. A place where total football entertainment is just a swipe away. No need to be
part of dozen Facebook groups or WhatsApp groups. Keep track of all the football activities around
your area and become part of them. Due to this platform players will keep track of their
performances, their team’s performances and showcase their profile to the world. Player’s profile
will be proof of their skills.
2. Overall description
2.1 Product perspective
Football is the most followed sport in the world and it is gaining ground in Pakistan by the day.
Footy Arena is the first of its kind in Pakistan. Similar systems are working in England and Italy
will not only give football lovers in Pakistan the opportunity to keep track of football activities but
also to be updated with global football news as well. Users will be provide with scores, news,
transfers and match schedules of their favorite Professional clubs too. The application will allow
users to stay connected with football, football community and grow their football social circle.
2.2 Operating environment

OE-1: The system shall operate on android version 4.1 and above.
OE-2: Node.js server shall be used due its efficiency, security and feasibility.
OE-3: User base is Islamabad and Rawalpindi.
OE-4: The database of the system will be created using mongoDB.
OE-5: The web application will operate in the following web browsers:
 Google Chrome
 Mozilla Firefox
 Microsoft Edge
 Internet Explorer
2.3 Design and implementation constraints

Following are the design and implementation constraints:
1. The platform will have an android application and a web interface. Therefore it won’t be
available for iOS users.
2. The platform shall uses easyPay for carrying out players transactions. One part of the system
will be dependent of easy paisa servers. If their servers go down, then so do our payment
side.
3. Requirement identifying technique

3.1 Use case diagram
3.2 Use case description
Use Case UC-1.1

ID:
Use Case Player sign-up
Name:
Actors: Player
Description: The player can register him/herself into the system.
Trigger: Player clicks on the sign-up button.
Preconditions: 1. Player should have a valid email account to register.
Postconditions:
1. Player will get registered into the system after successful
authentication.
2. They will finally have an account on the system.
Normal Flow: 1. Player clicks the sign-up button.
2. Player enters username they want to use for this system.
3. Player enters an email id. (Validity check applied)
4. The system prompts to enter valid password (Validity check applied)
5. Player enters mobile number.
6. Player enters date of birth.
7. Player uploads the picture.(optional)
8. Player checks the box to agree to terms and conditions.
9. After authentication, player is notified that the request of account
creation has been successfully created.
Alternative Flows:
Exceptions: 1. If player enters invalid username.

• Show error message.
• Prompt player to enter valid name.
• If valid name entered, proceed to next step.
2. If player enters invalid email id.
• Prompt player to enter valid email id.
• If valid email entered, proceed to next step.
4. If player enters invalid mobile number.
• Prompt contactor to enter valid mobile number.
• If valid mobile number entered, proceed to next step.
5. If player enters invalid password.
• Prompt player to enter valid password.
• If valid password entered, proceed to next step.
6. If player does not check the terms and conditions.

• Prompt player to accept terms and conditions.
• If button is checked, proceed to next step
Business Rules
Assumptions: 1. Player enters valid credentials.
Use Case UC-1.2

ID:
Use Case Player Facebook sign-up
Name:
Actors: Player
Description: The player can register him/herself into the system through their active
Facebook account.
Trigger: Player clicks on the sign-in button.
Preconditions: 1. Player have a valid email account.
2. Player have an account on the system’s database.
Postconditions:
1. Player is signed in and directed to home screen.
Normal Flow: • Player clicks the Facebook sign-up button.
• Player enters their email id used on Facebook.
• Player enters their mobile phone.
• Player enters a valid password.
• After authentication, player is notified that the request of
account creation has been successfully created.
Alternative Flows: 1. Player clicks on forgot password.

2. UC-1.2.1
3. Player enters password.
4. Player will be signed in to the system.
Exceptions: 1. If player enters invalid email.
• Prompt player to enter valid name.
• If valid name entered, proceed to next step.
2. If player enters invalid mobile number.
• Prompt contactor to enter valid mobile number.
• If valid mobile number entered, proceed to next step.
3. If player enters invalid password.
• Prompt player to enter valid password.
4. If player does not check the terms and conditions.
• Prompt player to accept terms and conditions.

• If button is checked, proceed to next step
Business Rules
Assumptions: 1. Player enters valid credentials.
Use Case UC-1.3

ID:
Use Case Player sign-in
Name:
Actors: Player
Description: The player can login him/herself into the system.
Trigger: Player clicks on the sign-in button.
Preconditions: 1. Player have a valid email account.
Postconditions: 1. Player is signed in and directed to home screen.

Normal Flow: 1. Player clicks on sign in button.
2. Player enters his/her email id.
3. Player enters the password.
Alternative Flows: 1. Player clicks on forgot password.
2. UC-1.2.1
3. Player enters password.
Exceptions: 1. Player enters invalid email id.
• Prompt player to re-enter a valid email id.
• If valid email id is entered, proceed to next step.
2. Player enters invalid password.
• Prompt player to enter a valid password.
Business Rules
Assumptions: Player is already registered and enters valid email and password.
Use Case UC-1.4

ID:
Use Case Reset/Forgot Password
Name:
Actors: Player
Description: The player can reset the password.
Trigger: Player clicks on forgot password button.

Preconditions: 1. Player should have an account on the system’s database.
Postconditions: 1. The password is reset.

Normal Flow: 1. Player clicks forgot password button.
2. A link will be sent to player’s email id.
3. Following the link, player will enter a new password.
4. New password is set.
5. UC-1.2: User is redirected to sign in page.
Alternative Flows:
Exceptions: 1. Player enters invalid email id.

• Prompt player to re-enter a valid email id.
• If valid email id is entered, proceed to next step.
Business Rules
Assumptions: • Player is using the same email address which was used to sign-
up.
• Player enters a valid password.
Use Case UC-2.1

ID:
Use Case Create Match
Name:
Actors: Player
Description: Player will be able to create a football match either with another team
by challenging them or a pool for other players to join.
Trigger: Player clicks on create match button.
Preconditions: 1. Player is logged in.
Postconditions: 1. Match will be created and available to join for other teams.
Normal Flow: 1. Player clicks the create match button.
2. Player will asked to book the ground of their choice.
3. Player will be able to set time of match, slots available to join match
and price to be paid for joining the game.
4. Player will set format of match i.e. 5 vs 5 or 6 vs 6.
Alternative Flows: 1. Player has already booked a ground.
2. Player will set time, slots available, and price of match.
3. Player will set format of the game i.e. 5 vs 5 or 6 vs 6
Exceptions: 1. Player misses to enter detail that is required in the create match
form.
Business Rules 1. Player can cancel the game 4 hours before the start of the same
2. Only Player creating the match can cancel it.
Assumptions: -
Use Case UC-2.2

ID:
Use Case Cancel Match
Name:
Actors: Player
Description: Player will be able to cancel a football match either created by
challenging other teams or a pool game.
Trigger: Player clicks on cancel match button.
Postconditions: 1. Match will be cancelled.
Normal Flow: 1. Player clicks the cancel match button.
2. Player will prompted for confirm cancel.
Alternative Flows: -
Exceptions: Match is in progress

Business Rules 1. Player can cancel the game 4 hours before the start of the same
2. Only Player creating the match can cancel it.
Assumptions: -
Use Case UC-2.3

ID:
Use Case Join Match
Name:
Actors: Player
Description: Player can show his availability in his team by joining the match his
team is playing.
Trigger: Player clicks on join match button.
2. Player is member of a team.
Postconditions: 1. Player will join the game and play for his team.
Normal Flow: 1. Player clicks the join match button.
2. Player will be set available for the match.
Exceptions: Number of players exceeds the total number of available players.

Business Rules -
Assumptions: Player is willing to play for his team.
Use Case UC-2.4

ID:
Use Case Leave Match
Name:
Actors: Player
Description: Player can show his availability in his team by joining the match his
team is playing.
Trigger: Player clicks on join match button.
2. Player is member of a team.
Postconditions: 1. Player will join the game and play for his team.
Normal Flow: 1. Player clicks the join match button.
2. Player will be set available for the match.
Exceptions: 1. Number of players exceeds the total number of available

players.
Business Rules -
Assumptions: 1. Player is willing to play for his team.
Use Case UC-2.5

ID:
Use Case Join Pool Match
Name:
Actors: Player
Description: Player will be able to join pool of matches nearest to his location
organized by the system.
Trigger: Player clicks on join pool button.
2. Player has required cash in their account.
Postconditions: 1. Player will be able join the game nearest to his location and
enjoy the game.
Normal Flow: 1. Player clicks the join pool button.
2. Player will set his available time and place to play.
Exceptions: 1. Player gives wrong input of time and place.

Business Rules 1. The Player can remove himself from the game 4 hours before
the start of the same
Assumptions: 1. Player is willing to play in the provided time and place.
Use Case UC-2.6

ID:
Use Case Leave Pool Match
Name:
Actors: Player
Description: Player will be able to leave pool match joined by him.
Trigger: Player clicks on leave pool match button.
Postconditions: 1. Player will be leave a pool game joined by him
Normal Flow: 1. Player clicks the leave pool match button.
Exceptions: 1. Match is in progress

Business Rules 1. The Player can remove himself from the game 4 hours before
the start of the same
Assumptions: 1. Player is not willing to play in the provided time and place.
Use Case UC-3.1

ID:
Use Case Create Team
Name:
Actors: Player
Description: Player will be able to create their own team
Trigger: Player clicks on create team button.
Postconditions: 1. Team will be created and available to join for other players and
to play with.
Normal Flow: 1. Player clicks the create team button.
2. Player will search players available on the platform.
3. Player will be able to send invites to player he wants in his
team.
4. Upon the acceptance of request, the requested player will
become part of the team.
Exceptions: -
Business Rules -
Assumptions: 1. Player has a sound knowledge of football for better selection of
players.
Use Case UC-3.2

ID:
Use Case Update Team
Name:
Actors: Player
Description: Player will be able to update his team
Trigger: Player clicks on update team button.
2. Player is a team member
3. Player has a captain/manager status
Postconditions: 1. Team will be updated and available to join for other players and
to play with.
Normal Flow: 1. Player clicks the update team button.
2. Player will search players available on the platform to join.
3. Player will be able to send invites to player he wants in his
team.
4. Upon the acceptance of request, the requested player will
become part of the team.
5. Player will be able to remove players from his team.
Exceptions: -
Business Rules -
Assumptions: 1. Player has a sound knowledge of football for better selection of
players.
Use Case UC-4.1

ID:
Use Case Create Tournament
Name:
Actors: Player
Description: Player will be able to start a new tournament by setting its time, date
and venue.
Trigger: Player clicks on create Tournament button.
Postconditions: 1. Player will be able create a new tournament.
Normal Flow: 1. Player clicks the create Tournament button.
2. Player will set opening and closing date of tournament.
3. Player will set number of matches in tournament.
4. Player will set timings of matches
5. Player will set venue of matches
6. Player will set format of the game i.e. 5 vs 5 or 6 vs 6
7. Player will set fee for joining the tournament.
Exceptions: 1. Player gives invalid input.

Business Rules -
Assumptions: -
Use Case UC-4.2

ID:
Use Case Update Tournament
Name:
Actors: Player
Description: Player will be able to update tournament details.
Trigger: Player clicks on update Tournament button.
Postconditions: 1. Player will be able to update tournament details.
Normal Flow: 1. Player clicks the update Tournament button.
2. Player can update opening and closing date of tournament.
3. Player can update number of matches in tournament.
4. Player can update timings of matches
5. Player can update venue of matches
6. Player can update format of the game i.e. 5 vs 5 or 6 vs 6
7. Player can update fee for joining the tournament.
Exceptions: 1. Player gives invalid input.

Business Rules -
Assumptions: -
Use Case UC-4.3

ID:
Use Case Delete Tournament
Name:
Actors: Player
Description: Player will be able to delete a tournament.
Trigger: Player clicks on delete tournament button.
Postconditions: 1. Player will be able to delete a created tournament.
Normal Flow: 1. Player clicks the delete Tournament button.
2. Select the tournament to be deleted from the list of his ongoing

tournaments
Exceptions: 1. Tournament to be deleted is in progress.

Business Rules -
Assumptions: -
Use Case UC-4.4

ID:
Use Case Join Tournament
Name:
Actors: Player
Description: Teams will be able to join tournaments that are available.
Trigger: Player clicks on join Tournament button.
2. Player has caption/manager status
3. Player is member of a team
Postconditions: 1. Teams will be able join tournaments.
Normal Flow: 1. Player clicks the join Tournament button.
2. Player enters his team credentials.
Exceptions: 1. Player enters wrong/invalid input.

Business Rules -
Assumptions: -
Use Case UC-4.5

ID:
Use Case Leave Tournament
Name:
Actors: Player
Description: Teams will be able to leave tournaments that are joined by them.
Trigger: Player clicks on leave Tournament button.
2. Player has caption/manager status
3. Player is member of a team
Postconditions: 1. Teams will be able leave tournaments.

Normal Flow: 1. Player clicks the leave Tournament button.
2. Player enters his team credentials.
Exceptions: 1. Player enters wrong/invalid input.

Business Rules -
Assumptions: -
Use Case UC-5.1

ID:
Use Case Send Request
Name:
Actors: Player
Description: Players will send request to other players on this platform to grow their
circle.
Trigger: Player visits another player’s profile and clicks on send request button.
Postconditions:
Normal Flow: Player visit the profile of the player he wants to send request to and
presses send request.
Exceptions:
Business Rules -
Assumptions: Player want to add the other player for entertaining football.
Use Case UC-5.2

ID:
Use Case Accept Request
Name:
Actors: Player
Description: Player, to whom request is sent, accepts it.
Trigger: Player clicks the accept request button.
2. Friend Request is sent by someone.
Postconditions: Both players will be now Football Buddies on this platform.
Normal Flow: Player is notified regarding friend request.
Exceptions:
Business Rules -
Assumptions: Player want to add the other player for entertaining football.
Use Case UC-5.3

ID:
Use Case Reject Request
Name:
Actors: Player
Description: Player, to whom request is sent, rejects it.
Trigger: Player clicks the reject request button.
Postconditions: Both players will be not be Football Buddies on this platform.
Normal Flow: Player is notified regarding friend request.
Exceptions:
Business Rules -
Assumptions: Player doesn’t want to add other player.
Use Case ID: UC-6.1

Use Case Name: Sent Match Invite
Actors: Player
Description: Player sends match invite to a friend/team.
Trigger: Player clicks the send invite button.
2. Match is available on this platform.
3. Player or team to which invite will be sent is registered on this
platform.
Postconditions: Friend/Team will be notified.
Normal Flow:
Exceptions:
Business Rules -
Assumptions: Player wants to enjoy football in spare time.
Use Case UC-6.2

ID:
Use Case Accept Match Invite
Name:
Actors: Player
Description: Player/Team, to whom request is sent, accepts it.
Trigger: Player clicks the accept request button.
Postconditions:
Normal Flow: Player is notified regarding match invite on home page.
Exceptions:
Business Rules -
Assumptions: Player wants to enjoy football in spare time.
Use Case UC-6.3

ID:
Use Case Reject Match Invite
Name:
Actors: Player
Description: Player/Team, to whom invite is sent, rejects it.
Trigger: Player clicks the reject invite button.
Postconditions:
Normal Flow: Player is notified regarding match invite on home page.
Exceptions:
Business Rules -
Assumptions: Player/Team doesn’t want to engage in football.
Use Case UC-7.1

ID:
Use Case News
Name:
Actors: Player
Description: Players can see all global football news, match scores from major
football leagues.
Trigger:Player visit the Newsfeed screen.
2. Player had choosed the teams about which he wants to see news
Postconditions: 1. Player will be able to see news about their selected teams
Normal Flow: 1. Player clicks on Newsfeed.
2. Player will select on particular news to see its detail
Exceptions:
Business Rules -
Assumptions:
Use Case UC-7.2

ID:
Use Case News Detail
Name:
Actors: Player
Description: Players can see detail of the particular news on the Newsfeed.
Trigger: Player clicks the particular news.
2. Player had choosed the teams about which he wants to see news
Postconditions: 1. Player will be able to see full detail of the news
Normal Flow: 1. Player clicks on Particular News.
2. Player will be shown full news.
Exceptions:
Business Rules -
Assumptions:
Use Case UC-7.3

ID:
Use Case Newsfeed Selection

Name:
Actors: Player
Description: Players will be able to select teams whom newsfeed they want to see
Trigger: Player clicks the select newsfeed button.
Postconditions: 1. Player will be able to see the selected newsfeed
Normal Flow: 1. Player clicks on select newsfeed button.
2. Player selects the teams.
Exceptions:
Business Rules -
Assumptions:
Use Case UC-7.4

ID:
Use Case Edit Newsfeed
Name:
Actors: Player
Description: Players will be able to edit teams whom newsfeed they want to see
Trigger: Player clicks the edit newsfeed button.
Postconditions: 1. Player will be able to see the edit newsfeed
Normal Flow: 1. Player clicks on edit newsfeed button.
2. Player add/remove teams whom related news he want to see on
his newsfeed.
Exceptions: •
Business Rules -
Assumptions:
Use Case UC-8.1

ID:
Use Case Upload Ground Detail
Name:
Actors: Ground Manager
Description: Ground Manager will be to upload his/her ground details
Trigger: Ground Manager clicks the upload ground button.
Preconditions: 1. Ground Manager is logged in and has privileges to add details.
2. Ground Manager owns or manages a playing field
Postconditions: 1. Ground Manager will be able to upload ground detail
Normal Flow: 1. Ground Manager clicks on upload ground detail button.
2. Ground Manager enters ground name.
3. Ground Manager enters ground location.
4. Ground Manager enters games format that can be played on the
field i.e. 5 vs 5 or 6 vs 6
5. Ground Manager enters ground booking fee structure
6. Ground Manager enters little description about his playing field
Exceptions: 1. Ground Manager enters invalid input

Business Rules -
Assumptions: 1. Ground Manager has a ground and he wants to upload his/her
ground details so it can be used for booking purposes.
Use Case UC-8.2

ID:
Use Case Edit Ground Detail
Name:
Description: Ground Manager will be to edit his/her ground details
Trigger: Ground Manager clicks the edit ground button.
3. Ground Manager has already registered his ground
Postconditions: 1. Ground Manager edited ground detail
Normal Flow: 1. Ground Manager clicks on edit ground detail button.
2. Ground Manager edit ground detail he wants to change.
3. Ground Manager clicks save changes button

Business Rules -
Assumptions: 1. Ground Manager has a registered ground and he wants to
change any information provided by him/her.
Use Case UC-8.3

ID:
Use Case Remove Ground
Name:
Description: Ground Manager will be to remove his/her ground details
Trigger: Ground Manager clicks the remove ground button.
Preconditions: 1. Ground Manager is logged in and has privileges to remove
details.
3. Ground Manager has already registered his ground
Postconditions: 1. Ground Manager removed ground detail
Normal Flow: 1. Ground Manager clicks on remove ground button.
2. Ground Manager confirms the removal of ground.
3. Ground Manager click save changes button
Exceptions: 1. Ground Manager does not have ground removal privileges

Business Rules -
Assumptions: 1. Ground Manager has a registered ground and he/she wants to
remove ground details provided by him/her.
Use Case UC-8.4

ID:
Use Case Upload Ground Schedule
Name:
Description: Ground Manager will be to upload his/her ground schedule (booking
details)
Trigger: Ground Manager clicks the upload ground schedule button.
Postconditions: 1. Ground Manager uploaded ground schedule
Normal Flow: 1. Ground Manager clicks on upload ground schedule button.
2. Ground Manager enters matches being played on ground
3. .Ground Manager enters timings of matches being played
4. Ground Manager enters free slot timings that can be booked.

Business Rules -
Assumptions: 1. Ground Manager has a ground and he wants to upload his/her
ground schedule so free slots can be used for booking purposes.
Use Case UC-8.5

ID:
Use Case Edit Ground Schedule
Name:
Description: Ground Manager will be to edit his/her ground schedule (booking
details)
Trigger: Ground Manager clicks the edit ground schedule button.
Postconditions: 1. Ground Manager edited ground schedule
Normal Flow: 1. Ground Manager clicks on edit ground schedule button.
2. Ground Manager edits timings/free slots/matches detail

Business Rules -
Assumptions: 1. Ground Manager has a ground and he wants to edit his/her
ground schedule.
Use Case UC-9.1

ID:
Use Case Send Message
Name:
Actors: Player
Description: Player will be able to send messages to other users.
Trigger: Player clicks the send message button.
Preconditions: • Player is logged in
Postconditions: 1. Player communicated with each other
Normal Flow: 1. Player clicks on send message button
2. Player select the user he want to send message
3. Player writes message
4. Player click send button
Exceptions:
Business Rules -
Assumptions: 1. Player is communicating with other user.
Use Case UC-9.2

ID:
Use Case Delete Message
Name:
Actors: Player
Description: Player will be able to delete messages history.
Trigger: Player clicks the delete messages button.
Preconditions: 1. Player is logged in
Postconditions: 1. Player deleted communication history
Normal Flow: 1. Player clicks on delete message button
2. Player select the message he/she want to delete
3. Player click delete button
4. Player confirms deletion
Exceptions: -
Business Rules -
Assumptions: 1. Player is deleting previous messages history.
Use Case UC-10.1

ID:
Use Case Rate
Name:
Actors: Player
Description: Player will rate the performance of a player/team in a specific game or
based on their career span.
Trigger: Player clicks the rate button.
Postconditions: 1. Player rated a player
Normal Flow: 1. Player clicks on rate button
2. Player select player/team he/she want to rate

3. Player rate
4. Player clicks save button
Exceptions: -
Business Rules -
Assumptions: 1. Player is rating other player/team.
Use Case UC-10.2

ID:
Use Case Reviews
Name:
Actors: Player
Description: Player will be able to give reviews on other player and grounds
Trigger: Player clicks the review button.
Postconditions: 1. Player reviewed a player/ground
Normal Flow: 1. Player clicks on review button
2. Player select player/team/ground he/she want to review
3. Player review
4. Player clicks save button
Exceptions: -
Business Rules -
Assumptions: 1. Player is giving reviews to other player/team/team.
Use Case UC-11.1

ID:
Use Case Player Payment
Name:
Actors: Player
Description: Player will be able to pay for his match dues
Trigger: Player clicks the payment button.
Postconditions: 1. Player payed his/her match dues
Normal Flow: 1. Player clicks on payment button

2. Player selects his payment method
3. Player enters his credentials (Visa/MasterCard)
4. Player clicks pay button
Exceptions: Player enters wrong credentials

Business Rules -
Assumptions: 1. Player is paying his/her dues
Use Case UC-11.2

ID:
Use Case Organizer Payment
Name:
Actors: Organizer
Description: Organizer will be able to pay for his/her ground booking dues
Trigger: Organizer clicks the payment button.
Preconditions: 1. Organizer is logged in
Postconditions: 1. Organizer payed his/her match dues
Normal Flow: 1. Organizer clicks on payment button
2. Organizer selects his payment method
3. Organizer enters his credentials (Visa/MasterCard)
4. Organizer clicks pay button
Exceptions : Organizer enters wrong credentials

Business Rules -
Assumptions: 1. Organizer is paying his/her dues
4. Functional Requirements
4.1 Sign-Up
Identifier FR-001
Title Sign-up
Requirement The players shall be able to create their account on the system.
Source Supervisor
Rationale Players can join the football community for updates and also start their
football career.
Business Rule (if Same email id cannot be used for multiple users and thus this minimizes
required) duplication.
Dependencies Nil
Priority High
4.2 Log-In
Identifier FR-002
Title Log-In
Requirement The system requires the player to login by providing correct credentials.
Source Supervisor
Rationale Players can join the football community for updates and also start their
football career.
Business Rule (if Player/Ground Manager enters correct email and password which ensures
required) security.
Dependencies FR-001
Priority High
4.3 Sign-Up With Facebook

Identifier FR-003
Title Sign-Up With Facebook
Requirement The system allows the users to sign-Up with their Facebook account.
Source Supervisor
Rationale System will allow user to sign-Up with Facebook.
Business Rule (if
required)
Dependencies FR-001
Priority Low
4.4 Sign-Up With Gmail

Identifier FR-004
Title Sign-Up With Gmail
Requirement The system allows the users to sign-up with their Gmail account.
Source Supervisor
Rationale System will allow user to sign-up with Gmail.
Business Rule (if
required)
Dependencies FR-001
Priority Low
4.5 Sign-In With Facebook

Identifier FR-005
Title Sign-In With Facebook
Requirement The system allows the users to sign-in with their Facebook account.
Source Supervisor
Rationale System will allow user to sign-in with Facebook.
Business Rule (if
required)
Dependencies FR-001
Priority Low
4.6 Sign-In With Gmail

Identifier FR-006
Title Sign-In With Gmail
Requirement The system allows the users to sign-in with their Gmail account.
Source Supervisor
Rationale System will allow user to sign-in with Gmail.
Business Rule (if
required)
Dependencies FR-001
Priority Low
4.7 Edit Profile

Identifier FR-007
Title Edit Profile
Requirement The system allows the player/ground manager to manage and edit their
profiles.
Source Supervisor
Rationale To allow the player to update their profiles with the latest information.
Business Rule (if Player/Ground manager must enter valid information.
required)
Dependencies FR-002
Priority Low
4.8 Player Rating

Identifier FR-008
Title Rating
Requirement The system allows the players to rate each other’s performances after
playing.
Source Supervisor
Rationale This helps the players to grow themselves and evolve in the community.
Business Rule (if
required)
Dependencies FR-002
Priority Medium
4.9 Send Message

Identifier FR-009
Title Message
Requirement The system allows the player/ground manager to convey a message
regarding games.
Source Supervisor
Rationale This helps improved communication between players and ground
managers.
Business Rule (if
required)
Dependencies FR-002
Priority Medium
4.10 Upload Match (Ground Manager)

Identifier FR-010
Title Upload Match
Requirement The system allows the manager to upload and update ground slots
schedule.
Source Supervisor
Rationale Instead of manually meeting with lower management managers can
upload ground’s information with an instance.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.11 Upload Match (Player)

Identifier FR-011
Title Upload Match
Requirement The system allows the player to upload and update ground slots for match
so that other players can join in.
Source Supervisor
Rationale Instead of manually meeting, texting or posting updates of a match
players can simply post it here and other players can view where the
match is being played.
Business Rule (if First player needs to create match.
required)
Dependencies FR-002
Priority High
4.12 Join Match

Identifier FR-012
Title Join Match
Requirement The system allows the players to join matches.
Source Supervisor
Rationale Players see match updates and invites on newsfeed. Depending on most
suitable place and time they can join the match.
Business Rule (if For joining open pool matches, player needs to pay in advance.
required)
Dependencies FR-002 , FR-020
Priority High
4.13 Create Tournament

Identifier FR-013
Title Create Tournament
Requirement The system allows the player to create a tournament in a specific ground.
Source Supervisor
Rationale Instead of manually meeting and inviting teams to play football, make a
tournament a let other teams join.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.14 Send Request

Identifier FR-014
Title Send Request
Requirement The system allows the player to send request to players and teams in their
circle to play match or tournaments.
Source Supervisor
Rationale Instead of manually meeting and inviting teams/players to play football,

just send them a request.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.15 Accept Request

Identifier FR-015
Title Accept Request
Requirement The system allows the player to accept request and enjoy football.
Source Supervisor
Rationale Instead of manually meeting and inviting teams/players to play football,
just accept request.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.16 Reject Request

Identifier FR-016
Title Reject Request
Requirement The system allows the player to reject request sent by someone on this
platform.
Source Supervisor
Rationale Join games which suit your schedule and add people in your circle which
you know otherwise reject their offer.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.17 Book Ground

Identifier FR-017
Title Book Ground

Requirement The system allows the players to book ground for a time and match fee
described by the ground manager.
Source Supervisor
Rationale Instead of going to the ground to check available time or calling ground
management constantly for booking. Players can easily book ground via
their cell phones.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.18 Create Team

Identifier FR-018
Title Create Team
Requirement To join tournaments and challenge other teams.
Source Supervisor
Rationale It will allow player to create their team with their friends who are on this
platform. Assign roles to each team mate.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.19 Create Match

Identifier FR-019
Title Create Match
Requirement The system allows player to create a match with friends or open pool for
anyone to join.
Source Supervisor
Rationale Create a match on place and time which best suits the players and post in
online so that anyone can join it.
Business Rule (if Must have enough money in account to book ground.
required)
Dependencies FR-002 ,FR-034

Priority High
4.20 Payment
Identifier FR-020
Title Payment
Requirement System allows players and ground managers to carry out transactions.
Source Supervisor
Rationale This functionality enables players to pay ground managers for playing in
their grounds.
Business Rule (if Need to have an account and registered for an e-wallet as well.
required)
Dependencies FR-002
Priority High
4.21 View Newsfeed

Identifier FR-021
Title View Newsfeed
Requirement The system allows players to see news from all over the globe.
Source Supervisor
Rationale This will keep football encapsulated just in a single application. Every
football activity will be available on just a click.
Business Rule (if
required)
Dependencies FR-002
Priority Medium
4.22 Ground Rating

Identifier FR-022
Title Ground Rating
Requirement The system allows players to rate the ground based on turf quality.
Source Supervisor
Rationale After playing match in a ground, players will be able to rate the ground
and provide their reviews.
Business Rule (if Player must have played a match on that ground.
required)
Dependencies FR-002 FR-012
Priority Medium
4.23 Player Feedback

Identifier FR-023
Title Player Feedback
Requirement The system allows players to provide feedback for other players
Source Supervisor
Rationale
Business Rule (if Player providing feedback must have interacted with the player he is
required) giving feedback about.
Dependencies FR002, FR-012
Priority High
4.24 Ground Feedback

Identifier FR-024
Title Player Feedback
Requirement The system allows players to provide feedback on grounds.
Source Supervisor
Rationale
Business Rule (if Players providing feedback first must play in the respective ground.
required)
Dependencies FR002 , FR012

Priority High
4.25 Delete Match

Identifier FR-025
Title Delete Match
Requirement The system allows the match creator to delete match.
Source Supervisor
Rationale If pool of a match created is not filled then player can delete the match
and payment can be refunded.
Business Rule (if Match must be booked first.
required)
Dependencies FR-002
Priority High
4.26 Leave Match

Identifier FR-026
Title Leave Match
Requirement The system allows player to leave a match they’ve joined previously.
Source Supervisor
Rationale If a player cannot join match due to some reason he can leave the match
before the match starts so that match organizer could be notified in time.
Business Rule (if If player doesn’t notified in time then payment will not be refunded.
required)
Dependencies FR-002, FR-012
Priority High
4.27 Show Ground Location

Identifier FR-027
Title Show Ground Location
Requirement The system shows ground location in which the match is going to be
played.
Source Supervisor
Rationale Players will easily get information of venue of the map using google
maps. It will help them reach ground locations and save time.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.28 Report Player

Identifier FR-028
Title Report
Requirement The functionality will allow to report misconduct.
Source Supervisor
Rationale Player/ground manager can report any misbehavior, so that strict action
could be taken to limit the violators account.
Business Rule (if
required)
Dependencies FR-002,FR-012
Priority High
4.29 Report Ground Management

Identifier FR-029
Title Report
Requirement The functionality will allow to report misconduct.
Source Supervisor
Rationale Player can report any misbehavior on part of the ground management, so
that strict action could be taken to limit the violators account.
Business Rule (if
required)
Dependencies FR-002,FR-012
Priority High
4.30 Fetch Leagues Data

Identifier FR-030
Title Fetch Leagues Data
Requirement The system shall fetch data from API, which will provide league scores
and table standings.
Source Supervisor
Rationale
Business Rule (if
required)
Dependencies FR-002
Priority Medium
4.31 Get Location from Google API

Identifier FR-031
Title Google Location Services
Requirement The system shall provide live location to user on google map, so that they
can check grounds in their areas.
Source Supervisor
Rationale
Business Rule (if Players will easily get information of venue of the map using google
required) maps. It’ll help them reach ground locations and save time.
Dependencies FR-002
Priority Medium
4.32 Gmail Authentication for Sign-Up/Login via Passport

Identifier FR-032
Title Gmail Authentication
Requirement Passport module will authenticate the user using OpenAuth strategy.
Passport will send user credentials from server to google for
authentication.
Source Supervisor
Rationale This ensures user to register themselves using their present account of
Gmail.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.33 Facebook Authentication for Sign-Up/Login

Identifier FR-033
Title Facebook Authentication
Requirement Passport module will authenticate the user using OpenAuth strategy.
Passport will send user credentials from server to Facebook for
authentication.
Source Supervisor
Rationale This ensures user to register themselves using their present account of
Facebook.
Business Rule (if
required)
Dependencies FR-002
Priority High
4.34 Check Account Information

Identifier FR-034
Title Check Account
Requirement The system shall check account before a player carries out a transaction.
System will keep check if sufficient funds are in account or not.
Source Supervisor
Rationale This ensures players to book grounds instead of meeting with ground
management in person.
Business Rule (if User must have a valid account integrated with the system.
required)
Dependencies FR-002
Priority High
4.35 Logout
Identifier FR-035
Title Logout
Requirement The system allows the player/ground manager to logout of the system.
Source Supervisor
Rationale This ensures system security and credibility. Someone might misuse
account if not logged out.
Business Rule (if
required)
Dependencies FR-002
Priority High
5. Non Functional Requirements

5.1 Usability
USE-1: Because of user-friendly interfaces, the user will have a self-explanatory interface to
perform the required task. Power user should take 1-2 hours to understand the basic functionality of
the website. While lay user should take 1-2 days training to understand the basics of our web and
mobile application. UI of the application will be based on Jakob Neilsen’s 10 Heuristics for
interface design. It will provide users control, freedom, consistency and error prevention.
5.2 Security
User information shall be kept secure using REST architecture and two-way authentication. System
shall prevent SQL-injection because of the architecture and coding standards used.
5.3 Reliability
By using good exception handling techniques users will be able to use a robust application.
6. References
https://footyaddicts.com/
https://www.forzafootball.com/
https://www.fansrepublic.com/
https://www.fubles.com/

Software Requirements Specification For: COMSATS University Islamabad, Park Road, Chak Shahzad, Islamabad Pakistan

Uploaded by

Copyright:

Available Formats

Software Requirements Specification For: COMSATS University Islamabad, Park Road, Chak Shahzad, Islamabad Pakistan

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirements Specification For: COMSATS University Islamabad, Park Road, Chak Shahzad, Islamabad Pakistan

Uploaded by

Copyright:

Available Formats

COMSATS University Islamabad,

Park Road, Chak Shahzad, Islamabad Pakistan

Bachelor of Science in Computer Science (2015-2019)

Application Evaluation History

Comments (by committee) Action Taken

2.2 Operating environment

2.3 Design and implementation constraints

3. Requirement identifying technique

3.2 Use case description

Use Case UC-1.1

Exceptions: 1. If player enters invalid username.

• Show error message.

Use Case UC-1.2

Alternative Flows: 1. Player clicks on forgot password.

• Prompt player to accept terms and conditions.

Use Case UC-1.3

Postconditions: 1. Player is signed in and directed to home screen.

Use Case UC-1.4

Trigger: Player clicks on forgot password button.

Postconditions: 1. The password is reset.

Exceptions: 1. Player enters invalid email id.

Use Case UC-2.1

Use Case UC-2.2

Exceptions: Match is in progress

Use Case UC-2.3

Exceptions: Number of players exceeds the total number of available players.

Use Case UC-2.4

Exceptions: 1. Number of players exceeds the total number of available

Use Case UC-2.5

Exceptions: 1. Player gives wrong input of time and place.

Use Case UC-2.6

Exceptions: 1. Match is in progress

Use Case UC-3.1

Use Case UC-3.2

Use Case UC-4.1

Exceptions: 1. Player gives invalid input.

Use Case UC-4.2

Exceptions: 1. Player gives invalid input.

Use Case UC-4.3

2. Select the tournament to be deleted from the list of his ongoing

Exceptions: 1. Tournament to be deleted is in progress.

Use Case UC-4.4

Exceptions: 1. Player enters wrong/invalid input.

Use Case UC-4.5

Postconditions: 1. Teams will be able leave tournaments.

Exceptions: 1. Player enters wrong/invalid input.

Use Case UC-5.1

Use Case UC-5.2

Use Case UC-5.3

Use Case ID: UC-6.1

Use Case UC-6.2

Use Case UC-6.3

Use Case UC-7.1

Use Case UC-7.2

Use Case UC-7.3

Use Case Newsfeed Selection

Use Case UC-7.4

Use Case UC-8.1