CMPE 352 ‐ Requirements

Glossary

• User: A person that has logged in using their e-mail address and password.
• Guest: A person that has not logged in using their e-mail address and password.
• System Admin An administrative user role that is assigned by the developer team.
• Community: An entity that users can subscribe to. A community exists for each team in the Turkish Super League.
• Post: A body of content that users can publicly share with other users and guests.
• Non-Community Post: A post that is not posted inside a community.
• Comment: A body of content that users can publicly share, as a response to a post or to another comment.
• Profile: The personal page of a user.
• Static Pages: Informative pages that do not allow any interaction with users or guests.
• Feed: A list of posts that are filtered and ordered in a certain way.

1. Functional Requirements:

1.1 User Requirements

• 1.1.1 Registration and Login

  • 1.1.1.1 Guests shall be able to:

    • 1.1.1.1.1 Register using their unique e-mail address, unique username, password and the team which they support to become a member.

  • 1.1.1.2 Users shall be able to:

    • 1.1.1.2.1 Login using their e-mail address and password.
    • 1.1.1.2.2 Recover their account if they have forgotten their password.

• 1.1.2 Account Actions

  • 1.1.2.1 Users shall be able to:

    • 1.1.2.1.1 Update their password.
    • 1.1.2.1.2 Log out of their account.
    • 1.1.2.1.3 Change their username once a month.
    • 1.1.2.1.4 Change their profile picture.
    • 1.1.2.1.5 Delete their account.

  • 1.1.2.2 Users shall not be able to:

    • 1.1.2.2.1 Change the team they support.
    • 1.1.2.2.2 Change their e-mail address.

• 1.1.3 Communities (See "1.2.1 Communities")

  • 1.1.3.1 Users shall be able to subscribe or unsubscribe to any community.
  • 1.1.3.2 Users shall be able to create posts or interact with posts only in the community of the team they support. (See "1.1.4 Posts")

• 1.1.4 Posts

  • 1.1.4.1 Users shall be able to create posts only on the community of the team they support or post it as a non-community post.
  • 1.1.4.2 Posts shall be able to have at most 250 characters and a single image with a size limit of 25MB.
  • 1.1.4.3 Users shall be able to add tags to their own posts.
  • 1.1.4.4 Users shall be able to bookmark a post.
  • 1.1.4.5 If a post is in the users' team's community or it is a non-community post users shall be able to:
    • 1.1.4.5.1 Like or dislike a post.
    • 1.1.4.5.2 Write a comment to a post. (See "1.1.5 Comments")
  • 1.1.4.7 Users shall be able to tag other users in the post.

• 1.1.5 Comments

  • 1.1.5.1 Users shall be able to write comments to the posts in the community of the team they support.
  • 1.1.5.2 Comments shall contain at most 250 characters.
  • 1.1.5.3 Users shall be able to tag other users in the comment.
  • 1.1.5.4 Users shall be able to reply a comment with their comment.
  • 1.1.5.5 Users shall be able to like or dislike a comment if that comment belongs to the community of the team they support or the comment belongs to a non-community post.

• 1.1.6 Profile

  • 1.1.6.1 Users shall have a profile (personal page) visible to guests and users.
  • 1.1.6.2 At the profile, other users and guest shall be able to see:
    • 1.1.6.2.1 Users profile picture.
    • 1.1.6.2.2 The team user supports.
    • 1.1.6.2.3 People who follow the user and the people the user follows.
    • 1.1.6.2.4 User's latest posts and comments.

• 1.1.7 Searching

  • 1.1.7.1 Users shall be able to search by semantic search.
  • 1.1.7.2 Users shall be able to sort and filter posts with certain criteria.
  • 1.1.7.3 Users shall be able to use Wikidata API to add tags to posts.

1.2 System Requirements

• 1.2.1 Communities

  • 1.2.1.1 Each team in "Süper Lig" shall have a community of their own.
  • 1.2.1.2 Communities shall not be deleted or created by users.
  • 1.2.1.3 Users shall be automatically be subscribed to the community of the team they support.

• 1.2.2 Posts

  • 1.2.2.1 Posts shall have a title.
  • 1.2.2.4 Posts shall have tags.
  • 1.2.2.5 One of the tags shall be the community in which the post is posted.

• 1.2.3 Notifications

  • 1.2.3.1 Users shall be notified when one of the following happens:
    • 1.2.3.1.1 They are tagged in a post or a comment.
    • 1.2.3.1.2 One of their posts or comments has been liked.
    • 1.2.3.1.3 A new comment has been written to one of their posts.
    • 1.2.3.1.4 A new reply has been given to one of their comments.

• 1.2.4 Search and Filtering

  • 1.2.4.1 The system shall allow users to search posts, communities and users by semantic searching.
  • 1.2.4.2 The system shall allow users to filter search results using tags and filtering options.
  • 1.2.4.3 The system shall keep the search history of every user for better searching experience.
  • 1.2.4.4 The system shall allow the user to delete their search history.
  • 1.2.4.5 The system shall allow to opt-out history tracking.

• 1.2.5 Static Pages

  • 1.2.5.1 The system shall have a user independent static page section where the following are displayed:
    • 1.2.5.1.1 History of the team
    • 1.2.5.1.2 Link to the community of the team

• 1.2.6 Feed

  • 1.2.6.1 The system shall filter the posts by the user and shows the feed as the home page.
  • 1.2.6.2 The feed shall be refreshable.
  • 1.2.6.3 The feed shall be filtered by the user.

2. Non-Functional Requirements

2.1 Platforms

• 2.1.1 Application shall be available for both Web and Mobile platforms.
• 2.1.2 Web version of the application shall be compatible with widely used browsers. E.g. Google Chrome, Safari, Microsoft Edge, Mozilla Firefox
• 2.1.3 Mobile version shall be compatible with devices and OS versions with less then 5 years of age.

2.2 Privacy

• 2.2.1 The application shall protect personal and contact information with respect to GDPR regulations, including copyright and licensing issues.

2.3 Security

• 2.3.1 User authorization data shall be encrypted to ensure security.
• 2.3.2 The application shall enforce robust password protocols and assist users in generating secure passwords.

2.4 Performance

• 2.4.1 The application shall respond to user interactions within a maximum of 2 seconds for at least 90% of requests.
• 2.4.2 The application architecture shall be designed to accommodate an increase in user traffic by at least 100% without significant degradation in performance, which includes both horizontal and vertical scaling strategies.
• 2.4.3 Database queries shall be optimized and whole database should be normalized and designed carefully regarding the specific needs to ensure efficient data retrieval and processing. The application shall be capable of handling a large volume of concurrent database transactions without impacting response time.
• 2.4.4 The application shall implement caching mechanisms both on the backend and the frontend to reduce server load and improve response time for frequently accessed content. Cached data shall be refreshed periodically if it needs to ensure data consistency.
• 2.4.5 The application shall gracefully handle errors and exceptions to prevent downtime and maintain user experience. Error messages shall be informative, well-formatted and actionable to assist users in resolving issues efficiently.

draft made by Group 8 | prepared by Dağhan Erdönmez and Yekta Ercul