-
Notifications
You must be signed in to change notification settings - Fork 6
Requirements Analysis
Checkout Requirements Analysis Grooming page to add and track missing requirements, needed adjustments and possible suggestions.
-
Account: A set of application related information individually for each person.
-
Admin: A person who is responsible for the management and sustainability of the system.
-
Admin panel: The interface admin uses to interact with the system.
-
Annotation: Explanatory content attached to an item.
-
Attendee: Number of users that have marked the event as "will attend".
-
Attendance information: Information of a user about attendence to an event. It can be "will attend", "may attend", "won't attend", "attended" or "didn't attend".
-
Application: The whole project as seen by guests, members and users.
-
Comment: A body of text, image or links shared in response to a post by a user.
-
Database: An organized collection of data.
-
Event: An organization that has a certain place, attendance information and a specific time.
-
Guest: A person who is not signed in to the system.
-
Interface: The visual part of the system.
-
Localization: Multilingual Support of the Platform
-
Location: Place that an event will be organized or a place around the user.
-
Member: A person who is signed up to the system.
-
Mobile application: Part of the application running on mobile phones, tablets etc.
-
Page: A screen view of the application which is exposed to the users or guests.
-
Password: A secret sequence of characters used by users to prove their right to enter the system.
-
Post: A body of text, image, event or links shared by a user.
-
Preferences: The choices a user made about which kind of events he/she might be interested in.
-
Profile: A number of specific information about the user including all the posts shared by that user.
-
Recommendation: Suggesting to a user some events to participate or users to follow.
-
Semantic search: Search algorithm which finds similar users and events based on the context information provided in the tags.
-
Sign in: Member's process of entering the application.
-
Sign up: Creating an account to be a member of the application.
-
System: The whole project, including design and functionalities.
-
Tag: A keyword that categorizes an event.
-
User: A person who is signed in to the system.
-
Username: A unique sequence of characters used to identify a user.
-
Vote: Users' rating on events, other users or other users' comments. Rating means number of followers for users, number of likes for events and comments. Comments and events can also be disliked.
- 1.1.1.1. Guests shall be able to see events created by the members.
- 1.1.1.2. Guests shall not post any comments.
- 1.1.1.3. Guests shall not create events.
- 1.1.1.4. Guests shall be able to search for public content.
- 1.1.1.5. Guests shall not be able to vote on anything.
- 1.1.1.6. Guests shall see the Trending page instead of Feed page when they open the system.
- 1.1.1.7. Guests shall not be able to mark attendance information about events.
-
1.1.2.1. Sign Up
- 1.1.2.1.1. The users shall sign up by providing an appropriate password, an e-mail address and a unique username to the system.
- 1.1.2.1.2. Users shall be able to Sign Up via their Facebook accounts.
-
1.1.2.2. Sign In
- 1.1.2.2.1. Users shall enter their username and password to login to the system.
- 1.1.2.2.2. Users shall have the option to Sign in via their Facebook account.
- 1.1.2.2.3. Users shall have an option to reset their password.
-
1.1.3.1. Personal
- 1.1.3.1.1. Users shall have a profile page which includes their information. (name, surname, date of birth, nationality)
- 1.1.3.1.2. Users shall be able edit their activity preferences.
- 1.1.3.1.3. Users shall be able to show or don't show the activities they will attend.
- 1.1.3.1.4. Users shall be able to show or don't show the activities they attended.
-
1.1.3.2. Settings
- 1.1.3.2.1. Users should be able to select whether they want to take notification or not.
- 1.1.3.2.2. Users should be able to configure their privacy settings.
-
1.1.3.3. Timeline
-
1.1.3.3.1. Users shall be able to create events by providing necessary inputs:
- 1.1.3.3.1.1 Title explaining event shortly (required)
- 1.1.3.3.1.2 Description explaining event longer (optional)
- 1.1.3.3.1.3 Owner
- 1.1.3.3.1.4 Date
- 1.1.3.3.1.5 Price and currency
- 1.1.3.3.1.6 Media: image or video
- 1.1.3.3.1.7 Location base on google map api
- 1.1.3.3.1.8 Tags
- 1.1.3.3.2. Users shall be able to see past events that they attended.
- 1.1.3.3.3. Users shall be able to post comments on events which they attended.
- 1.1.3.3.4. Users shall be able to share particular events.
- 1.1.3.3.5. Users shall be able to post photos by tagging certain events.
- 1.1.3.3.6. Users shall be able to get notifications from certain events.
-
1.1.3.3.1. Users shall be able to create events by providing necessary inputs:
- 1.1.4.1. Users shall come across first with the feed page when they open the web site or mobile application.
- 1.1.4.2. Users can see recent created events in the feed section.
- 1.1.5.1. Users shall be able to follow to vote a user and send a personal message to each other.
- 1.1.5.2. Users shall be able to block other people.
- 1.1.5.3. Blocked users shall not be able to follow the user who blocks her/him.
- 1.1.5.4. Blocked users shall not be able to attend any activity organized by the blocker user.
-
1.1.6.1. Contribution
- 1.1.6.1.1. Users shall be able to create pages for already passed events.
- 1.1.6.1.2. Users shall be able to create pages for future events.
-
1.1.6.2. Tagging
-
1.1.6.2.1. Users shall be able to attach a tag to the posts they created.
-
1.1.6.2.1.1. Some predetermined tags shall be provided by the system.
-
1.1.6.2.1.1.1 The predetermined tags:
- Movie
- Music
- Jazz
- Biennial
- Theater
- Exhibition
- Modern Art
- Art Movie
- Photography
- Travel
- Festival
- Museum
- Workshop
- Ballet
- Dance
- Classical Music
- Opera
- Blues
- Turkish Folk Music
- Concert
-
1.1.6.2.1.1.1 The predetermined tags:
-
1.1.6.2.1.2. Users shall be able to create their own tag if they prefer.
-
-
1.1.6.2.1. Users shall be able to attach a tag to the posts they created.
-
1.1.6.3. Attendance
- 1.1.6.3.1. Users shall be able to mark upcoming events as will attend, may attend or won't attend.
- 1.1.6.3.2. Multiple people can attend an event using one account by selecting attendance number at event page.
-
1.1.6.4. Voting
- 1.1.6.4.1. User shall be able to vote the events with 5 star rating system.
-
1.1.6.5. Annotation
-
1.1.6.5.1. Users shall be able to annotate the event information and multimedia that may have been added to an event page.
- 1.1.6.5.1.1 Users shall be able to annotate text formatted files.
- 1.1.6.5.1.1 Users shall be able to annotate links.
- 1.1.6.5.1.2 Users shall be able to annotate geographical references/places.
-
1.1.6.5.1. Users shall be able to annotate the event information and multimedia that may have been added to an event page.
-
1.1.6.6. Pricing
- 1.1.6.6.1 Users shall be able to see the price of every event.
-
1.1.6.7 Location and Time
- 1.1.6.7.1 Location supported by the Google Maps API shall be included in every event.
- 1.1.6.7.2 Time of the event shall be very strict and definite in terms of date, hour and minutes.
- 1.1.6.7.3 Users can set duration of the event.
- 1.1.7.1. Users shall be able to search with Semantic, Content, Time and Location options.
- 1.1.7.2. User should be able to filter the events in a city or district.
- 1.1.7.3. Users should be able to search for other users.
- 1.1.8.1. Well known users that organizes a cultural activity should be able to verify their accounts.
- 1.1.8.2 Cultural foundations should be able to verify their accounts.
- 1.1.8.3 Verification shall be done to avoid fake accounts.
- 1.1.9.1 Users shall be able to upvote/downvote the comments.
-
1.1.10.1. The system should provide an admin panel for admins with privileged rights
-
1.1.10.1.1 An admin should be able to delete or edit events.
- 1.1.10.1.1.1 An event should be deleted by admins when it is not an actual event but used for another purpose like advertisement.
- 1.1.10.1.1.2 An event should be deleted by admins when it contains illegal contents in 1.1.10.1.2.1.
- 1.1.10.1.1.3 An event should be blocked for a day when it contains illegal contents in 1.1.10.1.2.2. This is for user to change the content without removing the event.
-
1.1.10.1.2 An admin should be able to block a user from logging a specific amount time.
- 1.1.10.1.2.1 A member user should be blocked for a day when he or she spams messages and disturbs other users.
- 1.1.10.1.2.2 A member user should be blocked for an appropriate time based on what he or she has done when he or she sends illegal contents like pornography, criminal activities.
-
1.1.10.1.3 An admin should be able to view emails came from users.
- 1.1.10.1.4 An admin should be able to respond the emails. The admin shall respond in 7 days.
- 1.1.10.1.4 Admins should be able to verify celebrities and well known users.
-
1.1.10.1.1 An admin should be able to delete or edit events.
1.1.1. Guests
1.1.2. Authentication
1.1.3. Profile
1.1.4. Feed
1.1.5. Communication
1.1.6. Events
1.1.7. Searching
1.1.8. Verification
1.1.9. Comments
1.1.10. Admin Panel
-
1.2.1.1. System will search content based on search type
- 1.2.1.1.1 If semantic search is selected, system will bring related events depending on tags of events.
- 1.2.1.1.2 If content search is selected, system will bring exact matches in usernames and event names.
- 1.2.1.1.3 If location search is selected, system will bring events which are in the location.
- 1.2.1.2. System should sort search results according to the criteria given in 1.2.3.
- 1.2.2.1. The system shall recommend events to the users, based on the followed users, activity preferences and events attended.
- 1.2.3.1. The system shall provide a way for the user to see "Trending" events.
- 1.2.3.2. The ranking procedure shall be calculated according to number of attendees, votes of an event, number of views of an event, and remaining time to an event.
-
1.2.3.3. The user should be able to control ranking process:
- by selecting any single one of the criteria stated 1.2.3.2
- by not selecting one criterion, in this case overall ranking is done including all criteria in 1.2.3.2
- 1.2.4.1 System shall be able to handle all operations stated in 1.1.10.
- 1.2.5.1 Annotations shall be retrieved by the system when a page with annotations is opened
- 1.2.5.2 Annotations shall be stored in the system
- 1.2.5.3 System shall test the annotations to assure validity.
- 1.2.5.4 System shall allow text formatted annotation.
- 1.2.5.5 System shall allow image and a description message formatted annotation.
- 1.2.5.6 System shall support geographical references using Google Map API.
- 1.2.5.7 System shall allow links to other web pages.
- 1.2.6.1 System shall store events attendance information
- 1.2.6.2 System shall store attendance information for passed events, either attended or not.
-
1.2.6.3 System shall store attendance information for upcoming events.
- 1.2.6.3.1 It can be "will attend".
- 1.2.6.3.2 It can be "may attend".
- 1.2.6.3.3 It can be "won’t attend".
-
1.2.6.4 System shall store attendance information for already passed events.
- 1.2.6.4.1 It can be "attended".
- 1.2.6.4.2 It can be "did not attend".
-
1.2.7.1 System shall be able to store data in the database
- 1.2.7.1.1. System shall be able to store event tags to sort sematic search results.
- 1.2.7.1.2 System shall be able to retrieve past event history of a user in events page.
- 1.2.7.2 System shall be able to update data in the database
- 1.2.7.3 System should do an integrity check once a week to prevent data loss.
- 1.2.8.1 System shall be able to store voting data.
- 1.2.8.2 System shall be able to retrieve voting data.
-
1.2.8.3 Followers/Follows/Blocks Information
- 1.2.8.3.1 System shall hide user information between the users if one of them blocks the other.
- 1.2.8.3.2 System should be able to show the number followers and the number of users followed by the user.
- 1.2.8.3.3 System should show number of followers of a user while searching.
-
1.2.8.4 Events
- 1.2.8.4.1 System shall sort searching results according to like numbers of the events.
- 1.2.9.1 In home page there shall be a part for notifications.
-
1.2.9.2 Notifications is sent under these circumstances
- 1.2.9.2.1 System should send notification including upcoming event information of the events which a user has indicated that he or she will attend.
- 1.2.9.2.2 System should send notification to event owner if somebody comments on event page.
- 1.2.9.2.3 System should send notification to users if somebody comments under their comment.
- 1.2.9.2.4 System should send notification to users if somebody follows them.
- 1.2.9.3 Mobile version shall send notifications to users from notifications panel.
- 1.2.10.1 A confirmation e-mail shall be send by system to complete the sign up.
- 1.2.10.2 System shall provide remember me option for username and password.
-
1.2.10.3 System hides users' information to other users if privacy activated:
- 1.2.10.3.1 If user does not allow his posts cannot be seen by any user, it can be seen by only friends of the user.
- 1.2.10.3.2 User should be able to choose to hide his personal information to hide from any user, only show to friends.
- 1.2.10.3.3 Other than name can be hided.
-
1.2.11.1 The content of the feed shall depend on the owner account.
- 1.2.11.1.1 Feed shall include the approaching events created or attended by the users followed by the owner.
- 1.2.11.1.2 Feed should include the events that the owner might interest. (The details are under Recommendation)
- 1.2.11.1.3 Feed should include the events that are sponsored by verified users.(Paid advertising business model)
- 1.2.11.2 Feed shall be updated whenever a new event is ready.
- 1.2.11.3 Feed should bring new content when user presses a button in the feed page.
1.2.1. Search
1.2.2. Recommendation
1.2.3. Ranking
1.2.4. Admin Feature
1.2.5. Annotations
1.2.6. Events
1.2.7. Database
1.2.8. Voting
1.2.9. Notification
1.2.10. Account
1.2.11. Feed
- 2.1.1. The system shall be accessible on Android and web platforms.
- 2.1.2. The system shall be compatible with popular Android devices and web browsers.
- 2.1.3. The web platform shall be responsive to screen sizes with various sizes.
- 2.1.4. The system's default theme shall be modifiable to night, day and color-blindness themes.
- 2.2.1. The system will be available to users for 24 hours every day.(Except during maintenance or unexpected errors.)
- 2.2.2. The system should have a mean time to failure of at least 1 year.
- 2.2.3. The system shall achieve 99.5% uptime.
- 2.2.4. Starting of the maintenance hours, the system shall notify present users about the expected termination time of maintenance.
- 2.3.1. An update process of an item shall start all related updates again if any update fails to commit.
- 2.3.2. The system storage shall be checked regularly and should be increased whenever necessary in order for the system to continue storing new data without losing any of the old.
- 2.3.3. The system shall take regular backups of its database every two weeks.
- 2.3.4. The system shall produce a proper log file in any occurrence of an unexpected error for fixing and recovering purposes.
- 2.3.5. After each unexpected error, the system should be able to return back at least the latest database backup time.
- 2.3.6. The system shall produce an occasional log file, once the 70% memory capacity threshold is exceeded.
- 2.4.1. The system shall respond to requests in 1 second.
- 2.4.2. The system should support up to 200 requests per second.
- 2.4.3. System restart cycle shouldn't exceed 5 minutes.
- 2.4.4. Any interaction between user and interface will be last at most 3 seconds.
- 2.4.5. At least, %20 of the system's processing capacity will be available during peak load hours.
- 2.4.6. The Android client should be loaded and ready to use in at most 5 seconds.
- 2.4.7. The system should be able to serve up to 1000 concurrent users.
- 2.5.1. All numeric amounts shall be accurate to two decimal points.
- 2.5.2. Consistency between latest back-up and system will be checked once in a week.
- 2.5.3. In case of any inconsistency between incoming requests and database, the operation related to the request should be terminated.
- 2.5.4. After the termination of a request, state of the database should be restored in case of changes in databases.
- 2.5.5. An occasional log file should be generated once any inconsistency occurs.
- 2.5.6. All log files' syntax should be consistent with each other. Thereby not allowing any confusion.
- 2.6.1. Users shall be forced to change their password each year after signing up or latest password change.
- 2.6.2. After 5 unsuccessful login attempts, another try should be possible after 10 minutes has passed.
- 2.6.3. The user will be notified via an e-mail about exceedance of 5 unsuccessful login attempts.
- 2.6.4. User shall be notified about changes of a profile, personal information and password via an e-mail.
- 2.6.5. The application is web-based, therefore it should have SSL certificate.
- 2.6.6. The system should deny the requests if the request limit is breached.
- 2.6.7. The system shall escape any user-supplied input to prevent SQL Injection Attacks and XSS attacks.
- 2.6.8. Users shall be prevented to construct his/her password with well-known public pieces of information such as his name, birthday.
- 2.6.9. The system shall throw an inactivity timeout if no action is taken by the user for a specific time.
- 2.6.10 Passwords shall not be shorter than 8 characters and include both non-numeric characters and numbers.
-
2.7.1. The system shall guarantee the security of user data including personal information and passwords.
-
2.7.1.1 User privacy format can be in one of the two options.
- 2.7.1.1.1 Profile details can be seen by everyone (public)
- 2.7.1.1.2 Profile details can only be seen by the followers
-
2.7.1.1 User privacy format can be in one of the two options.
- 2.7.2. The password of a user shall not be visible at any point in time. In case of password loss, the user shall be provided a link which enables construct him/her to a new password.
- 2.7.3. Against web bots, the system should have reCaptcha human verification tools.
- 2.7.4. In login page of the web and Android application, the password shall not be visible unless the user chooses otherwise.
- 2.8.1. Any password of personal information about a user shall be encrypted before being put in the database.
- 2.8.2. Database architecture should allow fast operations to reduce latency.
- 2.8.3. Periodic backups shall be taken to ensure data is safe and sound.
- 2.9.1. The W3C Web Annotation Protocol shall be used to store annotations.
- 2.9.2. The annotations should be stored and retrieved in accordance with the protocol
- 2.9.3. Annotations shall be stored and retrieved with an API that is compliant with the standard
- 2.9.4. The annotations should be tested to assure validity.
- 2.9.5. JSON-LD should be used for annotation representation as described in the W3C documentation.
- 2.10.1. In case of failure, the system should have a recovery time of at most 30 minutes.
- 2.10.2. Any errors and exceptions encountered will be handled if possible. Proper error message shall be produced for each occurrence of such events.
- 2.11.1. The application should be support XX or higher android version.
- 2.11.2. The application should be launched XX or higher android version.
- 2.12.1. The system will be accessible by native Turkish, English and French users.
- 2.13.1 Number of collected votes shall define the popularity of comments.
-
2.14.1 The location of an event should be provided by Google Maps API.
- 2.14.1.1 Android application of the system shall provide compatibility with Google Maps application.
- 2.14.1.2 Web client of the system shall embed a Map in its body.