Skip to content

Software Requirements Specification (SRS)

Jump to bottom
irfanbozkurt edited this page May 9, 2021 · 42 revisions

Table of Contents

Revision History

Name Date Reason For Changes Version
Tolga Kerimoğlu 05.04.2021 Initial structure and draft of first two sections 1.0
Irfan Bozkurt 07.04.2021 Non-functional requirements 1.0
Tolga Kerimoğlu, Ece Dilara Aslan, İhsan Mert Atalay 07.04.2021 Initial system requirements 1.0
Berkay Gümüş, Mehmet Hilmi Dündar, Salih Furkan Akkurt 07.04.2021 Initial user requirements 1.0
Ece Dilara Aslan, Irfan Bozkurt, Mehmet Hilmi Dündar, Tolga Kerimoğlu, Yağmur Selek 08.04.2021 Initial glossary 1.0

1. Introduction

1.1 Document Purpose

The purpose of this document is to build an online system to support people who are interested in participating in amateur sports events.

1.2 Product Scope

Our platform aims to assist people in finding and participating nearby amateur sports events easily. The system will allow users to either share an event they are organizing to gather participants or to discover nearby events to potentially participate. Our goal is, above all, to provide a comfortable user experience along with bringing people together.

1.3 Glossary

Account: An identity created for a person in the system.
Activity History:A record of past events a user has attended/created.
Applier: The users who have requested to join a particular event.
Attendee: The users who have been selected to join a particular event.
Badge: A visual indicator of commendations or complaints that can be given to users by other users that is visible in a user's profile.
Comment: A user message about an event visible to any other user.
Event: Sports organizations conducted by the users. Identified by characteristics such as sports type, venue, number of participants etc.
Event Creator:A user who created an event visible in the application.
 Notification: A visual indicator notifying a user.
Register: Creating an account on the application using an email and password.
 Spectator: An attendee of an event who is not a player in the game.
Subscription: The mechanism of following other users to get notified when they create an event.
System: The collection of hardware, software and the network containing the application.
System Maintainer: A person managing the system, considering its health and maintainability.
Transaction History: A record of a users past monetary transactions.
User: Any person using the application.
User Profile: A customizable page containing information about a user.

1.4 Document Overview

Rest of this document will cover, in detail, the structure of the project, it's features and different types of requirements following the IEEE SRS documentation standards.

1.5 References

  • Project description provided to us by our instructors on Moodle
  • An SRS template you can find on our wiki

2. Product Overview

2.1 Product Perspective

This product is built by the students of the Fundamentals of Software Engineering course at Boğaziçi University per instruction of course instructors. It's a new, self-contained product. It offers an android based mobile and a web interface. On a high-level, a relational database will store the following information.

  • Users: Includes related information and details about each user registered in the system, such as their login info, kinds of sports they are interested in and their skill level. Also a reference to any active or past events they have created or participated in.

  • Events: Includes any information related to events that have been created, such as location, reference to the organizing user, type of sport/sports in contains, number of people who can participate, users who have applied to participate, users who have been selected to participate by the organizer.

  • Sports: Includes information about each type of sports that is recognized by the system, such as references to equipment related to it, analysis information of previous participants of the sport such as age, analysis information of previous events of the sport such as region and season and its popularity.

2.2 Product Functions

This section will be updated, ideally with a top level data flow diagram after the specifics have been decided upon.

2.3 Product Constraints

2.4 User Characteristics

Users of the system should be able to discover sports events nearby a given location, apply to participate in them, create events if they wish, find equipment for the sports they are interested in and just follow the event flow in general and get information about statistics of previous events and sports types.

Users should be able to do the following functions:

  • Register to the system
  • Discover potential sports events of interest based on time and location
  • Express interest in joining an event
  • Find equipment related to the sports they are interested in
  • See their activities based on analysis performed by the system. Activities about sports such as average age of participants, region and season can be viewed
  • Give badges to the players
  • Create events and make them available for people to apply for
  • Make decisions of who can participate and inform the appliers using the system
  • Select the type of sports event when creating an event
  • Specify the characteristics of an event if there is no matching option in the system
  • Provide information to other users over the system about events and individual competitions
  • Define badges for a given sport
  • Tag any item with semantic tags

2.5 Assumptions and Dependencies

List of requirements stated is subject to change depending on the progression of the course and requests of the course instructors/any changes in the project description.

2.6 Apportioning of Requirements

Not determined as of now.

3. Requirements

3.1 Functional Requirements

3.1.1 User Requirements

3.1.1.1 Sign in/up
  • 3.1.1.1.1 User shall include his/her name, username, password, e-mail during sign-up.
3.1.1.2 Profile
  • 3.1.1.2.1 User shall have interests with skill level, location, age and public badges shown on profile.
  • 3.1.1.2.2 User shall be able to see the private activity history.
  • 3.1.1.2.3 User shall be able to follow other users.
  • 3.1.1.2.4 User shall be able to get notifications of the events that the users they follow create.
3.1.1.3 Settings
  • 3.1.1.3.1 User shall be able to delete his/her account.
  • 3.1.1.3.2 User shall be able to customize notifications.
3.1.1.4 Creating events
  • 3.1.1.4.1 Any user shall be able to create events.
  • 3.1.1.4.2 Event creator shall provide location, date, duration, and type of an event when creating an event.
  • 3.1.1.4.3 Type of an event shall include its name, rules, number of people needed, required equipment, skill level.
  • 3.1.1.4.4 If the desired type cannot be found, user shall be able to use characteristics to define an event.
  • 3.1.1.4.5 Event creator shall be able to check the appliers' badges or related information for whether to accept them or not.
  • 3.1.1.4.6 Event creator shall select the attendees out of appliers.
  • 3.1.1.4.7 Event creator shall be able to create and give out badges to attendees.
3.1.1.5 Searching and attending an event
  • 3.1.1.5.1 User shall provide at least 3 kinds of sports and skill level for searching.
  • 3.1.1.5.2 User shall be able to search by location, date, type, people, skill level.
  • 3.1.1.5.3 User shall be able to apply to participate in or spectate an event.
  • 3.1.1.5.4 User shall be informed on whether he/she was accepted to the event.
  • 3.1.1.5.5 After the event, user shall be able to give badges defined by event creators to other people.
  • 3.1.1.5.6 Event creator shall be able to contact system maintainers for desired badge inclusion.
  • 3.1.1.5.7 User shall be able to comment on the event page.
3.1.1.6 Buying products and other services
  • 3.1.1.6.1 User shall be able to search for equipment sales by sport and location.
  • 3.1.1.6.2 User shall be able to check information of equipment sellers and read descriptions written by them.
  • 3.1.1.6.3 User shall be able to create equipment sale posts that include its description.

3.1.2 System Requirements

3.1.2.1 Sign in/up
  • 3.1.2.1.1 The system shall provide users with options to create a new account or sign-in to an existing.
  • 3.1.2.1.2 The system shall allow users to enter information about the kinds of sports they are interested in and their skill level while they are signing up.
  • 3.1.2.1.3 The system should allow users to recover their password by sending a password-recovery e-mail.
  • 3.1.2.1.4 The system shall verify the entered information before creating an account for registering users. Users who provide invalid information should not be allowed to create an account.
3.1.2.2 Search
  • 3.1.2.2.1 The system shall allow users to search for events, according to event name, location, sport, date.
  • 3.1.2.2.2 The system shall allow users to search for other users and view their location, schedule and interests if they have provided such information.
  • 3.1.2.2.3 The system shall allow users to search for other users by name, view their profile and follow other users.
  • 3.1.2.2.4 The system shall allow users to search for equipment for any sport they are interested in.
3.1.2.3 Events
  • 3.1.2.3.1 The system shall provide information about the events such as event name, location, date, sport and the number of players.
  • 3.1.2.3.2 The system shall maintain and provide analysis information about the events.
  • 3.1.2.3.3 The system shall allow users to request joining an event.
  • 3.1.2.3.4 The system shall allow users to create events by specifying event name, location, date, sport and the number of players.
  • 3.1.2.3.5 The system shall provide default sport types for the event creators to select from.
  • 3.1.2.3.6 If no matching sports type exist, the system shall allow event creators to specify the event characteristics.
  • 3.1.2.3.7 The system shall send a pop-up message after a user creates an event.
  • 3.1.2.3.8 The system shall allow users to cancel events they have created.
3.1.2.4 Recommendations
  • 3.1.2.4.1 The system shall recommend users events based on their location and sports they are interested in.
  • 3.1.2.4.2 The system shall recommend event creators other users based on their location, interests and schedules.
  • 3.1.2.4.3 The system shall recommend sport-related content(gadgets, clothing, tools, merchandise) to users for the sports they are interested in.
3.1.2.5 Notifications
  • 3.1.2.5.1 The system shall send notifications to event creators when a user sends a request to one of their events.
  • 3.1.2.5.2 The system shall send notifications to users who are accepted or rejected for that event.
  • 3.1.2.5.3 The system shall send notifications to users when one of the users they are following creates an event.
3.1.2.6 Badges
  • 3.1.2.6.1 The system shall allow users to give badges to others users who they have joined an event together with.
  • 3.1.2.6.2 The system shall allow event creators to give badges to users who have participated in their events.
  • 3.1.2.6.3 The system shall provide a default selection of customizable badges.
  • 3.1.2.6.4 The system should allow users to make requests for new badge types they would like to see available.
3.1.2.7 Interactions
  • 3.1.2.7.1 The system shall allow users to block other users.
  • 3.1.2.7.2 The system shall not allow users to view other users profiles who have blocked them.
  • 3.1.2.7.3 The system should allow users to leave comments on the events they have participated in.

3.2 Nonfunctional Requirements

3.2.1 Availability

  • 3.2.1.1 The system shall run as a web application, available through modern web browsers & an Android application.
  • 3.2.1.2 Cross-platform languages shall not be used implementing the system.
  • 3.2.1.3 The system language shall be English.

3.2.2 Standards

  • 3.2.2.1 The system shall follow W3C Activity Stream Standard 2.0 to implement subscriptions & notifications
  • 3.2.2.2 The semantic taggings should be supported with Wikidata.

3.2.3 Privacy

  • 3.2.3.1 Users shall accept a privacy policy during a sign-up, setting permissions on personal data.
  • 3.2.3.2 Users should be able to block each other, further specifying who can see their data.
  • 3.2.3.3 Users shall not be asked to grant any information besides than a name & an e-mail address.
  • 3.2.3.4 Data should be extracted out of what users share and allow to be visible, to analyze statistically and optimize user experience.
  • 3.2.3.5 User data shall be stored and processed according to General Data Protection Regulation(GDPR) and KVKK.

3.2.4 Security

  • 3.2.4.1 Users shall not be able to track transaction history of other users.
  • 3.2.4.2 System shall not be accessible through old versions of browsers.
  • 3.2.4.3 E-mail and password info for users shall be encrypted before storage.
  • 3.2.4.4 No user shall be granted admin permissions.

General

🏠 Home
📞 Communication Plan
📃 Weekly Efforts
📃 Fall21-Week 1

📑 Product Related

📋 Meeting Notes

🔍 Research

👥 Team Members

📁 Templates

Clone this wiki locally