Skip to content

Requirements Analysis

Serkan Özel edited this page Nov 27, 2018 · 157 revisions

Checkout Requirements Analysis Grooming page to add and track missing requirements, needed adjustments and possible suggestions.

Glossary

Definitions

  • 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.

Technical Terms

Project Requirements

1. Functional Requirements

1.1. User Requirements

    1.1.1. Guests
    • 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. Authentication
    • 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. Profile
    • 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.4. Feed
    • 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. Communication
    • 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. Events
    • 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.2. Users shall be able to create their own tag if they prefer.

    • 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.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. Searching
    • 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. Verification
    • 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. Comments
    • 1.1.9.1 Users shall be able to upvote/downvote the comments.

    1.1.10. Admin Panel
    • 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.2. System Requirements

    1.2.1. Search
    • 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. Recommendation

    1.2.2. Recommendation

    • 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. Ranking
    • 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. Admin Feature
    • 1.2.4.1 System shall be able to handle all operations stated in 1.1.10.

    1.2.5. Annotations
    • 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. Events
    • 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. Database
    • 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. Voting
    • 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. Notification
    • 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. Account
    • 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. Feed
    • 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.

2. Nonfunctional Requirements

    2.1. Accessibility
    • 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. Availability
    • 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. Reliability/Survivability
    • 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. Performance/Efficiency
    • 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. Integrity
    • 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. Security
    • 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. Privacy
    • 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.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. Database
    • 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. Annotations
    • 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. Robustness
    • 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. Version
    • 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. Localization
    • 2.12.1. The system will be accessible by native Turkish, English and French users.

    2.13. Voting
    • 2.13.1 Number of collected votes shall define the popularity of comments.

    2.14. Location
    • 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.
Clone this wiki locally