Requirements

Glossary

• Achievement: Earnable success token that displays the completion of a course or other general accomplishments.
• Activity: User behaviour including creating on enrolling in courses, earning badges and achievements. Displayed on user profile for public users.
• Administrator: User with additional priveleges in a course, determined by the course creator.
• Annotate: To supply with critical or explanatory notes; comment upon in notes.
• Authentication: The steps of establishing identity and verifying permission to access the platform.
• Avatar: A static image that acts as a visual representation for the user.
• Bio: A short text field edited by the user that is displayed on the user profile page.
• Comment: A text of feedback provided with the rating when evaluating a course.
• Course: A prescribed number of chapters, lectures and learning material in a particular field of study.
• Evaluation: Rating and feedback given about lectures by users who participated as learners.
• Event: In-person meetings organised by the lecturer of a course, displayed on the course page. Includes geolocation, date, duration and person capacity.
• Filter: An algorithm that categorizes, sorts, prioritizes, or blocks data through rule-based protocols.
• Follow: Establish contact with another user in order to get in touch more easily and view their activities.
• Forum: Communication platform provided within the course in order for the learners and the lecturer to interact.
• Highlight: To emphasize or make prominent.
• Inactivity: Lack of app use or interaction for a continuous amount of time.
• Incomplete: A temporary grade indicating that a learner has not fulfilled one or more of the essential requirements for a course.
• Interface: Graphic display of the application that makes it easier for use.
• Knowledge base: A store of information or data that is available to draw on.
• Learner: User enrolled in a course.
• Lecture: A single part of the course that contains learning materials that will be used together.
• Lecturer: The user that created the course, is responsible for uploading educative content and has admin privileges.
• Message: A piece of information that is sent through Forum which contains letters and emojis.
• Milestone: A significant point of progress that is reached in a course.
• Note: A text of comment or explanation created by the user.
• Poll: List of questions with options to choose from and no correct answer.
• Private: A piece of information that can only be seen by chosen users.
• Profile Page: Special page created for each user that contains their information.
• Progress: A state showing how many chapters in a lesson has been completed.
• Public: A piece of information that can be seen by all users.
• Quiz: A special type of poll containing questions with a determined correct answer.
• Reputation: Overall representation of how well a user's courses have been rated.
• Semantic Search: Semantic search is an alternative to the lexical search where contextual meaning is used to improve the accuracy of the results.
• Strong password: A password that is made of at least 6 characters, and contains at least one letter and one number.
• Tag: Label used to categorize or identify content.
• Typeface: Design of the lettering that can include variation in size, weight, slope, width etc.
• User: A person utilizing the application.

---

Requirements

1. Functional Requirements

1.1. 🧍 User Requirements

1.1.1. 🔑 Authentication

1.1.1.1. Signup

• 1.1.1.1.1. Guests shall enter an unused username, an unregistered email address, and a strong password to signup.
• 1.1.1.1.2. Guests shall agree to the privacy policy and terms&conditions to signup.

1.1.1.2. Login

• 1.1.1.2.1. Users shall provide their usernames and passwords to log in.

1.1.1.3. Email Verification

• 1.1.1.3.1. Users shall enter the received verification codes (via their registered email addresses) to complete the email verification process.

1.1.1.4. Forgot Password

• 1.1.1.4.1. Users shall first enter the email addresses they signed up with and then the verification code they received.
• 1.1.1.4.2. Users shall enter a new password if the verification code is matched so that the old password is replaced with the new one.

1.1.1.5. Logout

• 1.1.1.5.1. Users shall be able to log out.

1.1.1.6. Change Password

• 1.1.1.6.1. Users shall be able to change their passwords by verifying their emails.

1.1.2. 🗿 Profile Page

• 1.1.2.1. Users shall have a profile page.
• 1.1.2.2. Users shall be able to edit their profile page.
• 1.1.2.3. Full name of the users shall be able to seen on their profile pages.
• 1.1.2.4. Users shall have an avatar.
• 1.1.2.5. Users shall be able to change their avatars.
• 1.1.2.6. Users shall have a bio in their profile pages.
• 1.1.2.7. Users shall have a "My Events" section on their profile pages.
• 1.1.2.8. Users who are qualified as "Lecturer" will see the events they have organized on their "My Events" section with the headline: "You are the organizer!".
• 1.1.2.9. Users who are qualified as "Learners" will see the events they are participating in on their "My Events" section with the headline: "You are participating!".

1.1.2.10. Interests and Knowledge

• 1.1.2.10.1. Users shall identify their interest areas and display them in their profile pages.
• 1.1.2.10.2. Users shall view the knowledge base, consisting the courses, they have successfully completed.
• 1.1.2.10.3. Users shall view the total number of badges they have earned for each course in their knowledge base.
• 1.1.2.10.4. Users shall view the total number of completed courses and earned badges in their knowledge base.

1.1.2.11. Achievements

• 1.1.2.11.1. Users shall view the achievements they earned from the courses they have studied in the achievements section of their profile pages.
• 1.1.2.11.2. Users shall be able to change the achievements, which are displayed in the achievements section of their profile pages.
• 1.1.2.11.3. Users shall be able to view the most rare achievement they have earned based on the earning rate of this achievement across the whole platform, from the achievements section.

1.1.2.12. Learner Profile

1.1.2.12.1. Progress Tracking

• 1.1.2.12.1.1. Users shall keep track of their progress in each course from their profile page.
• 1.1.2.12.1.2. Users shall view both the completed and incomplete courses with their completeness status in the progress tracking section.

1.1.2.12.2. Lecture Notes

• 1.1.2.12.2.1. Users shall view their notes taken from the courses in the lecture notes section of their profile pages.
• 1.1.2.12.2.2. Users shall view the most recent time of edit for each lecture note.

1.1.2.12.3. Annotations

• 1.1.2.12.3.1. Users shall access the annotations they have added for course material from the annotations section of their profile pages.
• 1.1.2.12.3.2. Users shall be able to browse their annotations by category, by course, by history, and by upvotes they have received.
• 1.1.2.12.3.3. Users shall be able to see how many annotations they have and from how many categories, from how many courses and the total number of upvotes they have received.

1.1.2.13. Lecturer Profile

1.1.2.13.1. Courses and Reputation

• 1.1.2.13.1.1. Users shall be able to see the courses they have provided teaching material as a lecturer and their reputation in their profile pages.
• 1.1.2.13.1.2. Users shall view the cover photo, a basic bar chart that shows the rate of stars and the average rating they have received for each course in the lecturer profile section.
• 1.1.2.13.1.3. Users should be able to enroll a course, which is provided by the owner of the profile page from the lecturer profile section.

1.1.2.13.2. Recommendation

• 1.1.2.13.2.1. Users shall be able to see the feedback they have received for the courses they provide teaching material in the recommendations section.
• 1.1.2.13.2.2. Users shall be able to view comment and star rating for each feedback, alongside the commentator’s name and first letter of their surname, a basic profile picture with their initials, and the name of the course.

1.1.3 👩🏼‍💻 User Interaction

1.1.3.1. User-User Interaction

• 1.1.3.1.1. Users shall see each others profiles.
• 1.1.3.1.2. Users shall be able to follow each other.
• 1.1.3.1.3. Users shall see the information of people they follow; achievements and activities.
• 1.1.3.1.4. Users shall be able to share notes with each other.
• 1.1.3.1.5. Users shall be able to block other users.
• 1.1.3.1.6. Users could prevent other users to see their profile by blocking them.

1.1.3.2. User-Lecture Interaction

1.1.3.2.1. Creating Lectures

• 1.1.3.2.1.1. Lectures shall be given a unique title during creation.
• 1.1.3.2.1.2. Lecturer shall state the lectures topic in a specified field for sake of categorization.

1.1.3.2.2. Editing Lectures

• 1.1.3.2.2.1. Lecturer shall be able to edit lecture material.
• 1.1.3.2.2.2. Lecturer shall be able to delete lectures.
• 1.1.3.2.2.3. Lecturer should be able to set a part of the lecture as hidden to be able to edit in different times.

1.1.3.2.3. Taking Lectures

• 1.1.3.2.3.1. Users shall see the content within sections as lecturer intended.
• 1.1.3.2.3.2. Users shall navigate in lecture material.
• 1.1.3.2.3.3. Users shall see which parts of the lecture they completed.
• 1.1.3.2.3.4. Users shall know type of the poll they are participating in beforehand.
• 1.1.3.2.3.5. Users shall receive confirmation of their expertise on the topic upon completion of a lecture.
• 1.1.3.2.3.6. Users shall be able to review lectures by giving stars and optionally providing feedback.
• 1.1.3.2.3.7. Users may need to complete some polls for unlocking some sections of the lecture.

1.1.3.2.4. Notes and Annotation

• 1.1.3.2.4.1. Each user shall have his/her notes section under each lecture.
• 1.1.3.2.4.2. User shall create and edit notes under notes section via typing.
• 1.1.3.2.4.3. User shall be able to mention other notes from other lectures or/and other users in his/her.
• 1.1.3.2.4.4. Users shall annotate lecture content by matching lecture content to notes.
• 1.1.3.2.4.5. Users shall connect, annotate and tag notes.

1.1.3.2.5. Community Events

• 1.1.3.2.5.1. Users who are qualified as lecturers shall create community events.
• 1.1.3.2.5.2. Created events shall only be available to currently enrolled learners.
• 1.1.3.2.5.3. Created events are only specified for various courses, which means some courses may not have an event-creating ability.
• 1.1.3.2.5.4. Created events have a specific date, duration, and limit for the number of participants.
• 1.1.3.2.5.5. Lecturers can give a brief description of the topics of discussion for the event.
• 1.1.3.2.5.6. Lecturers are able to cancel events that they have created.
• 1.1.3.2.5.7. Created events will be visible on the course info page along with the date, duration, and the number of participants.
• 1.1.3.2.5.8. Enrolled students will be able to notify that they will be joining community events with a button click.
• 1.1.3.2.5.9. The number of students who will join the event will be visible to both lecturers and students.

1.1.4 📝 Lecture Structure

• 1.1.4.1. Lectures shall deliver lecture material in text, images, and embedded videos.
• 1.1.4.2. Lectures shall have an Introduction where the lecturer presents the lecture in a text.
• 1.1.4.3. Lecturers shall be able to place quiz polls before a section of lecture.
• 1.1.4.4. Lectures shall have a main page where users can see introduction, events, sections, notes, annotations, and polls.

1.1.5 🛂 Administration

• 1.1.5.1. Admin shall evaluate reports and takes action accordingly.
• 1.1.5.2. Admin shall be able to ban users permanently and temporarily.
• 1.1.5.3. Admin shall be able to view all contents.
• 1.1.5.4. Admin shall be able to remove any content.

1.2. 💻 System Requirements

1.2.1. 💡 Recommendations

• 1.2.1.1. Users will get various courses as recommendations.
• 1.2.1.2. These recommendations will be based on users' preferences about the topics of courses. Courses that have similar topics will be chosen to recommend.
• 1.2.1.3. The recommendations will be displayed on the courses' page.

1.2.2. 🔔 Notifications

• 1.2.2.1 Users shall get notifications from the system.
• 1.2.2.2 The system shall notify users regarding incoming messages from their communication channels.
• 1.2.2.3 The system shall notify users when other users share notes with them.
• 1.2.2.4 The system shall notify learners when they achieve a milestone regarding their progress with respect to a course.
• 1.2.2.5 The system shall notify learners that they should give feedback about their lecturers whose course they have completed recently.
• 1.2.2.6 The system shall notify users when other users invite them to an organized in-person meeting.
• 1.2.2.7 The system shall notify learners when lecturers create polls to help them contribute to some decisions taken during the lecture.
• 1.2.2.8 The mobile app system shall notify mobile users in such a way that they are kept engaged.
  • 1.2.2.8.1 The system shall send a notification to the users who do not open the app for at least 1 day.
• 1.2.2.9 Users shall be able to switch their notifications on or off.
• 1.2.2.10 The system shall notify users when other users follow them.
• 1.2.2.11 The system should notify users about other users they follow.
  • 1.2.2.11.1 These notifications should be on the activities or accomplishments of the people they follow.

1.2.3. 🔎 Searching and Browsing

• 1.2.3.1 The system shall implement semantic searching.
• 1.2.3.2 The system shall allow users to search for other users.
  • 1.2.3.2.1 The system shall allow searching for users by their username.
  • 1.2.3.2.2 The system should suggest users based on full name when search query gives no result for usernames.
• 1.2.3.3 The system shall allow users to search for courses.
• 1.2.3.4 The system shall offer filters for search results.
  • 1.2.3.4.1 The system shall allow users to filter search results as only users or only courses.
• 1.2.3.5 The system shall allow users to browse for recommended courses.
• 1.2.3.6 The system shall allow users to browse for courses offered by a lecturer on the lecturer user's profile page.
• 1.2.3.7 The system shall allow users to browse their notes.
• 1.2.3.8 The system shall allow users to browse for notes filtered by their tags.
• 1.2.3.9 The system shall allow users to browse the activities and achievements of users they follow on the user's profile page.

1.2.4. 📝 Lectures

• 1.2.4.1. The system shall set the user created the lecture as the lecture’s lecturer.
• 1.2.4.2. Newly created lectures, chapters, and sections shall set as private initially as long as the lecturer states otherwise.

1.2.5. 💬 Chat

• 1.2.5.1. The chat features should be unique to the lecture. There is no common channel for the entire community.
• 1.2.5.2. Learners can be in contact with lecturers through chat.
• 1.2.5.3. The chat should include the feature of creating events.
• 1.2.5.4. The chat should include a timestamp for each message and the senders' name should be at top of the each message.
• 1.2.5.5. The sender's name should direct the user to his/her profile page.
• 1.2.5.6. The chat messages should be stored.

1.2.6. 🏁 Almost Done

• 1.2.6.1. System shall allow users to optionally provide additional information about their full names, birth date, state of education, gender just after the signup stage.
• 1.2.6.2. System should allow users to select educational topics, and titles which they are interested in in the almost done stage.

1.2.7. 🗑️ Delete Account

• 1.2.7.1. System shall allow users to delete their accounts.
• 1.2.7.2. All personalized information about the deleted users have to be anonymized or completely deleted according to the privacy policy that will be determined later on.

1.2.8. 🗒️ Annotations

• 1.2.8.1. Users shall be able to create annotations.
• 1.2.8.2. Annotations should comply to the W3 Web Annotation Data Model.
• 1.2.8.3. Owner of the annotations shall be able to set annotations as public or private.
• 1.2.8.4. Created annotations shall be reachable from both profile page and relevant target resource(s).
• 1.2.8.5. Annotations may have a body attribute.
• 1.2.8.6. Annotations shall have a target attribute.
• 1.2.8.7. Annotations may have more than one body attribute and may have more than one target attribute.
• 1.2.8.8. Annotations with public visibility should be listed on that annotation's creator's profile page.

2. Non-Functional Requirements

2.1. 🔓 Availability and Accessibility

• 2.1.1. System should have both a Web interface and an Android application. These two interfaces must provide same features but different interactions.
  • 2.1.1.1. Mobile App should be designed to keep mobile users engaged.
• 2.1.2. System should support UTF-8 character encoding.
• 2.1.3. System should support English and Turkish languages.

2.2. 🔏 Privacy

• 2.2.1. Ethical concerns must be considered, so system must follow the rules defined by GDPR/KVKK.
  • 2.2.1.1 A well-defined explanation about how users data will be used must be given to users.
  • 2.2.1.2 Users must agree to the Privacy Policy and User Agreement.
  • 2.2.1.3 If any change happens in the policy, users must be notified about it.
• 2.2.2. Lectures can be private or public. If a lecture is private, its content should not be visible to every user in the app.

2.3. 🛡️ Security

• 2.3.1 All sensitive data shall be encrypted before storing.
• 2.3.2 HTTPS protocol is required in order to access web application.
• 2.3.3 The system shall block the account if any security issue is observed.

2.4. 🔧 Performance and Reliability

• 2.4.1 The system should be able to handle at least 10.000 users and 500 user actions simultaneously.
• 2.4.2 The system should have a response time of at most 2.0 seconds excluding network based delay.

2.5. 🧩 Usability

• 2.5.1 The system should provide a user-friendly interface. It should contain a basic site map and should not contain a confusing linking system.
• 2.5.2 The system should place more important things like headers or logos in the top left corner. The logo serves as a landmark that orients users when they first land on a page and helps them identify the website they are visiting.
• 2.5.3 The system should provide a direct feedback mechanism. The moment people interact with the system, we should offer an indication of the success or failure of their actions.
• 2.5.4 The system should have a well-chosen typeface that should be readable and clean without diverting too much attention from the rest of the design.

2.6. 🌋 Disaster Recovery

• 2.6.1 The system should get backups and send them off-site at regular intervals for the possibility of disasters.
• 2.6.2 When the disaster occurs, the backup protocol should be activated; the last taken backup will be uploaded and the site will be updated in a short time.