Requirements - bounswe/bounswe2023group4 GitHub Wiki
Glossary
Will be discussed in further meetings
Definitions
- Account: A set of platform related information with unique e-mail address.
- Guest: A person who didn't signed up to the system.
- Poll: A poll is a method of collecting data or opinions from a group of individuals. A poll is considered active if its result is not yet determined.
- Profile: Number of information that user has allowed to be shared.
- Tag: Keywords used to categorize polls.
- User: A person who signed up to the system.
Project Requirements
1. Functional Requirements
1.1 User Requirements
1.1.1 Guests
- 1.1.1.1 Guests shall be able to see polls.
- 1.1.1.2 Guests shall not be able to create polls.
- 1.1.1.3 Guests shall not be able to vote in any polls.
- 1.1.1.4 Guests shall be able to see other user's profile.
- 1.1.1.5 Guests shall be able to give feedbacks to developers.
- 1.1.1.6 Guests shall not be able to add friends.
1.1.2 Authentication
-
1.1.2.1 Sign up
- 1.1.2.1.1 Users should be able to sign up with an unused e-mail, unused nickname and a password.
- 1.1.2.1.2 Passwords determined by users while signing up shall be at least 8 characters and shall contain at least three of the following:
- Lower case letters (a-z)
- Upper case letters (A-Z)
- Numbers (0-9)
- Special characters (e.g. [email protected]#$%^&*)
- 1.1.2.1.3 Users should get a verification mail to their e-mail address when they sign up.
- 1.1.2.1.4 Users should be able to sign up with google.
- 1.1.2.1.5 Users shall accept the KVKK terms to sign up.
-
1.1.2.2 Sign in
- 1.1.2.2.1 Users should be able to sign in with their username/email and password if they have verified their e-mail via the verification mail stated in requirement 1.1.2.1.3.
- 1.1.2.2.2 Users should be able to sign in with google.
1.1.3 Profile
- 1.1.3.1 Users shall have a profile page which they can display their name, username, profile picture, bio, polls that they created, or they voted for, and achievements.
-
1.1.3.2 Users shall have a profile page which includes the visible information about the user
- 1.1.3.2.1 Users shall have an option to hide their information except the username.
- 1.1.3.2.2 Users shall have an option to decide which of their actions will be displayed in their profile.
1.1.4 Users
-
1.1.4.1 Users shall be able to post polls.
- 1.1.4.1.1 Each poll must have a question.
- 1.1.4.1.2 Each poll must accept either multiple-choice inputs, or customized, such as date-time, integer, etc., input whose type is determined by the poll creator.
- 1.1.4.1.3 A poll might have a due date at which the answer will be determined.
- 1.1.4.1.4 A user shall pay 5 * daily gained points, from his/her prediction scores, to open a poll.
- 1.1.4.1.5 A user shall be banned from opening polls for one day if one of his polls is reported and removed by jury.
- 1.1.4.2 Users shall be able to add friends by sending friend requests.
- 1.1.4.3 Users shall be able to share their achievements on their social media platforms.
- 1.1.4.4 Users shall be able to share any poll on their social media platforms.
- 1.1.4.5 Users shall be able to vote on active polls.
- 1.1.4.6 Users shall be able to express their views in the comment section of the poll.
- 1.1.4.7 Users shall be able to decide on the visibility of vote distribution of their polls to other users.
-
1.1.4.8 Users (TBD) shall be able to partake in a jury to verify the correctness of a poll.
- 1.1.4.8.1 Users shall be able to report if the poll has an incorrect label.
- 1.1.4.8.2 Users shall not be able to partake in the jury that will verify the correctness of the poll if they already voted for that poll.
- 1.1.4.8.3 Users shall not be able to vote for the poll if they participated in the jury that verified the poll’s correctness.
- 1.1.4.8.4 Users shall receive points from participating in the jury. The points received will be determined by the system and is explained in system requirements.
-
1.1.4.9 Poll owner shall be able to send a request to finish the poll to the system.
- 1.1.4.9.1 Each finish request must contain a suggested answer.
- 1.1.4.10 Users shall be able to receive points from the one and only true guess in the case of multiple-choice polls, or nearly true guesses, in the case of customized input polls. The points received is explained in the system requirements.
1.1.5 Polls
-
1.1.5.1 Poll Opening
- 1.1.5.1.1 User shall pay poll opening fee.
- 1.1.5.1.2 User shall enter the poll question.
- 1.1.5.1.3 User shall choose a final voting date or vote change acceptance time -the time that system takes to accept a vote changing process -.
- 1.1.5.1.4 User shall choose poll type as discrete or continuous.
- Discrete Poll Opening
- 1.1.5.1.5 User shall choose the number of the options.
- 1.1.5.1.6 User shall fill every option.
- Continuous Poll Opening
- 1.1.5.1.7 User shall choose the input type.
-
1.1.5.2 Poll Vote Change
- 1.1.5.2.1 User shall be able to change their vote, which changes the option where the user's general points reside.
- 1.1.5.2.2 If the poll has a final voting date, system shall accept user's vote change immediately.
- 1.1.5.2.3 If the poll has a vote change acceptance time, system shall accept user's vote change after the vote change acceptance time has passed.
1.2 System Requirements
1.2.1 Polls
- 1.2.1.1 System shall tag the polls depending on their content.
- 1.2.1.2 System shall periodically notify the poll owners that created polls with no due dates to check if the poll should be ended.
- 1.2.1.3 System shall close the polls with no due dates if the owner of the poll has been inactive for a long time (TBD).
1.2.2 Grading
- 1.2.2.1 System shall grant points to the users (TBD) according to the proximity of their voting time to the poll posting time.
- 1.2.2.2 System shall grant points (TBD) to the users if they partake in the jury.
- 1.2.2.3 Polls with indefinite due dates shall not be subject to linear incremental grading. (TBD)
- 1.2.3.4 System shall award points to users based on the accuracy of their guesses in continuous polls. The closeness is defined as the absolute difference between the guess and the result. The procedure is as follows:
There are 3 possibilities for distribution of the users:
1- The user can be at top 50% (imagine the sorted list of users with respect to worst to best guess. The users that are right of the median are the top %50 or at the median).
2- The user can be at bottom 50%.
3- Everyone can make the same guess.
If the user is at top 50%: The user will get his/her deposited points back. Top 50% will be divided into 4 parts:
- The bottom 25% part will share %5 of the points of the losers.
- The next better division will share %15 of the points of the losers.
- The next better division will share %25 of the points of the losers.
- The top %25 division will share %45 of the points of the losers.
- Remaining 10% of the points will be burned to prevent point inflation.
- If there is a tie between users in the top 50%, the rewards will be split among the tied users starting from the best-performing division (i.e., the top 25%).
Users will share points proportional to their deposited points.
The bottom 50% part will be the losers. They will lose all their deposited points.
If everyone makes the same guess, the deposited points will be given back. No losers or winners.
2. Non-Functional Requirements
2.1 Portability and Compatibility Requirements
- 2.1.1 The website shall be able to run on Google Chrome, Yandex, Safari, Internet Explorer and Firefox without any extra work, any failure regarding its specified performance and scalability requirements and any change in its behavior.
- 2.1.2 The application shall be able to run on Android API 24 and later versions without any extra work and change in the behavior.
- 2.1.3 The application shall be able to run on iOS 16.0 and later versions without any extra work and change in the behavior.
2.2 Performance and Scalability Requirements
- 2.2.1 The website's page load time shall be maximum 6 seconds.
- 2.2.2 The website's page load time should be under 3 seconds on average.
- 2.2.3 The website should have an average response time between 0.1 - 1 second.
2.3 Reliability, Maintainability, Availability Requirements
The Reliability, Maintainability, Availability requirements will be decided at the further stages of the project.
2.4 Security Requirements
- 2.4.1 An unauthorized access to admin panel shall be blocked by defining different login flows and different user roles as user actions.
- 2.4.2 All nicknames shall be different from each other.
- 2.4.3 KVKK provisions shall be applied.
2.5 Localization Requirements
These are localization requirements for Turkey. If our customer decides to enter other markets, suitable localization requirements will be applied.
- 2.5.1 The language of the website shall be Turkish.
- 2.5.2 The date format shall be date.month.year.
- 2.5.3 The context of the website shall be proper to the regulations of Turkey.
- 2.5.4 The website shall be able to show Turkish characters without any problem.
- 2.5.5 The sorting algorithms(if any) used on the website shall be according to Turkish alphabet.
2.6 Usability Requirements
Adequately trained users are considered to be the appropriate users for testable usability requirements.
- 2.6.1 Users should be adequately trained by aid of simple instructions when they are first sign-up to the website.
- 2.6.2 The appropriate user should be able to login to the system.
- 2.6.3 The appropriate user should be able to post a new poll.
- 2.6.4 The appropriate user should be able to predict on a poll.
- 2.6.5 The appropriate user should be able to personalize his/her profile.
- 2.6.6 Components in the page should have overlay description for special users.