Requirements - bounswe/bounswe2024group6 GitHub Wiki
Project Requirements
Glossary
Guest: Uses system without creating account.
Registered User: Uses system with log-in after creating account.
User: Describes both guest and the registered user.
Admin: A type of users with more authority such as deleting a post.
Authentication: The steps of establishing identity and verifying permission to access the platform.
Profile Page: A page that collects registered users' own posts.
Home Page: An introductory page for a user when they log in to the system. It includes posts of followed users, most popular posts of the week etc.
Post: A content which contains information and pictures about an architect, a building or a style.
Comment: A content that contains additional information to its related post.
Follow: A contact between users in order to view their activities easily.
Like: A feature in communication software where the user can express that they like, enjoy or support certain content.
Dislike: A feature in communication software where the user can express their dissatisfaction with the content.
Misinformation Tag: A tag that can be added to posts which contains false information.
Hateful Speech Tag: A tag that can be added to posts which contains hate speech, slang, racist discourses etc.
Architect: Professionals trained in the art and science of building design.
Architectural Style: A classification of buildings based on a set of characteristics, including overall appearance, method of construction, historic and regional character.
Tag: A label to categorise content (#question, #information, #meme etc.).
1. Functional Requirements
1.1 User Requirements
1.1.1 Sign-up Requirements
Users shall provide their unique username.
Users shall provide their secure password.
Users shall provide their e-mail adresses.
Users shall provide another e-mail adress for recovery.
Users shall verify their e-mail adress.
1.1.2 Sign-in / Sign-out Requirements
Users should be able to recover their password given their e-mail.
Users shall be able to log in to their profile given credentials.
Users should be able to change their passwords.
Users shall be able to log out from their profiles and continue with guest user account.
1.1.3 Guest requirements
Guests represents people using system without log-in.
Guests should be able to see users posts.
Guests shall not be able to post.
Guests shall not be able to bookmark.
Guests shall not be able to comment.
Guests shall not be able to like.
Guests shall not be able to send personal message.
Guests should have an empty avatar in the profile section.
1.1.4 Profile Requirements
Only Registered Users should have a profile
A profile shall have an initial avatar.
A profile shall have biography section.
A profile should let the user to update its avatar.
A profile should let the user to update the biography.
A profile shall keep track of bookmarks.
A profile should keep track of likes.
A profile shall keep track of previous posts.
A profile should include a message box.
A profile should store previous messages.
1.1.5 User Interaction Requirements
Users shall be able to view other users profiles.
Registered users shall be able to post a new post.
Registered users shall be able to bookmark a post.
Users shall be able to view posts.
Users shall be able to query a search giving an architect name.
Users shall be able to query a search giving an building name.
Users shall be able to query a search giving an architectural-style name.
Registered users shall be able to comment to the posts.
Registered users should be able to delete the comment to the posts.
Registered users shall be able to like posts.
Registered users shall be able to undo like posts.
Registered users shall be able to bookmark posts.
Registered users shall be able to undo bookmark posts.
Users shall be able to see the locations on the posts via google maps.
Users shall be able to navigate to the related pages from a single page.
Registered users shall be able to follow other users.
Registered users shall be able to undo follow other users.
1.2 System Requirements
1.2.1 Searching and Sorting Requirements
Architectural trends should be able to be searched using keywords or specific queries.
Results should be allowed to be sorted based on relevance, date, popularity, or other relevant factors.
Results should be allowed to be filtered based on criteria such as time period, geographical location, architectural style, etc.
Functionality should be implemented to save search history for users and provide an option to revisit previous searches.
Users should be able to do semantic search. Providing a keyword they should get the result for closest query.
1.2.2 Integration Requirements
Integration with the Wikidata API should be implemented to fetch relevant data about architectural trends, ensuring proper handling of API requests and responses.
Caching mechanisms should be implemented to optimize performance and reduce the load on the Wikidata API by storing frequently accessed data locally.
1.2.3 Post Requirements
A post should contain 3 sections: Style, Architect, Building.
Under the Style section, relevant information about the stylistic part of the building should be included.
Under the Architect section, general information about the architect, the trends they are associated with, and an image of the architect should be provided.
Under the Building section, information about the building and a picture should be included.
At the bottom of the page, a map should be displayed showing the location of the building.
Posts should have the functionality to be liked and disliked.
A post should contain 3 sections: Style, Architect, Building.
Under the Style section, relevant information about the stylistic part of the building should be included.
Under the Architect section, general information about the architect, the trends they are associated with, and an image of the architect should be provided.
Under the Building section, information about the building and a picture should be included.
At the bottom of the page, a map should be displayed showing the location of the building.
Posts should have the functionality to be liked and disliked.
2. Non-functional Requirements
2.1 Availability and Reliability Requirements
The project should be available in English.
The system should be designed to restore functionality within one or two hours following any unexpected system disruptions
Should set up backups to protect against data loss and quickly fix any problems if data gets corrupted or lost.
The platform must be capable of accommodating a minimum of 100 simultaneous user actions.
2.2 Compatibility
Compatibility with popular web browsers like Google Chrome, Safari is ensured for the project.
The users shall be able to enter the system from a smartphone, tablet.
It should be compatible with different popular Operating Systems.
Testing must be regularly conducted to ensure that updates to browsers or operating systems do not affect the system's usability or accessibility
2.3 Performance
The system shall respond to requests within 3 seconds.
The system is capable of handling up to 5000 requests per second
The platform must maintain a minimum uptime of 99%.
2.4 Security
Passwords maintained in the system's database will be secured through encryption.
Personal information of users must be concealed from other members
Should be used strong passwords for user accounts, combining letters, numbers, and symbols
The system will utilize the HTTPS protocol.
Unique and valid emails should be used.
2.5 Database
The system will store user information, user histories, and user preferences in the database.
The information within the database should support updates.
The database structure will prioritize efficiency
The database should be designed to support scalability, allowing for easy expansion as the number of users and the volume of data grows