Requirements Analysis

Glossary

Admin: A person who is responsible for the sustainability of the system.

Annotation: Explanatory content attached to an event compatible with W3C standards.

Comment: The response of users about activities of the other users or their profile, which can be voted by the others.

Community: A group of people sharing the same or similar interests and having communication or/and collaboration among themselves.

Database: An organized collection of data to store users' data safely.

Event: A cultural meeting that has a certain place and a specific time interval fields such as theater, cinema demonstration, opera, concert, book discussion, etc.

Event history: History of events which the user attends in the past, which is shown in his/her profile.

Follow: Users can follow the events attended by the specific user and his/her profile by this feature.

Google Maps API: Data gives you exact real-time information for locations, mapping, and navigation.

Guest: A person who is not registered and not having user privileges but viewing public pages.

Item: An article, an image or basically anything a user shares on the platform.

Password: Minimum 8 maximum 20 characters of a secret sequence used to identify a user and grant the user with member user abilities.

Profile: Profile: A number of specific information about a user containing his/her interests and events s/he attends.

Recommendation: Suggesting an event liked by a user to other users or recommending users to follow.

Sign-up: When a new user registers by giving intended personal information by the system.

System: The whole environment of the Cultidate Project including Web, Mobile, server-side, databases, cold storages.

Tag: A descriptive word or phrase to define an item defined and can be searched better.

User: A person who has an account on the community.

Username: User specific unique characters to identify a user.

Vote: The rating system allowing users to vote and comment the other users or events positively or negatively.

1. Functional Requirements

1.1. User Requirements

1.1.1 Member User Requirements

• 1.1.1.1 Sign-Up

  • 1.1.1.1.1 Users shall sign up by following one of the following procedures.
    • 1.1.1.1.1.1 Users shall provide a name, surname, username, password, e-mail address.
      • 1.1.1.1.1.1.1 Users shall verify their e-mail addresses by following the steps in the confirmation mail sent by the system.
      • 1.1.1.1.1.1.2 User emails and usernames shall be unique.
      • 1.1.1.1.1.1.3 Passwords shall be no shorter than 8 characters and no longer than 20 characters.
    • 1.1.1.1.1.2 Users shall sign up using their Facebook accounts.

• 1.1.1.2 Login

  • 1.1.1.2.1 Users shall login using their username and password.
  • 1.1.1.2.2 Users shall login using their Facebook account.

  • 1.1.1.2.3 Resetting Password

    • 1.1.1.2.3.1 In case of a user forget the account password, a password reset link is to be sent to the user's email address.
    • 1.1.1.2.3.2 A user who gets a reset link should be able to reset the password by going the unique link provided in the email.

• 1.1.1.3 Profile

  • 1.1.1.3.1 Users shall have a profile which includes but is not limited to their information bio, interests.
  • 1.1.1.3.2 Users shall be able to edit their profiles.

• 1.1.1.4 Contribution

  • 1.1.1.4.1 Users shall be able to create events.
  • 1.1.1.4.2 Users shall be able to follow events.
  • 1.1.1.4.3 Users shall be able to add photos to the events they created.
  • 1.1.1.4.4 Users shall be able to edit performing artist, location, date, price information of the events they created.
  • 1.1.1.4.5 Users shall be able to comment on events.
  • 1.1.1.4.6 Users shall be able to mark their attendance status to the events by choosing attend, will attend, maybe, won't attend, or block options.

• 1.1.1.5 Messaging

  • 1.1.1.5.1 Users shall be able to send private messages to other users unless at least one of the messaging parties is blocked by the other.

• 1.1.1.6 Tagging

  • 1.1.1.6.1 Users shall be able to tag their items such as creating a tag or using an existing one.

• 1.1.1.7 Searching

  • 1.1.1.7.1 Users should be able to search users and events semantically by means of the following services.
    • 1.1.1.7.1.1 They shall be able to make location-based filtering.
    • 1.1.1.7.1.2 They shall be able to make tags filtering.
    • 1.1.1.7.1.3 They shall be able to find events by searching with relevant keywords.

• 1.1.1.8 Notifications

  • 1.1.1.8.1 Users should be able to get notification of friends requests when other users send a request.
  • 1.1.1.8.2 Users should be able to get notification of private message sent by other users, which can be seen in their message page.

• 1.1.1.9 Blocking

  • 1.1.1.9.1 Users should be able to block certain users.
  • 1.1.1.9.2 A blocked user by another user shall not be able to see each other's profile and items.

1.1.2 Guest User Requirements

• 1.1.2.1 Guest users shall be able to only view events and actions taken by members whose profile visibility is set to be open to the public.
• 1.1.2.2 Guest users shall not be able to take any other action.

1.2. System Requirements

• 1.2.1 Content

  • 1.2.1.1 Users shall have the freedom to create an item and an event.
  • 1.2.1.2 Users shall be able to delete their items and events.
  • 1.2.1.3 Users shall be able to edit their items and events.
  • 1.2.1.4 The system shall provide enough information about an artist, event date, and event price.

• 1.2.2 Recommendations

  • 1.2.2.1 Users shall be able to get recommendations for events based on their event histories.

• 1.2.3 Interface

  • 1.2.3.1 Project interface language shall be English.

• 1.2.4 Annotations

  • 1.2.4.1 Users shall be able to annotate the event information and multimedia that may have been added to an event page with explanations, questions, and answers.
  • 1.2.4.2 System shall allow annotation including geographical references by using Google Map API.
  • 1.2.4.3 System shall allow text formatted annotation.
  • 1.2.4.4 System shall allow image formatted annotation.
  • 1.2.4.5 System shall allow links which may be semantic resources to provide more detailed information about the event.

• 1.2.5 Search

  • 1.2.5.1 The system shall be able to perform semantic searches as specified by the users.
  • 1.2.5.2 The application should allow a semantic search to be made.
  • 1.2.5.3 The system should be able to use a given location when a user searches events in the platform.

• 1.2.6 Database

  • 1.2.6.1 The system shall store data in the database.
  • 1.2.6.2 The system shall update data in the database.
  • 1.2.6.3 The system should make integrity check once in two weeks to prevent data loss.

• 1.2.7 Voting

  • 1.2.7.1 System shall be able to store voting data coming from users.
  • 1.2.7.2 System shall be able to retrieve voting data coming from users.

2. Non-Functional Requirements

2.1 Security and Reliability

• 2.1.1 Data of users shall be protected and used according to LAW ON THE PROTECTION OF PERSONAL DATA (Kişisel Verilerin Korunması Kanunu)
• 2.1.2 Users' email addresses shall not be reachable by other users or the public.
• 2.1.3 Users' passwords shall be stored with encryption in the database.
• 2.1.4 Users shall get notification emails when they change their password.
• 2.1.5 Captcha method shall be enabled while registering to prevent malicious bots.
• 2.1.6 Weekly periodic backups shall be taken to ensure data is safe and sound.
• 2.1.7 In case of server failure and in the need, the system shall be restored with the latest backup.

2.2 Performance

• 2.2.1 The system should be able to respond to requests within 4 seconds.
• 2.2.2 100 requests per seconds should be responded.
• 2.2.3 The system shall be able to serve at least 20000 members.

2.3 Availability

• 2.3.1 Project shall be available on both Android and Web platform.
• 2.3.2 Compatibility with Google Chrome, Opera(Chromium based browsers), Firefox, Safari and Edge should be ensured.
• 2.3.3 The system should be guaranteed to be accessible always except for maintenance times.
• 2.3.4 System should be available 95% of the time.
• 2.3.5 In the case of a failure, the system should recover in at most 1 hour.

2.4 Database

• 2.4.1 Data shall be held in a secure database.
• 2.4.2 Database hierarchy shall be constructed in such a way that it is efficient and protects the privacy of users' data.
• 2.4.3 All changes' logs shall be kept in a database.`

2.5 Annotations

• 2.5.1 The W3C Web Annotation Data Model shall be used for annotation.
• 2.5.2 The annotations shall be stored and retrieved based on Linked Data Platform.
• 2.5.3 JSON-LD format shall be used for annotation representation according to W3 documentation.
• 2.5.4 The annotations shall be tested by the test team to ensure that they work correctly.
• 2.5.5 Suggestion of annotation should allow urls while creating an annotation.
• 2.5.6 Retrieving annotations shall be allowed for all users.
• 2.5.7 Creating annotations shall be allowed for only registered users.
• 2.5.8 Updating and deleting annotations shall be allowed only if the online user is the owner of the annotation.

2.6 Accessibility

• 2.6.1 The system shall be accessible on Android version 6.0 and higher and web platforms.
• 2.6.2 The web platform shall be responsive to screen sizes of various sizes.