Chosen-Juan1
commented
1 month ago 2.2.4 Interface Requirements
The system shall allow users to create and/or log in to an account belonging to them only by using specific credentials: a username/email and a password. The system shall recognize when an account belongs to an admin, and shall redirect them to the admin’s communication interface page rather than the usual user page.
After logging in, the system shall redirect a non-admin user to the appropriate user landing page. Else, the system shall redirect an admin to the admin communication’s interface page.
From the landing page the system shall provide the user with buttons that execute the following actions: Allow the user to access the reports page, S.O.S page, rumors page, and resources page.
Allow the user to access their profile page.
Allow the user to access the settings page.
Should a user file a report, regardless if it’s a normal report or an S.O.S report, the system must provide a method to track the progress of these reports, preferably through buttons inside both normal and S.O.S reports pages.
Reports page The system must allow the user to create and post personalized reports that detail a situation they wish to report. The system shall allow the user to provide a description of the situation, a location, and a date. The system shall use the user’s profile to provide identifying information to a post. Depending on the user’s preferences, the system shall use the user’s device to provide an accurate date and location information for the post. Else, the system shall allow the user to provide said information manually via a digital map and clock.
The system shall provide a sub menu that allows users to track ongoing reports.
S.O.S page
The system must allow the user to file an urgent “S.O.S” report that is similar to the reports mentioned above, but that come with a generic description and a last known location already pre-attached to said report. The system must have an interface that allows the user to realize this action in as little time as possible, prioritizing simplicity above all else.
The system shall provide a sub-menu that allows users to track ongoing reports.
Rumors page
The system must allow users to create and upload posts that detail what is considered a rumor. The system shall allow users to provide a description of the rumor and a known location that relates to the rumor (if it applies).
The system shall display the credibility score of any user who makes a post within this page, so that other user’s are able to gauge a post’s credibility, before any admin interaction.
Profile page
The system shall allow the user to customize their profile picture and username
Settings page
The system shall allow users to customize their interface through this page. Things like: font size, notifications, scroll speed, etc… Admin’s communication interface page:
The system shall provide admin’s with separate windows that illustrate recent reports, S.O.S reports, and available/ongoing system wide alarms.
In the case of both report windows, the system must illustrate up to three of the most recent reports submitted by the users. This is done so that an admin can receive the most recent reports as soon as possible. Should an admin wish to view all reports currently in circulation, the system must provide a button, located below the recent reports mentioned above, that takes the admin to the respective reports page.
For the alarms, the system shall provide the admin with buttons that take the admin to sub-pages, or modals, that prompt the admin for relevant information (like a description of the emergency being announced, the location of said emergency, the date, etc…) and then provides the option to send the alarm system wide. The system shall also allow admins to verify past alarms and ongoing alarms for the sake of record keeping and management respectively.
Objective: Define and document the interface requirements for the system-to-be, focusing on how the system will interact with users, external systems, and the domain itself. These requirements will guide the development of the user interface and other interaction points, ensuring they are aligned with the domain needs and user expectations.
Task Description: The Interface Requirements section outlines how the system should interact with users and other external systems. This includes defining how the system will represent domain phenomena, how inputs from users will be handled, and how outputs will be presented. The interface requirements should ensure that the user experience is intuitive and that the system can effectively bridge the gap between the real-world domain and the system’s internal logic.
Implementation:
Subtasks: • Identify Interface Points: Review the domain requirements and user stories to identify key interface points where users or external systems interact with the system. • Define UI/UX Requirements: Write specific requirements that focus on how users will interact with the system, including input forms, display elements, and navigation. • Define External Interface Requirements: Define how the system will interact with external systems (e.g., APIs, data sources), specifying data exchange protocols and formats. • Review for Completeness: Ensure that all critical interface points have been documented and that the requirements cover both user interactions and system integrations. • Iterative Refinement: Plan for ongoing refinement of interface requirements as the project evolves and new interface points are identified.
Testing and Debugging: • Review the interface requirements with team members and stakeholders to ensure they align with user expectations and domain needs. • Validate the interface requirements by comparing them to user stories and domain requirements to ensure they cover all necessary interactions. • Test for completeness by ensuring that the interface requirements address both user-facing interfaces and external system interfaces.
Deadline: Wednesday, September 18 at 11:59 p.m.