-
Notifications
You must be signed in to change notification settings - Fork 2
Final Software Requirements
yektaercul edited this page May 19, 2024
·
2 revisions
- 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.
- Global Post: A post that is not posted inside a community. (Previously Non-Community Post)
- 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.
- Feed: A list of posts that are filtered and ordered in a certain way.
-
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, 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.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.4 Change their profile picture.
-
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.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 global post.
- 1.1.4.2 Posts shall be able to have at no character limits and a single image with a size limit of 4MB.
- 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 global 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.5.3 Bookmark a 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.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.4 User's latest posts and comments.
-
1.1.7 Searching and Filter
- 1.1.7.1 Users shall be able to search by semantic search.
- 1.1.7.2 Users shall be able to see specific team's post in their corresponding community.
-
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, body and an indicator of in which community or globally they posted.
-
1.2.3 Community Pages
- 1.2.3.1 The system shall have a user independent community page section where the following are displayed:
- 1.2.3.1.1 Information of the team such as name, description fanatic count, logo and posts that are posted in there as a dynamic content from backend.
- 1.2.3.1 The system shall have a user independent community page section where the following are displayed:
-
1.2.4 Feed
- 1.2.4.1 The system shall filter the posts by the user and shows the feed as the home page.
- 1.2.4.2 The feed shall be refreshable.
- 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.1 The application shall protect personal and contact information with respect to GDPR regulations, including copyright and licensing issues.
- 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.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
🏠Home
- Third Customer Milestone Report
- RAM
- Requirements
- Mockups
- Sequence Diagrams
- Use Case Diagram
- Class Diagrams
- Scenarios
- User Scenario
- User Manual
- System Manual
- Third Customer Milestone Report
- Second Customer Milestone Report
- First Customer Milestone Report
- RAM
- Requirements
- Mockups
- Sequence Diagrams
- Scenarios
- Use Case Diagram
- Class Diagrams
- Software Quality Plan
- Milestone1 Presentation Scenarios
- Post Creation Page
- User Scenario
- Meeting Notes 10 - Dec 10
- Meeting Notes 9 - Dec 3
- Meeting Notes 8 - Nov 17
- Meeting Notes 7 - Nov 12
- Meeting Notes 6 - Nov 5
- Optional Meeting Notes 1 ‐ Oct 21
- Meeting Notes 5 - Oct 15
- Meeting Notes 4 - Oct 8
- Meeting Notes 3 - Oct 3
- Meeting Notes 2 - Oct 1
- Meeting Notes 1 - Sep 24
- Deniz Ulaş Poyraz
- Eren Donmez
- Ersel Çanakçılı
- Oğuz Kağnıcı
- Onur Çerli
- Yekta Ercul
- Ali Alperen Sönmez
- Huseyin Turker Erdem
- Mehmet Tuluyhan Sozen
352 Material
- Final Milestone Report
- Milestone 2 Report
- RAM
- Use Case Diagram
- Sequence Diagrams
- Class Diagrams
- Requirements
- Elicitation Questions
- Mockups
- Scenarios
- Milestone 1 Report
- Our Favourite Repositories
- Linked Data and SPARQL
- Web Application Development
- API Development and Utilization
- Wikidata and Wikidata API
- Mobile Application Development
- Android Studio
- Git
- Meeting Notes 10 ‐ May 10th
- Meeting Notes 9 ‐ Apr 25th
- Meeting Notes 8 ‐ Apr 21st
- Meeting Notes 7 ‐ Apr 12th
- Meeting Notes 6 ‐ Mar 14th
- Meeting Notes 5 ‐ Mar 11th
- Meeting Notes 4 - Mar 7th
- Meeting Notes 3 - Mar 3rd
- Meeting Notes 2 - Feb 22nd
- Meeting Notes 1 - Feb 18th