The main purpose of this project is to provide a platform that quantizes and digitizes real-life events and actions that occur after a disaster by collecting, verifying, and sharing information in a structured manner. The platform aims to connect providers with demanders and eliminate the lack of coordination that can arise during disaster response efforts. By providing a platform for verified users and guest users, the system can help manage resources and aid distribution more efficiently.

• Disaster: A sudden accident or a natural catastrophe that causes great damage or loss of life (earthquake, fire, flooding, rainstorm, hurricane, avalanche, etc.).
• Admin: User who has the highest level of authority and who can control the application by banning users, editing posts, etc.
• Information: Various types of information which circulate on the application (event, action, resource, need).
• Event: Disaster related static happenings created by users (road is blocked, buildings are destroyed, power cut).
• Action: Disaster related dynamic happenings created by users (dispatch of a relief team, search for survivors).
• Resource: Any type of resource provided to demanders such as material resources (food, clothing, shelter, medical supplies, vehicles, instruments, etc.) or human resources (doctors, volunteers, etc.).
• Need/Demand: Needs that are needed by demanders.
• Demander: Users who need resources due to suffering damage from disasters.
• Provider: Users who can provide material resources or him/herself as human resource to demanders.
• CDC: Collection and distribution center which act as a provider and demander by receiving and distributing resources at the same time.
• User: Anyone who is using the application. Can be a volunteer, demander, provider, etc.
• Guest user: Anyone who is using the application without registration. A guest user can view general information about disasters.
• Authenticated/General user: Anyone who is using the application with signing up and entering personal information (name, surname, phone number). An authenticated user can report information such as events, actions, resources, needs.
• Verified user: Special users with extra authority (headman, pharmacist) who can prioritize actions, verify information, contact users, etc.
• Profile: A page containing static data related to registered users (name, surname, phone number).

The objectives of the system include:

1. Facilitating the efficient allocation and distribution of resources, such as food, clothing, shelter, and medical supplies.
2. Providing real-time location tracking and mapping to optimize aid delivery to affected areas.
3. Streamlining communication between relief teams, local authorities, and affected individuals.
4. Supporting both predefined and generic events and actions to ensure that all types of aid requests and needs are addressed.

The benefits of the system include:

1. Improved coordination and organization of relief efforts, reducing redundancy and ensuring that aid is delivered to those who need it most.
2. Enhanced efficiency in the allocation of resources, minimizing waste, and ensuring that resources are used effectively.
3. Better communication and collaboration between relief teams, local authorities, and affected individuals, leading to more effective disaster response.
4. Providing a centralized platform that can be easily accessed by various users, simplifying the management of disaster response efforts.

1. https://en.wikipedia.org/wiki/2023_Turkey%E2%80%93Syria_earthquake
2. https://deprem.io/
   
   [TODO: Remove this - When docjob is done] Should be written with relevant information. References are important. And should be.

TODO: Shall/should distinction is a bit mixed here should review To draft the functional requirements, we need to put a brief description of the process. The user actions refer to the workflow.

As stated in the introduction section, disasters being exceptional events require non-ordinary responses by both corporate structures and individuals with unusual amounts through various and unconventional ways.

Needs of individuals and social/administrative bodies arise, while excessive amounts of resources by both individuals and corporate structures are declared for help.

Needs should be met by the declared resources and resources should be found/requested for needs.

Information is also a crucial issue. Collecting, verifying, and sharing information in a useful and structured manner is needed.

We decided to generalize the process for this as follows. (The "elements" or concepts of the system are defined in the definitions section)

Various types of resources are dynamically registered. Including instruments, vehicles, goods (food, clothing, medicine), personnel with special abilities, volunteers, and even accommodation.

Various types of needs are declared by individuals, social or administrative bodies. Through defined, formal or undefined and informal channels.

Various types of information circulate.

1. All resources should be recorded with according data. (e.g. A truck offered by an individual with certain ability/capacity with certain times of availability. A doctor with certain qualities/expertise volunteering to join the action in certain times of availability. )
2. All demands/needs should be recorded with according data. (e.g. Need for help to evacuate a building or a village at risk of flooding. Need for help for rescue etc.)
3. All related information should be recorded with according data (e.g. A road is blocked. Flood risk arises in certain locations. Power cut in certain regions/locations)
4. Improvements, state changes of needs, events, resources, and information should be recorded. (e.g. A demand is fulfilled by third parties. A resource is not available anymore etc.)

1. The administrative bodies using the software should be able to monitor all the recorded data (With visual instruments, maps, lists, etc.)
2. Recorded resources should be notified about recorded needs and demands meeting their abilities. Through notifications to system users which are the owner of the resource information. The user may be the provider themselves or the user who registered the information to the system.
3. Activities to fulfill the demands by available resources should be recorded and be related to the demands and resources.
4. The availability of the resource should be updated according to the action decisions taken. (e.g. Certain vehicle is on the way for certain recorded demand. A volunteering doctor is on the way. Or arrived!)
5. The need/demand records should be updated/extended according to the action decisions taken. (e.g. A resource is assigned for the demand. The demand is fulfilled. The priority of the demand is changed. Etc.)
6. Any information recorded in the system should initiate notifications to the users interested/related. By definition (e.g. The drivers who will possibly use the route including the blocked road mentioned in the information) or by user interaction (e.g. An authorized user decides to notify certain users about the information)

1. Any record (need/demand, resource declaration, information) should have a verification state.
2. By default the verification state is assigned according to the "reliability" of the recording user.
3. Authorized users shall be able to change the verification state or assign a resource to verify.

1. Providers are entities declaring resources. (e.g. Someone giving away a given amount of food voluntarily, Some doctor, volunteering to work) Providers are not users. Users (subjects logging on the system) may declares themselves as providers or delegate providers on the system.

   1. A provider is linked to a system user by definition. (One user to many provider relation) Cases are: a. provider is an active user of the system. b. provider is delegated by an active user of the system (The user is in contact or is responsible of contacting the provider in this case)
   2. Providers declare available resources.
   3. Any contact by the system (including notifications) with the provider will be done via the linked user.

2. Users -> Providers -> Resources... Redundancy will be eliminated in this schema in certain limits. If a user declares themselves as a provider, the profile of the user will be duplicated to the provider data. [#Tobediscussed]

3. Providers are static elements of the system. The case of a doctor, for instance, being a provider might be confusing. So it is a good example to understand the distinctions.

   1. A doctor declares himself/herself to be available from A_DATE to/until B_DATE in ACTIY. And declares that he/she is ready to serve as a orhopedist surgeon. The doctor as a person with a name and ID is a provider here. The resource declared is "an orthopedist surgeon who is available between A_DATE and B_DATE in ACITY.
   2. The same doctor may declare himself/herself as a rescue expert. This time he declares self as a human resource, but not a doctor this time.
   3. Individuals, communities, foundations even governmental bodies can be declared as providers. For different types of resources: Human resources, food, clothing, machinery, trucks etc.

1. Demanders are static entities with to be declared needs
2. Demanders have
   • Contact information
   • Personal data
   • Reliability level
   • Scope (Geographical area and operational quality - e.g. A user is reliable in ACITY with Rescue knowledge)

1. Resources are dynamic (living) entities
2. Resources have attributes:
   • Definition/functionality (Blanket, truck, orthopedist surgeon, Shoe, boot, ability to collect information etc.
   • Current location
   • (will be) Available at location
   • (will be/is) Available in certain time interval
   • Quantity
   • Reliability
3. Resources have attributes:
   • Allocated
   • Used
   • Cancelled

1. CDCs are providers and demanders at the same time.
2. Every CDC can receive resources provided by Providers acting as a demander.
3. Every CDC can provide demanders with resources by acting as a Provider.
4. Every resource received by a CDC becomes a resource declared by the CDC. 5, Every resource provided to a demander by a CDC becomes a used resource fulfilling the need of a demander.

1. Needs are dynamic (living) entities
2. Needs have attributes:
   • Definition/functionality (Blanket, truck, orthopedist surgeon, Shoe, boot, ability to collect information etc.
   • location
   • Wants to fulfilled in certain time interval
   • Quantity
   • Reliability
3. Needs have attributes:
   • Assigned to certain resource
   • Fulfilled
   • Cancelled

TODO: Static Operational roles mentioned belove in Profiles section). Roles like "keşif ve doğrulama elemanı" or "dağıtım merkezi yetkilisi" or "çağrı merkezi yetkilisi" but not "şöför", "doktor", "rescue expert". Operational is related to the operation of the software here. Not the field operation TODO: This definition seems to be redundant. Provider represents the static information with qualities/abilities. When put in action defines a resource (Keşif ve doğrulama elemanı in certain location at certain time is a resource)

1. Users shall have a reliability level.
2. Users shall record providers, demanders, resources, needs and information with their reliability level.
3. Users shall be able to change reliability of data according to their reliability level. (A more reliable user shall be able to upgrade the reliability of a recorded data by other "less reliable" users.

• 2.3.1. Registration
  • 2.3.1.1. Users shall be able to create an account using a valid and unique email address, a username, and a password.
  • 2.3.1.2. Users should see the data without login. (?)
• 2.3.2. Log In
  • 2.3.2.1. Users shall be able to log into their account using their email or username, and password combination.
  • 2.3.2.2. Users shall be able to reset their password via email verification.
• 2.3.3. Log Out
  • 2.3.3.1. Users shall be able to log out of their accounts.

Profile information for a user consists of:

1. Name and surname
2. Place of birth
3. Date of birth
4. Nationality
5. ID number

1. Education
2. Health status
3. Works at/works as
4. Marital status
5. Children/respondents

1. Address
2. Phone
3. E-mail
4. Social media links
5. Free format info for contacting them
6. Second contact (contact info of a relative, close friend, etc.)

1. Specialities

• Definition
• Experience level
• Documented/certified by
  • Uses
    • Device, vehicle, instrument, etc.
    • Certificates (e.g. driver's license info)

2. Languages spoken
   • Language
   • Proficiency
3. Professions
4. Other skills
5. Medical condition (health problems, disabilities, allergies, etc.)

1. Role/Authority type
2. Context

1. Users shall have their profile information recorded.
2. Users shall be able to display profile information details.
3. Users shall be able to select which details of their profile information will be publicly displayed.
4. Users shall be able to edit their profile info.
5. Users' profile information will be subject to verification, correction, and deletion by users having the rights to do.
6. Users shall be designated to operational roles by users having the rights to do so.
7. Users shall be able to confirm or reject the operational roles they are designated.
8. Users shall be able to propose themselves as active resources (within available time limits) according to their profile information.

• Users shall be able to see the general information about disasters without logging in.
• Users shall be able to view information about disasters, including event types, resources available, and actions taken.
• Users shall be able to report new disasters, such as fire, flood, or earthquake.
• Users shall be able to report required resources related to a disaster.
• Users should be able to receive notifications about available resources, or actions taken in their area.
• Users shall be able to filter and sort information about events, resources, and actions based on location, date, etc.

• Verified users shall be able to view information about ongoing disasters in their area, including event types, resources available, and actions taken.
• Verified users shall be able to see the contact information of other users.
• Verified users shall be able to verify the authenticity of events, resources, and actions reported by other users to avoid duplicate or false information.
• Verified users should be able to prioritize actions based on the severity and urgency of the situation.
• Verified users should be able to see a summary of all actions taken by users to help identify areas where additional resources or actions are needed.