REQUIREMENTS

1. Functional Requirements

1.1. Registration and Profile Requirements

1.1.1. User Expertise and Resources

• 1.1.1.1 Users shall be able to specify their profession or area of expertise.
• 1.1.1.2 Users shall be able to declare the areas in which they have knowledge, training, or expertise.
• 1.1.1.3 Users shall be able to specify the resources or supplies they are willing to provide.
• 1.1.1.4 The system shall support verification of user-provided professional or expertise information.
• 1.1.1.5 Users shall be able to update their listed expertise fields and offered resources after registration.
• 1.1.1.6 The system shall distinguish verified expertise information from unverified user-provided expertise information.

1.1.2. Sign-Up

• 1.1.2.1 Users shall be able to sign up by providing their email address and creating a password.
• 1.1.2.2 Users shall be required to verify their email address before activating their account.
• 1.1.2.3 Users shall be able to provide their full name during registration.
• 1.1.2.4 Users shall be able to provide their phone number during registration.
• 1.1.2.5 Users shall be required to accept the terms and conditions during registration.

1.1.3. Physical Information

• 1.1.3.1 Users shall be able to enter their height and weight during registration.
• 1.1.3.2 Users shall be able to provide their date of birth.
• 1.1.3.3 Users shall be able to provide their gender (optional).
• 1.1.3.4 Users shall be able to update their physical information after registration.

1.1.4. Health Information

• 1.1.4.1 Users shall be able to enter their medical history during registration.
• 1.1.4.2 Users shall be able to specify chronic diseases (if any).
• 1.1.4.3 Users shall be able to specify allergies (if any).
• 1.1.4.4 Users shall be able to enter their medications (if any).
• 1.1.4.5 Users shall be able to enter their blood type.
• 1.1.4.6 Users shall be able to update their health information at any time.

1.1.5. Location Information

• 1.1.5.1 Users shall be able to provide their country and city.
• 1.1.5.2 Users shall be able to share their current location (optional).
• 1.1.5.3 Users shall be able to update their location information.

1.1.6. Privacy and Security

• 1.1.6.1 Users shall be able to control which personal information is publicly visible.
• 1.1.6.2 The system shall securely store all personal and health-related data.
• 1.1.6.3 The system shall encrypt sensitive user information.
• 1.1.6.4 Users shall be able to delete their account and associated personal data.
• 1.1.6.5 Users shall be able to choose whether their precise location, approximate location, or no location information is visible to other users.
• 1.1.6.6 Users shall be able to choose whether their health information is visible to other users or remains private.

1.1.7. Reporting and Notifications

• 1.1.7.1 The system shall provide a mechanism for users to flag harmful, abusive, or inappropriate content or behavior.
• 1.1.7.2 The system shall notify users about relevant emergencies or assignments by considering factors such as proximity and contextual relevance.

---

1.2. Availability and Help Assignment Requirements

1.2.1. Availability Management

• 1.2.1.1 Volunteer users shall be able to declare their availability to provide help by activating an “Available to Help” status.
• 1.2.1.2 Volunteer users shall be able to deactivate their availability status at any time.

1.2.2. Offline Support and Synchronization

• 1.2.2.1 The system shall store changes to availability status locally when internet connectivity is unavailable.
• 1.2.2.2 The system shall synchronize locally stored availability status updates automatically when internet connectivity is restored.
• 1.2.2.3 Users shall be able to create a help request while offline.
• 1.2.2.4 Users shall be able to choose their need type when creating their help request.
• 1.2.2.5 Users shall be able to enter a short description for their help request.
• 1.2.2.6 The system shall warn users when critical request information is missing (e.g., location or need type), while still allowing them to proceed with defaults.
• 1.2.2.7 The system shall store help requests locally until connectivity is available.
• 1.2.2.8 The system shall synchronize pending help requests automatically when connectivity returns.
• 1.2.2.9 The system shall match help requests when connectivity returns, using the automatic assignment and matching process defined in Section 1.2.3.
• 1.2.2.10 The system shall display synchronization status to users for locally stored changes.
• 1.2.2.11 The system shall synchronize locally stored changes automatically when connectivity becomes available.
• 1.2.2.12 The system may allow users to manually trigger synchronization when connectivity is available.

1.2.3. Automatic Assignment and Matching

• 1.2.3.1 The system shall automatically evaluate active help requests for assignment to available users.
• 1.2.3.2 The system shall assign help requests to available users based on declared skills, expertise, available resources, and urgency level of the request.
• 1.2.3.3 The system shall assign a help request only if the user’s declared skills, expertise, or resources match the required category of the request.
• 1.2.3.4 The system shall display the request status as Pending Sync, Synced, Matched, or Resolved.
• 1.2.3.5 The system shall allow an assigned helper to cancel an assignment.
• 1.2.3.6 The system shall allow a requester or an authorized administrator to mark a help request as resolved.

1.2.4. Help Request Details and Interaction

• 1.2.4.1 Users shall be able to access the essential details of a help request, including its description and urgency level.
• 1.2.4.2 The system shall present the geographic location of a help request through a map-based view.
• 1.2.4.3 Users shall be able to submit an offer to help by indicating the relevant category, skill or resource, a short description, and their availability.
• 1.2.4.4 Users shall be able to view the assigned helper information for their matched help requests.
• 1.2.4.5 Users shall be able to view their own submitted help requests and track their current status.

1.2.5. Communication Between Matched Users

• 1.2.5.1 The system shall enable direct communication or contact between a requester and the helper assigned to that request.
• 1.2.5.2 The system shall restrict communication or contact access so that it is available only between matched users.

---

1.3. Web Portal Requirements

1.3.1. Public Information Pages

• 1.3.1.1 The web portal shall provide a public landing page describing the purpose of the system and how it works.
• 1.3.1.2 The web portal shall provide a page listing emergency contact numbers.
• 1.3.1.3 The web portal shall provide an interactive map showing gathering areas.
• 1.3.1.4 The web portal shall allow users to view news and announcements related to emergencies and preparedness.

1.3.2. Profile Access from Web

• 1.3.2.1 Users shall be able to log in through the web portal and update their profile information.
• 1.3.2.2 The web portal shall not require operational emergency actions such as creating or managing help requests.

1.3.3. Administrative Functions

• 1.3.3.1 Authorized administrators shall be able to view the list of registered users.
• 1.3.3.2 Authorized administrators shall be able to view help requests and their statuses.
• 1.3.3.3 Authorized administrators shall be able to suspend users when necessary.
• 1.3.3.4 Authorized administrators shall be able to override assignments when necessary.
• 1.3.3.5 Authorized administrators shall be able to mark help requests as resolved.
• 1.3.3.6 Authorized administrators shall be able to create, update, and delete news or announcement items.
• 1.3.3.7 Authorized administrators shall be able to view basic system statistics, including total users, active requests, and active volunteers.

---

1.4. Mobile Application Requirements

1.4.1. Mobile Notification and Status Awareness

• 1.4.1.1 The mobile application shall notify users in-app when relevant assignments or emergency-related updates occur.
• 1.4.1.2 The mobile application shall display clear request and assignment statuses to users.

---

2. Non-Functional Requirements

2.1. Performance and Responsiveness

• 2.1.1 The system shall remain responsive during background synchronization and other background operations without blocking core user interactions.

2.2. Availability and Resilience

• 2.2.1 When network access is unavailable, the system shall continue operating in a limited but usable mode by relying on cached critical information.
• 2.2.2 The system shall handle unstable connectivity without losing user data and shall retry failed synchronization attempts using an exponential backoff strategy.
• 2.2.3 Following an application failure or crash, the system shall restore the most recent consistent state when reopened.
• 2.2.4 Temporary communication failures shall not result in irreversible loss of critical data.

2.3. Offline-First and Data Integrity

• 2.3.1 The system shall keep user changes in local storage while offline and synchronize them automatically once connectivity is re-established.
• 2.3.2 The system shall resolve synchronization conflicts through a predefined and deterministic strategy such as timestamps, version comparison, or merge rules.
• 2.3.3 The system shall preserve consistency between locally stored information and server-side data after synchronization.

2.4. Security and Privacy

• 2.4.1 All data exchanged between clients and backend services shall be protected through encrypted network communication.
• 2.4.2 The system shall restrict administrative capabilities through role-based authorization controls.
• 2.4.3 The system shall avoid collecting unnecessary personal information whenever a less intrusive alternative is sufficient.
• 2.4.4 The system shall protect sensitive local data on the mobile device using platform-supported secure storage mechanisms where applicable.

2.5. Usability and Accessibility

• 2.5.1 The user interface shall clearly indicate offline operation and current synchronization state.

2.6. Reliability of Critical Features

• 2.6.1 The system shall record emergency-related events using a consistent timestamping approach and account for possible clock differences during offline usage.

2.7. Compatibility and Portability

• 2.7.1 Core features of the system shall remain usable on lower-end mobile devices.
• 2.7.2 The system shall continue supporting critical user flows under poor network conditions such as high latency or packet loss.