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 list expertise fields they possess.
• 1.1.1.3 Users shall be able to list resources they can offer.
• 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 Personal 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 update their health information at any time.
• 1.1.4.5 Users shall be able to choose whether their health information is visible to other users or remains private.

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.7 Reporting and Notifications

• 1.1.7.1 The system shall allow users to report inappropriate or harmful users or content.
• 1.1.7.2 Users shall receive notifications based on their proximity and relevance when emergency events or assignments occur.

---

1.2 Availability and Help Assignment Requirements

1.2.1 Availability Management

• 1.2.1.1 Users shall be able to declare their availability to provide help by activating an “Available to Help” status.
• 1.2.1.2 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 view help request details including description and urgency level.
• 1.2.4.2 Users shall be able to view the location of a help request on a map.
• 1.2.4.3 Users shall be able to create an offer of help by specifying category, skill or resource, description, and 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 provide a messaging or contact mechanism between matched users, namely the requester and the assigned helper.
• 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 The system shall operate in a degraded mode when connectivity is unavailable, preserving access to cached critical data.
• 2.2.2 The system shall tolerate intermittent connectivity without data loss, retrying synchronization using exponential backoff.
• 2.2.3 The system shall recover gracefully from crashes, restoring the last consistent state upon next launch.
• 2.2.4 The system shall prevent permanent data loss caused by temporary network failures.

2.3 Offline-First and Data Integrity

• 2.3.1 The system shall store offline changes locally and synchronize them automatically when connectivity returns.
• 2.3.2 The system shall implement deterministic conflict resolution using timestamps, versioning, or a defined merge strategy.
• 2.3.3 The system shall maintain consistency between local device storage and backend data.

2.4 Security and Privacy

• 2.4.1 The system shall use TLS encryption for all network communications.
• 2.4.2 The system shall enforce role-based access control for administrative operations.
• 2.4.3 The system shall minimize personal data collection where possible.
• 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 system shall provide clear offline indicators and visible synchronization status to users.

2.6 Reliability of Critical Features

• 2.6.1 The system shall timestamp all emergency events using a consistent time source and handle possible clock drift during offline use.

2.7 Compatibility and Portability

• 2.7.1 The system shall support low-end mobile devices without loss of core functionality.
• 2.7.2 The system shall operate under constrained network conditions, including high latency and packet loss, without breaking critical flows.