Alperen Dağı	Sezer Çot	Harun Reşid Ergen	Çağrı Gülbeycan	Kübra Aksu
Muhammed Ali Topcu	Volkan Öztürk	Ilgaz Er	Furkan Bülbül	Cem Sarpkaya

1. Executive Summary

• 1.1 Project Description
• 1.2 Project Status
• 1.3 Plans for the Future

2. List and Status of Deliverables

• 2.1.List and Status of Deliverables

3. Evaluation of Deliverables & Its Impact on Project Plan

• Evaluation of Deliverables & Its Impact on Project Plan
  • 3.1. Project GitHub Repository
  • 3.2. Requirements
  • 3.3. Scenarios and Mockups
  • 3.4. Software Design Documents in UML
    • 3.4.1 Use Case Diagrams
    • 3.4.2 Class Diagrams
    • 3.4.3 Sequence Diagrams
  • 3.5. Project Plan & RAM (Responsibility Assignment Matrix)
  • 3.6. Communication Plan

4. Evaluation of Tools & Processes

• 4.1. Evaluation of Tools
  • 4.1.1 Github
  • 4.1.2 Discord
  • 4.1.3 Whatsapp
  • 4.1.4 Diagrams.net
  • 4.1.5 Figma
  • 4.1.6 Google Docs
• 4.2. Evaluation of Processes
  • 4.2.1 Weekly Team Meetings
  • 4.2.2 Customer Meetings
  • 4.2.3 Github Issues & Discussions

5. Individual Contribution Reports

• Individual Contribution Reports
  • 5.1. Kübra Aksu's Report
  • 5.2. Furkan Bülbül's Report
  • 5.3. Sezer Çot's Report
  • 5.4. Alperen Dağı's Report
  • 5.5. Ilgaz Er's Report
  • 5.6. Harun Reşid Ergen's Report
  • 5.7. Çağrı Gülbeycan's Report
  • 5.8. Volkan Öztürk's Report
  • 5.9. Cem Sarpkaya's Report
  • 5.10. Muhammet Ali Topcu's Report

6. Deliverables

• Deliverables
  • 6.1. Project Repository
  • 6.2. Requirements
  • 6.3. Scenarios and Mockups
  • 6.4. Software Design Documents in UML
    • 6.4.1 Use Case Diagrams
    • 6.4.2 Class Diagrams
    • 6.4.3 Sequence Diagrams
  • 6.5. Project Plan
  • 6.6. RAM (Responsibility Assignment Matrix)
  • 6.7. Communication Plan

Our project is Disaster Response Platform. Disasters can strike anywhere, at any time, and the impact can be devastating. Whether it's a forest fire or an earthquake, having the right tools and technology can make all the difference in saving lives and minimizing damage. Our commitment to creating a reliable, user-friendly, and effective software solution is driven by our desire to help those in need during times of crisis. Our platform will be designed with the needs of responders and disaster-affected communities in mind, and we are committed to engaging with these stakeholders throughout the development process to ensure that we are creating a tool that truly meets their needs. Ultimately, our goal is to empower responders with the information and tools they need to help those affected by disasters quickly and effectively.

From the beginning of the project, we are trying our best to prepare a well-documented project repository. At the beginning, all the team members started to use GitHub repository. We firstly created our own wiki pages to provide information about us. Then, we created home page for our project and added all the works that we have done since the beginning of the project to the relevant pages. Also, we inserted relevant links to these pages to the Wiki sidebar.

In GitHub Repository, we managed our project through issues & discussions that GitHub provide. We created our labels first. Then, we started to open issues to distribute work among us and descriptions of the works that must be done. We also inserted labels to prioritize, describe the work.

We created a communication plan and determined weekly meeting time as Wednesday 19.00 face-to-face. In every meeting, we discussed what should be done until next week and who will work on specific tasks and with whom. At the end of the meetings, we opened issues regarding the tasks and assigned them.

Our first task was researching. All the team members searched either an API or a software tool and documented them in our Research wiki page.

After researching, we started to think about our project and we started to prepare requirements with our customers. Requirements are divided into two parts: functional and nonfunctional. After first meeting with the customers, we prepared a Google Docs document and wrote the requirements and our questions about the requirements to clarify them and agree on them.

After requirement elicitation, we scheduled a weekly meeting and started to work on Mockups & Scenarios. We needed Mockups & Scenarios to exactly understand that we are in the same page with our customers and demonstrate them how the project will look like. In the design of Mockups & Scenarios, we worked as teams of 2-3 people. We collaboratively designed our Mockups & Scenarios, and discussed with each other how to do specific parts of the Mockups & Scenarios based on requirements.

With our Mockups & Scenarios, we started to work on 3 kinds of diagrams: Use-case Diagrams, Class Diagrams, and Sequence Diagrams. This part of the project was very crucial since we were gradually approaching to decide how our system will work, which classes will it have and how the users will interact with our system. Firstly, we created Use Case diagrams to see what each type of user can do. In this process, our requirements & Mockups helped us a lot and facilitated our work. After completing use case diagrams, we scheduled a meeting and started to work on Class Diagrams. We defined necessary classes, their functions and fields and how they will interact with other classes in our Class Diagram. At the end, with the help of Use Case Diagrams and Class Diagrams, we created Sequence Diagrams and completed successfully all of the diagrams needed.

As a final task for the Milestone 1, we created RAM (Responsibility Assignment Matrix) and our Project plan. Everyone filled boxes in the RAM table according to their work done until now. In addition, every team member prepared their Individual Project Reports.

We are highly motivated since the beginning of the project. Since a devastating disaster happened in our country, we felt responsible to do something that can help people in the future disasters. Because of that, we tried hard to do our best until now. And from now on, we will continue to try our bests.

Deliverable	Status	Due Date
Project repository: up to date wiki pages (as usual constant gardening), issue tracking	Delivered on time	Monday, April 10, 2023, 23:59 PM
Software Requirement Specification	Delivered on time	Monday, April 10, 2023, 23:59 PM
Scenarios, and Mockups	Delivered on time	Monday, April 10, 2023, 23:59 PM
Software design documents in UML: Use Case, Class, and Sequence Diagrams	Delivered on time	Monday, April 10, 2023, 23:59 PM
Project Plan	Delivered on time	Monday, April 10, 2023, 23:59 PM
RAM (Responsibility Assignment Matrix)	Delivered on time	Monday, April 10, 2023, 23:59 PM
Communication Plan	Delivered on time	Monday, April 10, 2023, 23:59 PM
Milestone Report 1	Delivered on time	Monday, April 10, 2023, 23:59 PM

All deliverables for Milestone 1 have been completed on time, with only minor adjustments to our initial project plan. The addition of a new feature required some reallocation of resources, but the impact on the project timeline is negligible. The team's ability to adapt to changes and effectively communicate has helped mitigate potential issues. Also, completing each weekly tasks on time was helpful for us to process smoothly until now.

Through the planning, design and implementation of the project, we will mainly use GitHub repository. Our repository welcomes users with README.md which includes information about the project, about the course and team members. Most of the information about the project such as templates, deliverables, reports, plans, designs can be found in our wiki page. We have created more than 40 pages to keep information properly. In addition, we used GitHub issues for work distributions and discussions for discuss certain confusions.

Requirements were an essential part of the project. We elicitated requirements while meeting with our customers and these requirements laid the foundation of our project. Requirements are divided into two main parts: functional and nonfunctional. Functional requirements were related to mostly how will specific parts of the system act. On the other hand, nonfunctional requirements defined how the system will provide in general. As time went by when creating Use case diagrams, we discovered some points that need to be clarified and we reached solutions by discussing them in our weekly meetings. Being on the same page with our customers is so important so that we could provide exactly what they want from us. Also, it was important for us to be on the same page among our team members. So, we tried to distribute each weekly task in a way that every member deals with a sub-type of functional requirements.

In this part, we prepared 5 Mockups & Scenarios for each type of User: Admin, Coordinator, Facilitator, Responder, and Victim. In the scenarios, we tried to refer to each requirement so that they became more understandable to our customers. We worked in groups of 2-3 people during this stage and collaboratively prepared each scenario and mockup. We used Figma for Mockups. These Mockups & Scenarios shed a light on the Use Case Diagrams.

In this stage of the project, we immediately scheduled a meeting since there was a lot of work to do. In the meeting, we distributed our tasks to again teams 2-3 people so that every member could work collaboratively and take part in each part of diagram creation. We firstly decided on the platform that we will use to create diagrams and opted for diagrams.net. Then, we started creating Use case diagrams for each User roles. In this part, Scenarios helped us a lot and facilitated our work. After completing the whole Use case diagram, we switched to designing Class diagram. We collaboratively worked on deciding what each class will have as methods & fields and how they will interact with each other. At the last stage, with the help of both Use Case diagram and Class diagram, each team member prepared Sequence diagrams. Although we designed all of the diagrams for now, it may be necesary to modify some parts of them in later times of the project lifespan. Also, we realized that these diagrams will help us a lot in the implementation part of the project later.

Project plan is created based on Responsibility Assignment Matrix. Firstly, we created a Google Spreadsheet document and inserted what we have done until now. Then, every group member filled their columns according to the responsibilities that they had since the beginning of the project. Then, we created the project plan to display the responsibilities with timeline. We used ProjectLibre application for creating the project plan. We inserted our weekly tasks, their lifetime, and the person who was responsible for that certain task. We have inserted all the tasks that we are assigned until now.

Project plan and RAM are useful for us to see who handled which task clearly. Actually, it would be better if we know about this earlier.

In the first days of our project, we come together and meet with each other. Then, we started planning the project. We first made a decision about our communication plan. We created a WhatsApp group for instant messaging between group members. Then, we decided to hold our weekly meetings on Wednesday at 19.00 at our university. Lastly, we created a Discord server to use for online meetings and document sharing.

We used GitHub for issue tracking, discussions and collaboration on project documents. It has proven to be an effective tool for managing our project.

Our primary communication platform. It has allowed for quick and easy communication among team members and facilitated efficient problem-solving.

Used mainly for quick & instant messaging with team members, scheduling extra meetings using polls so that it will fit every member.

As the name suggests, it is mainly used for creating diagrams. It was an excellent app for creating diagrams and working together with the team members at the same time since it allows co-editing.

Used for sharing and collaborating on documents and diagrams. It has been a useful platform for organizing our files and collaborating in real-time.

It was easy to use and advantageous for collaborative work. We created our mockups and also our design artifacts on Figma. These tools and processes have contributed to our project's success thus far, and we will continue to use them as we move forward.

Since the project requires us to progress each week and do different kinds of work, we needed to meet regularly to discuss what should be done and how the work should be distributed among team members. We hold weekly meetings face-to-face to clearly express our ideas and discuss the meeting topics. In each weekly meeting, we addressed the topics covered that week and we kept meeting notes for each meeting so that members who couldn't attend the meeting can easily learn about the main ideas discussed in meetings. We first revise the work done until now and try to clarify if there is uncertainty/confusion in team members' minds. Then, we focus on the topic of the week and we create tasks and distribute them among team members so that each member can do a part of that week's tasks. Also, we try to distribute different parts of the project to each member so that every member can fully understand what each component of the system does. For example, if a person designs Mockups & Scenarios for Responder, he/she should be assigned to another type of User for diagrams so that he/she can deal with different parts of the project.

Customer Meetings were crucial since the product is described by the customers and we, as developers of the product, need to fully understand and meet their requirements about the project. For this reason, we met with our customers during the requirement elicitation process so that we can ensure that we are on the same page with our customers.

GitHub Discussions and Issues were helpful for creating tasks, discussing tasks, distributing tasks, and providing information about what parts of the project are we currently working on. We prepared an Issue Template to use in our issues. For issue tracking and management, the Issue template was helpful. We also used labels to define the issue in a brief format. Issue labeling also provides filtering by label, which could be helpful for finding/editing relevant issues later. During meetings, we distribute the tasks that we need to complete that week and decide on a deadline for that tasks. In addition, we try to observe each others' work so that everything is fine with the project.

• Kübra Aksu's Individual Report

• Furkan Bülbül's Individual Report

• Sezer Çot's Individual Report

• Alperen Dağı's Individual Report

• Ilgaz Er's Individual Report

• Harun Reşid Ergen's Individual Report

• Çağrı Gülbeycan's Individual Report

• Volkan Öztürk's Individual Report

• Cem Sarpkaya's Individual Report

• Muhammet Ali Topcu's Individual Report

---

Requirements: Software Requirement Specification

Glossary

• Account: A personal profile created by a user to access the system's features and services.
• Action: A specific tasks or activities that need to be taken in response to a event.
• Admin: A user role responsible for the maintaining the system.
• Automatic authentication: A verification mechanism that automatically verifies a user's identity or credentials.
• Ban: A feature that blocks a user from accessing the system due to non-compliance with the system's policies or inappropriate behavior, including system abuse or misinformation.
• Coordinator: A user role responsible for managing and coordinating the response efforts. Coordinator is the user that has the most permissions.
• Due date: A deadline set for a task to be completed.
• Event: A specific occurrence or situation that requires action.
• Facilitator: A user role responsible for providing accurate information on the needs and situation of the victims and communities. Also verifies the actions that are conducted by responders.
• Feedback: Comments or suggestions given by the facilitator or responder about a specific action or task.
• Information: A knowledge or data that is communicated or received about a particular subject or event(A fire broke out, a hospital opened etc.).
• Live statistics: Statistics that admins can see. They include the number of users, the number of actions completed, in-progress, on-hold, etc.
• Manual authentication: A verification mechanism that requires a human to verify a user's identity or credentials.
• Multilingual: A system or platform that supports multiple languages.
• Need: A specific requirements or functionalities that are required to be included in the system.
• Resource: Refers to both labor(medical support, driving, etc.) and materials(food, clothing, tents, etc.).
• Request: A user-generated submission that requires a response or action from another user.
• Responder: A user role for individuals who provide assistance to the victims, such as delivering supplies or offering medical care.
• Status: A label that indicates the current state of a task or request, such as completed, in progress, or rejected.
• Sufficient Information: Consists of standard information such as contact information and information change according to the type of resource(s) that the responder wants to provide.
• Task: A specific action that needs to be performed by the responders to fulfill a user's request.
• To-do list: A list of tasks or actions that need to be completed, often used for tracking progress.
• Translation feature: A feature that automatically translates text from one language to another.
• User: A user that uses the system with different purposes designated by respective role.
• Verification mechanism: A process to authenticate and verify the identity and credentials of the (mainly) facilitator user role.
• Verify: The process of accepting or validating a user's request or action by a coordinator or facilitator or responder.
• Victim: A user role for individuals affected by a disaster (multiple disasters) that require assistance & support and possibly have some needs.

Requirements

1. Functional Requirements

• 1.1 User Requirements

  • 1.1.1 Users shall be able to create an account on the system.

  • 1.1.2 Users shall have at least one of the roles below:

    1.1.2.1 Victim

    • 1.1.2.1.1 Everyone shall be able to be a victim after providing sufficient information to the system.
    • 1.1.2.1.2 Victim shall be able to give information about the current situation (primarily his/her needs.)
    • 1.1.2.1.3 Victim shall be able to see important locations. (Help centers, soup kitchens etc.)
    • 1.1.2.1.4 Victim shall be able to get notifications and directions whenever any kind of help is available for him/her.
    1.1.2.2 Coordinater

    • 1.1.2.2.1 Coordinators shall be assigned by admins.
    • 1.1.2.2.2 Coordinators shall be unassigned by admins only.
    • 1.1.2.2.3 Coordinators shall be able to suspend a user if this user is not a coordinator or admin.
    • 1.1.2.2.4 Coordinators shall be able to request a responder to take a specific action. The coordinator must provide all the necessary information for the action.
    • 1.1.2.2.5 Coordinators shall be able to create tasks consisting of to-do action lists that can be marked as completed by responders, allowing for easy progress tracking of the tasks
    • 1.1.2.2.6 Coordinator shall be able to remove the assignee(s) from the task.
    • 1.1.2.2.7 Coordinators shall be able to get notifications for new responders signed up to the system for specific needs.
    • 1.1.2.2.8 Coordinators shall be able to view all user profiles, actions, and information provided by facilitators.
    • 1.1.2.2.9 Coordinators shall be able to view, delete or reply to the requests.
    • 1.1.2.2.10 Coordinators shall be able to share information and update information shared by themselves.
    • 1.1.2.2.11 Coordinators shall be able to delete or update information shared by facilitators.
    • 1.1.2.2.12 Coordinators shall be able to view, delete or reply to reported problems.
    • 1.1.2.2.13 Coordinators shall be able to send requests to the admins.
    1.1.2.3 Facilitator

    • 1.1.2.3.1 Responders and victims can apply for a facilitator role.
    • 1.1.2.3.2 Facilitator role shall require an additional verification mechanism.
    • 1.1.2.3.3 The facilitator role shall be granted through automatic authentication by the system, or through manual authentication by a coordinator or an admin.
    • 1.1.2.3.4 Facilitators shall be able to create requests.
    • 1.1.2.3.5 Facilitators shall be able to create resources.
    • 1.1.2.3.6 Facilitators should be able to view the needs of the victims and include the victims' needs in the facilitators' requests.
    • 1.1.2.3.7 Facilitator shall be able to update requests. Updates should be trackable.
    • 1.1.2.3.8 Facilitator shall be able to give feedback about any ongoing actions that are sent by the coordinators.
    • 1.1.2.3.9 Facilitators should verify action requests that are sent by responders.
    • 1.1.2.3.10 Facilitators shall be able to share information and update information shared by themselves.
    1.1.2.4 Responder

    • 1.1.2.4.1 Responder shall provide the necessary resources. Responders shall be able to add information about resources they can provide to their profiles to be used later
    • 1.1.2.4.2 Everyone shall be able to be a responder after providing sufficient information to the system.
    • 1.1.2.4.3 Responders shall be able to accept or decline an offer to accomplish a task assigned by the coordinator.
    • 1.1.2.4.4 Responders shall be able to comment using the sections on the windows provided for their actions.
    • 1.1.2.4.5 Responders shall be able to update the statuses of their tasks. The statuses are: not started, in progress, and completed.
    • 1.1.2.4.6 Responders shall be able to view all information provided by facilitators.
    • 1.1.2.4.7 Responders shall be able to tick boxes in a to-do list if a to-do list is provided by coordinators for action in order to track the series of actions.
    • 1.1.2.4.8 Responders shall be able to see their current and previous tasks.
    1.1.2.5 Admin

    • 1.1.2.5.1 Admins shall be able to assign coordinator and facilitator roles to designated users.
    • 1.1.2.5.2 Admins shall delete the user roles if there is any abuse or misuse related to that user.
    • 1.1.2.5.3 Admins shall see any bug reports about the system and respond & fix it.
    • 1.1.2.5.4 Admins shall help to the coordinators whenever technical assistance is needed.
    • 1.1.2.5.5 Admins shall manually verify any document that requires verification whenever needed.
    • 1.1.2.5.6 Admins should dynamically provide new additions to the system according to user needs and feedback.
    • 1.1.2.5.7 Admin role shall only be given by the project owners.
    • 1.1.2.5.8 Admin shall send notifications to other admins.
    • 1.1.2.5.9 Admin shall see the live statistics of the system.

  • 1.1.3. Users shall be able to view the map and share their current location information on the map.

  • 1.1.4. Users shall be able to search and filter among the information provided by facilitators.

  • 1.1.5. Users shall be able to report a warning about current disasters.

• 1.2 System Requirements

  • 1.2.1 Multi-hazard support
    • 1.2.1.1 The system shall provide multi-hazard support, meaning that it should be able to handle and respond to multiple types of disasters and emergencies, such as natural disasters (e.g. earthquakes, floods, hurricanes), man-made disasters (e.g. explosions, fires, terrorist attacks), and public health emergencies (e.g. pandemics, epidemics). The system must be flexible enough to accommodate different needs and response strategies depending on the type of disaster.
  • 1.2.2. Multilingual Support
    • 1.2.2.1. The platform must be multilingual to provide use for multinational people.
  • 1.2.3 Resource Management
    • 1.2.3.1. Digitized resources
      • 1.2.3.1.2. Resources should be quantized and digitized on the system.
    • 1.2.3.2. Categorization of resources,
      • 1.2.3.2.1. To facilitate distribution, sent resources should be categorized in detail, including the contents of each box, quantity, shoe/clothing size, etc.
    • 1.2.3.3. Semantic relations between resources
      • 1.2.3.3.1. Resources should have semantic relations. For example, boots and shoes or heaters and blankets should have the same categories as they meet similar needs.
    • 1.2.3.4. Dynamic needs
      • 1.2.3.4.1. The platform should be flexible enough to adapt to the changing needs of disaster areas, depending on the location and stage of the disaster. This includes different needs in urban and rural areas, as well as different needs for surviving the disaster and educational needs.
  • 1.2.4. Event Creation
    • 1.2.4.1. Creating New Events
      • 1.2.4.1.1. The system shall allow users to create new events to notify other users of new supplies, requests for help, or other relevant information.
      • 1.2.4.1.2. The system shall require users to provide details such as the event type (e.g., new supply arrival, urgent medical need), the event location, and any additional relevant information.
      • 1.2.4.1.3 The system shall allow people to prioritize events.
      • 1.2.4.1.4. The system shall ensure that all required fields are filled in before an event can be created.
    • 1.2.4.2. Target Audience
      • 1.2.4.2.1. The system shall provide a feature for users to specify the target audience for the event (e.g., all users, users within a certain distance of the event location, and users with specific skills or resources).
    • 1.2.4.3. Duration and Visibility
      • 1.2.4.3.1. The system shall allow users to specify a duration or expiration date for the event, after which it will no longer be visible to users.
    • 1.2.4.4. Event Filtering
      • 1.2.4.4.1. The system shall allow users to filter events based on various criteria, such as event type, location, and target audience.
    • 1.2.4.5. Event Categorization
      • 1.2.4.5.1. The system shall provide a feature to categorize the events based on different types of events such as supply notifications, medical needs, etc.
  • 1.2.5. Actions
    • 1.2.5.1 Creating new actions
      • 1.2.5.1.1. The system shall allow authorized users to create new actions in response to disaster events.
      • 1.2.5.1.2. The system shall allow authorized users to provide action details such as the action type, the target group, and the due date.
      • 1.2.5.1.3. The system shall ensure that all required fields are filled in before an action can be created.
      • 1.2.5.1.4. The system shall provide a feature to categorize the actions based on different types of actions such as transportation, supply delivery, medical aid, etc.
    • 1.2.5.2. Assigning tasks
      • 1.2.5.2.1. The system shall allow authorized users to assign specific tasks to other users.
      • 1.2.5.2.2. The system shall allow authorized users to set deadlines for task completion.
    • 1.2.5.3. Prioritization
      • 1.2.5.3.1. The system shall provide a feature to prioritize actions based on their urgency and impact on the affected population.
    • 1.2.5.4. Linking Actions to Events
      • 1.2.5.4.1. The system shall allow authorized users to link the action to the corresponding event.
      • 1.2.5.4.2. The system shall notify users who have expressed interest in the event.
    • 1.2.5.5 Actions Filtering
      • 1.2.5.5.1. The system shall allow users to filter actions based on various criteria, such as action type, location, and target audience.
  • 1.2.6. Action Tracking
    • 1.2.6.1. Tracking action progress
      • 1.2.6.1.1. The system shall allow authorized users to track the progress of each action and its associated tasks.
      • 1.2.6.1.2. The system shall provide a feature to notify users when tasks are overdue or completed.
      • 1.2.6.1.3. The system shall allow authorized users to update the status of each action and its associated tasks.
    • 1.2.6.2. Generating reports
      • 1.2.6.2.1. The system shall provide a feature to generate reports on the overall progress of the disaster response efforts, including completed and pending actions, as well as their impact on the affected population.
  • 1.2.7. Map-based operations
    • 1.2.7.1. The platform should have a map-based interface that displays the warnings, where disasters occur most, actions, events taken during the disaster,
    • 1.2.7.2 The platform should have map can have various filtering options like location, category etc..
    • 1.2.7.3 The platform should allow creating path on the map.

2. Non Functional Requirements

• 2.1 Security and Privacy
  • 2.1.1. Data protection regulations
    • 2.1.1.1 The platform should prioritize and comply with data protection regulations such as GDPR/KVKK
  • 2.1.2. Personal information protection and confidentiality
    • 2.1.2.1 Personal information and contact details of individuals affected by the disaster should be protected and kept confidential.

Requirements: Scenarios & Mockups

Scenario 1 : Responder

User Profiles

	Ahmet Ahmet is a 34 years old businessman living in Istanbul, Turkey. He has a transportation company, located at Ümraniye, with many transportation vehicles such as trucks and buses. He is a benevolent person, that is why he registered to our Disaster Response Platform. After some time, an earthquake happened in Kahramanmaraş, Turkey. So, he is willing to help the disaster region immediately.
	Mehmet Mehmet is a 30 years old truck driver living in Üsküdar, Istanbul. He is a helpful person. After an earthquake happened in Kahramanmaraş, he decided to take action and he discovered our Disaster Response Platform and signed up immediately and completed his profile. So, he is ready to help.

Preconditions

1. Since Ahmet provides resources, he added necessary information to the system so that coordinators can be aware of him. He added information about himself and his company. The information he provides includes his real name and surname, place of residence, phone number, e-mail address, name of his company, location of his company, the contact information of people responsible for communication during a disaster on behalf of his company, and detailed information of resources that company is ready to provide (in this case Transportation/Bus and Transportation/Truck) such as the number, capacity, license plate of his trucks and busses, So, he is already signed in to the platform.
2. Mehmet completed his profile and he also selected what services he can provide (in this case, he can serve the disaster region as Transportation/Truck Driver.).

Addressed Requirements for Responder

• 1.1.2.4.1 Responder shall provide the necessary resources. Responders shall be able to add information about resources they can provide to their profiles to be used later
• 1.1.2.4.2 Everyone shall be able to be a responder after providing sufficient information to the system.
• 1.1.2.4.3 Responders shall be able to accept or decline an offer to accomplish a task assigned by the coordinator.
• 1.1.2.4.4 Responders shall be able to comment using the sections on the windows provided for their actions.
• 1.1.2.4.5 Responders shall be able to update the statuses of their tasks. The statuses are: not started, in progress, and completed.
• 1.1.2.4.6 Responders shall be able to view all information provided by facilitators.
• 1.1.2.4.7 Responders shall be able to tick boxes in a to-do list if a to-do list is provided by coordinators for action in order to track the series of actions.
• 1.1.2.4.8 Responders shall be able to see their current and previous tasks.

Scenario

1. Ahmet sees a task assigned by the coordinators to provide 10 trucks.
2. Ahmet approves to do the task.
3. After 2 hours Mehmet completed his profile, he gets a notification that one of the coordinators wants to assign him a task. He sees that he must go to Ümraniye where Ahmet' s company is located and get one of his trucks. Then, he must drive to Kadıköy Anadolu High School where he gets boxes of aid collected by philanthropists. There is also the name and contact information of a responsible person. He must find that person when he arrives at the location. Then he must drive to Hatay Science School where earthquake victims stay. There is also contact information for a responsible person whom Mehmet must find after arriving in Hatay. Mehmet accepts the task.
4. After Mehmet's approval, one truck is reserved for him for some time. If he couldn't appear at the truck company's location before due time, his truck could be requested by some other helpful truck drivers.
5. After Mehmet went out from his house to go to Ümraniye, he changes the status of the action from "not started" to "in progress"
6. Mehmet appears at the company's location before due time and he is again validated as a truck driver there.
7. After a while, Mehmet goes to Kadıköy where the aid is prepared to be sent. All aids were categorized and collected (For example, trousers are collected according to their size.).
8. After truck is loaded, Mehmet ticks the box to inform coordinators that his truck is ready to go with 15 packages each containing a certain number of materials (For example 2 packages of trousers each are classified according to the gender and size.).
9. When one of the coordinators sees his action, this coordinator gives him necessary information about where he should drive, they offer him and after he accepts, he starts driving.
10. While driving, he may encounter some transportation difficulties (For example, a road may have become unusable due to the disaster.). To inform the coordinators he could report a problem.
11. After a while, Mehmet comes to the area where the aid is collected and distributed to the victims. He calls Berke who is the responsible person to meet Mehmet.
12. So, Mehmet completes his action and informs the platform about it.

Mockups

---

Scenario 2 : Facilitator

User Profile

Zeynep Zeynep is a university student in Istanbul. Her family resides in Hatay. So, when the earthquake happened, she was devastated. Thankfully, she contacted her family and found out they were fine. However, she has many relatives in Hatay. She wanted to help her family, friends, and the people of her city. She has many contacts in the region and she went to the disaster region. The first that came to her mind is a disaster response platform developed by her friends to meet her relatives’ needs.

Preconditions

1. Since Zeynep needs to enter requests from a variety of people, she signed up the system to enter the info she had. She entered her detailed information to be validated by the platform (by admins or by the coordinators).
2. She was supposed to create requests for the victims in the disaster area. Since the coordinators should allocate effort to meet exact needs in the area, she entered the detailed request including the type, location, number of people in need, categorization of material if needed.

Addressed Requirements for Facilitator

• 1.1.2.3.1 Responders and victims can apply for a facilitator role.
• 1.1.2.3.2 Facilitator role shall require an additional verification mechanism.
• 1.1.2.3.3 The facilitator role shall be granted through automatic authentication by the system, or through manual authentication by a coordinator or an admin.
• 1.1.2.3.4 Facilitators shall be able to create requests.
• 1.1.2.3.5 Facilitators shall be able to create resources.
• 1.1.2.3.6 Facilitators should be able to view the needs of the victims and include the victims' needs in the facilitators' requests.
• 1.1.2.3.7 Facilitator shall be able to update requests. Updates should be trackable.
• 1.1.2.3.8 Facilitator shall be able to give feedback about any ongoing actions that are sent by the coordinators.
• 1.1.2.3.9 Facilitators should verify action requests that are sent by responders.
• 1.1.2.3.10 Facilitators shall be able to share information and update information shared by themselves.

Scenario

1. She reached out to as many people as she could. Also, after a while, the people started to contact Zeynep.
2. She first called her family and wanted to learn about their needs. Her family lives in the city center and their house seems fine but they do not want to go inside. While her family informs Zeynep, they did not only convey their need but also their neighbors'. Zeynep entered the info that has types of shelter, clothing, food, medicine requests, and number of people in need. She also had the information of categorization of types like woman-man clothing, baby food. After all, she was able to enter all information in detail including location.
   1. Coordinators assigned responders to provide resources for their need.
   2. Later, tents, clothing, and other resources were supplied to her family and neighbors. However, they got less than the request so, their need is partially met. She edited the request according to the amount they got.
   3. When the final part of their need was met by the responders Zeynep has closed the request.
3. She continued to gather information from the field. Unfortunately, a friend of hers expects a rescue team to get them out from the rubble. A German rescue team is nearby but communication is a problem. They need a translator, and she enters a request for a person who knows German. She also enters details like location, rubble detail, etc.
   1. One speaking German found in Kahramanmaraş, and assigned by the coordinator. He got on his way to Hatay.
   2. After a while, thanks to her request a translator was found to translate for a German rescue team. The translator helped the rescue to team to work around the rubble. Fortunately, her friend survived the disaster.
   3. Zeynep informed the platform and closed the request.
   4. The translator and the rescue team continued to work together in different locations to save other people.
4. While the time went by, different kinds of needs appeared. Her grandfather resides in the village of Hatay. His house is still standing since it is a one-floor home. So, they do not need accommodation, but they do need different kinds of resources. He is an old man, and he uses medicine for his chronic disease. However, his medicine stock depleted. Zeynep created a new request entry for her grandfather’s medicine. In this case transportation to villages is a little bit vague since the navigation application may be insufficient. So, she put a description of the way (direction) to the village along with other information. Another reason direction is needed within the entry is the carrier is possibly from a different area and does not have enough information about the transportation to villages.
5. 1. Coordinator found the medicine and a responder -carrier- to take medicine to the village.
   2. The carrier got on his way to take medicine to her grandfather. However, the described road was unusable. The feedback from the carrier was added to the current situation of the request. The status was changed from ‘in progress’ to ‘blocked’ as the help could not be delivered since the road was unusable to the village.
   3. Coordinator assigned resources to make the road usable again and medicine along with other possible help was delivered.
6. Zeynep tracked down all requests -including created by others- that she could, and helped the response to a disaster by using the platform.

Mockups

---

Scenario 3 : Coordinator

User Profiles

Ayşe Ayşe is a 42-year-old employee in Ahbap, a non-governmental organization that focuses on disaster relief efforts. Prior to the disaster, Ayşe was already a registered user of the disaster platform. As a disaster coordination and assistance worker, she applied to become a coordinator in the system through Ahbap, and her application was approved by the administrators. Thus, she became responsible for coordination processes and creating action in the system during a crisis. After a devastating earthquake hit Kahramanmaraş region, many people, both those in need of resources and those providing supply, logged in to the system. As a coordinator, Ayşe is responsible for matching the available supplies with the demands and creating action plans to manage logistics and coordinate the disaster response. To do this effectively, she needs highly efficient workflows to categorize information, visualize it, and coordinate different actions.

Preconditions

1. Ayşe was registered to the system before the disaster occurred.

2. A governmental or non-governmental organization nominated Ayşe to become a coordinator.

3. Administrators confirmed Ayşe’s appointment as coordinator.

4. Ayşe was familiar with the system before the disaster.

5. Ayşe should also be familiar with the conditions on the ground also through other means.

6. Ayşe has reliable internet access.

Addressed Requirements for Coordinator

• 1.1.2.2.1 Coordinators shall be assigned by admins.
• 1.1.2.2.2 Coordinators shall be unassigned by admins only.
• 1.1.2.2.3 Coordinators shall be able to suspend a user if this user is not a coordinator or admin.
• 1.1.2.2.4 Coordinators shall be able to request a responder to take a specific action. The coordinator must provide all the necessary information for the action.
• 1.1.2.2.5 Coordinators shall be able to create tasks consisting of to-do action lists that can be marked as completed by responders, allowing for easy progress tracking of the tasks
• 1.1.2.2.6 Coordinator shall be able to remove the assignee(s) from the task.
• 1.1.2.2.7 Coordinators shall be able to get notifications for new responders signed up to the system for specific needs.
• 1.1.2.2.8 Coordinators shall be able to view all user profiles, actions, and information provided by facilitators.
• 1.1.2.2.9 Coordinators shall be able to view, delete or reply to the requests.
• 1.1.2.2.10 Coordinators shall be able to share information and update information shared by themselves.
• 1.1.2.2.11 Coordinators shall be able to delete or update information shared by facilitators.
• 1.1.2.2.12 Coordinators shall be able to view, delete or reply to reported problems.
• 1.1.2.2.13 Coordinators shall be able to send requests to the admins.

Scenario

1. Ayşe logs into the Disaster Response Platform and navigates to the dashboard where she can see the list of responders and their resources.

2. Ayşe approves a facilitator request from an aid center located in the disaster area, granting the user "Facilitator" authority. With this new role, the user can create requests on behalf of victims based on the latest information from the region, helping to coordinate a more effective response effort. Now, Ayşe can see the demands of this facilitator on the dashboard.

3. A facilitator makes an urgent request for 600 boxes of food to be delivered to an aid center in Elbistan. Ayşe receives the request and quickly locates available food resources by filtering the resources on the platform's map and dashboard.

4. Ayşe checks the dashboard and finds 600 available boxes of food located at a resource collection point in Ankara. She then creates an action using this resource. Then, she tries to locate an available actor with a suitable vehicle that can pick up the food and deliver them to the aid center. She cannot find a truck with a driver, but truck owners looking for a driver and drivers looking for a truck appear on the dashboard.

5. Ayşe matches a driver with an available truck and creates an action for the driver to go and get the truck. She fills the required fields of the action creation such as type of action, location, urgency, time frame, etc. This action appears as a path to Ayşe on the map (driver to truck), and she can track this action and monitor its progress until it is completed.

6. After the driver obtains the truck, she creates a path for the driver to take the tents in the collection center in Ankara and send them to the aid center in the disaster area in Elbistan, and gives this task to the truck driver. Instead of assigning these actions to the driver one by one, it creates a to-do list that assigns them all. After the all actions in the to-do list are checked by the driver, as the final stage of the task, the facilitator from the aid center must confirm that the necessary resources have reached the area and that the task has been completed.

7. After the facilitator receives the food and confirms the shipment is complete, the task is tagged as completed.

Mockups

---

Scenario 4 : Victim

User Profile

Naila Naila is a high-school student in Adana and she is a resident of this city with her family. They are staying in a village. When the earthquake happened, she and her family were victims. Their house collapsed, they are physically healthy but they are now in a miserable situation. They are staying outside of their house and the weather conditions are extremely hard. It’s very cold and always raining. It is not possible to find any shelter, any heating, any food or any water. Also, they have a few cows and they also need decoys. There is also a big problem for them. She and her family members don’t know Turkish. They just know Arabic. And this can make everything worse for them because they will have problems with communicating with facilitators in the area. Moreover, the only person who knows how to read and write in the family is Naila and she has to take the responsibility of reporting and finding needs for all of them.

Preconditions

1. Naila has a device with an internet connection.
2. Naila has access to the disaster response platform website or application.

Adressed Requirements for Victim

• 1.1.2.1.1 Everyone shall be able to be a victim after providing sufficient information to the system.
• 1.1.2.1.2 Victim shall be able to give information about the current situation (primarily his/her needs.)
• 1.1.2.1.3 Victim shall be able to see important locations. (Help centers, soup kitchens etc.)
• 1.1.2.1.4 Victim shall be able to get notifications and directions whenever any kind of help is available for him/her.

Scenario

1. Naila opens the disaster response platform website or application on her device.
2. Naila grants the platform permission to access her location using geolocation technology.
3. Naila signs up for the platform, providing her information, including her language preference.
4. The platform validates Naila's information, including her Turkish ID number.
5. Naila is directed to the multilingual version of the platform.
6. The platform displays a map with Naila's location and nearby aid organizations.
7. Naila uses the platform's filter feature to display aid organizations in her vicinity.
8. Naila views the types of aid provided by each organization and their contact information.
9. Naila enters request by category feature of request. She can find categories suitable for her family and neighbors vital needs also specific needs such as medications for chronic diseases.
10. Naila also can find categories for the needs of her family cows such as decoys.
11. Naila prioritizes urgent needs such as medications for chronic diseases.
12. Naila receives automated notifications from the platform, displaying helpful information such as the closest hospital, pharmacy, food area, and clothing sharing areas. Especially if there is new facility she should learn and see this information.
13. Naila can edit her entry as needed, such as updating or removing request.
14. Naila states the needs of others who may not be able to access or use the platform by updating her request.
15. The platform is multilingual to accommodate Naila's Arabic language preference.
16. It has a translation feature that allows for semantic matching of needs.
17. Overall, the multilingual disaster response platform provides Naila and her family with the necessary resources and information to help them during this difficult time. By using the mapping feature, Naila is able to locate nearby aid organizations and receive the aid they need. The multilingual system and semantic matching feature ensure that she can state her needs accurately and effectively, and the history and editing features allow her to keep track of any changes made to her entries.

Mockups

---

Scenario 5 : Admin

User Profile

	Buğra Buğra is a member of the project team and worked hard for the development of the platform. Now he is maintaining the system as an admin.

Preconditions

1. Since Buğra worked in the development in project for a long time he knows the system and the requirements very well. Project owners decided to make him one of the admins because of his experience with the project. So, project owners asked from an existing admin to create an admin user for the Buğra. Admins provided necessary information (username & passphrase & other type of passphrases for specific actions) to Buğra. Now, Buğra is ready to work and help as admin.

Scenario

1. Buğra enters the system as admin with the given information.
2. One of the project owners calls to Buğra and asks for some statistics about the system.
3. Buğra looks at the live statistics in the bug reports page, and informs the project owner accordingly.
4. Admin Buğra gets a phone call from one of his closest friends named Yaren that is in the disaster area and continues her work as a volunteer. She tells him that she wants to contribute as facilitator but she does not have any document that are eligible for automatic authentication. Thus, she needs to be assigned manually as a facilitator. Buğra gets her credentials via phone and writes them in a text file. Then, Buğra assigns her as a facilitator
5. Buğras's friend Yaren gets a notification about its approval as a facilitator role. She starts to help using the platform immediately.
6. One of the project owners calls Buğra and says that the upcoming meeting is postponed one hour. He wants from Buğra to send notification tot he active admins about this issue in the case that they have not seen the mail that is sent by the project owner.
7. Buğra opens notification page and sends a notification to the all active admins.
8. One of the project owners again calls Buğra and wants a user to be assigned as a coordinator.
9. Buğra opens assignment page and assigns the coordinator role to the mentioned user.

Addressed requirements

• 1.1.2.5.1 Admins shall be able to assign coordinator and facilitator roles to designated users.
• 1.1.2.5.3 Admins shall see any bug reports about the system and respond & fix it.
• 1.1.2.5.6 Admins should dynamically provide new additions to the system according to user needs and feedback.
• 1.1.2.5.7 Admin role shall only be given by the project owners.
• 1.1.2.5.8 Admin shall send notifications to other admins.

Mockups

Software Design: Use Case Diagram

Software Design: Class Diagram

Software Design: Sequence Diagram

Project Plan

RAM (Responsibility Assignment Matrix)