In the second milestone of our disaster response project, we focused on enhancing the functionalities of resource and request creation, and user account management. Our approach was grounded in realistic disaster response scenarios, ensuring that our platform's features are not only functional but also detailed and contextually relevant.

• Implemented comprehensive steps for request and resource creation, tailored to capture specific disaster response needs.
• Special attention to details such as the number of affected individuals, including babies and children, to address their unique needs and psychological impacts.

• Developed a fully functional map feature with backend integration, making it a central component of our platform.
• Created separate, specialized data tables for victims, responders, coordinators, and facilitators.

• Enhanced the account page to include vital health information like diseases and body weight, crucial in disaster scenarios.
• Focused on detailed user profiles to tailor response efforts effectively.

• Ongoing collaboration with stakeholders, with customer insights significantly influencing our development strategy.
• Commitment to consistently responding to customer requests and revising requirements according to real-world needs.

• Developing the software with a strong focus on reliability and user-friendliness, crucial for supporting responders in critical situations.

Our progress in this milestone showcases our commitment to creating a responsive, detailed, and user-friendly platform for disaster response. We are continuously adapting and enhancing our features, guided by customer feedback and the evolving demands of disaster response scenarios.

• 3.1. Software Requirements Specification Report v0.3 | Report v0.3.1 | Requirements latest v
• 3.2. Software Design (UML diagrams)
• 3.3. Scenarios and Mockups Web: Web Scenario | Web Refactored Mockups
• 3.4. Scenarios and Mockups Mobile Mobile Scenario | Mobile Refactored Mockups
• 3.5. Project Plan, Communication Plan, Responsibility Assignment Matrix Project Plan | Communication Plan | RAM
• 3.6. Weekly reports and any additional meeting notes Reports
• 3.7. Milestone Review
• 3.8. Individual Contributions [Check below]
• 3.9. A pre-release version of our software Software

• 1.1.1. User Registration

  • 1.1.1.1. User Account Creation: Users shall be able to create an account on the system. In emergency situations, account creation is not mandatory, and unregistered users are, by default, assigned the "victim" role for immediate access to essential features without mandatory account creation. [COMPLETED]
  • 1.1.1.2. Registration Confirmation and Login: After successful registration, users shall receive a notification confirming the approval of their registration, indicating that the registration process is successful. Users will be automatically redirected to the login page after registration. [IN_PROGRESS]
  • 1.1.1.3. Convenient Sign-In: At the login page, users have the option to save their login information for a convenient sign-in process in subsequent visits, eliminating the need to re-enter their credentials.[NOT_STARTED]
  • 1.1.1.4. Role Request and Emergent Functionalities: After login, users can request new roles, each with its own verification methods. When a user's request for a new role is approved, they will gain access to emergent functionalities associated with that role. These emergent functionalities will include changes to the navbar and page view, with related buttons and options specific to the approved role.[IN_PROGRESS]
  • 1.1.1.5. Emergent Roles After a user's request for a new role is approved, the system shall dynamically adjust the navigation bar (navbar) and page view to reflect the functionalities and options related to the approved role. This shall include displaying role-specific buttons and options that are relevant to the newly assigned role. [IN_PROGRESS]

• 1.1.2. User Roles

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

  • 1.1.2.1. Victim

    • 1.1.2.1.1. Any user should be able to - 1.1.2.1.8. Victim shall be able to get directions to nearby assistence locations. [IN PROGRESS] assume the role of a victim after providing the necessary information to the system. [COMPLETED]
    • 1.1.2.1.2. Victims shall be able to report their current situation and needs. [IN_PROGRESS]
    • 1.1.2.1.3. Victims shall be able to view assistence locations on a map and as a list. (Help centers, soup kitchens etc.) [IN PROGRESS]
    • 1.1.2.1.4. Victims shall be able to filter the assistance locations by type and distance. [IN PROGRESS]
    • 1.1.2.1.5. Victims shall be able to view available resources on a map and as a list. [IN_PROGRESS]
    • 1.1.2.1.6. Victims shall be able to filter resources by name, category and distance. [COMPLETED]
    • 1.1.2.1.7. Victim shall be notified when a relevant assistence location is nearby. [IN PROGRESS]
    • 1.1.2.1.8. Victim shall be able to get directions to nearby assistence locations. [IN PROGRESS]

  • 1.1.2.2. Responder

    • 1.1.2.2.1. Any user wishing to become a responder must upload a valid identification document as a necessity for their role transition in the system. [IN PROGRESS]
    • 1.1.2.2.2. Responders shall be able to create a resource for objects or services they can offer. [COMPLETED]
    • 1.1.2.2.3. Responders shall be able to set the following information regarding a resource: location, quantity, type, category [COMPLETED]
    • 1.1.2.2.4. All users shall be able to view the resources a responder has added in the responder's profile. [IN PROGRESS]
    • 1.1.2.2.5. Responders shall be able to accept or decline task assignments from coordinators. [IN PROGRESS]
    • 1.1.2.2.6. Responders shall be able to comment on their actions using the sections on the windows provided for their actions. [NOT STARTED]
    • 1.1.2.2.7. Responders shall be able to update the status of their tasks as: to do, in progress, completed. [IN PROGRESS]
    • 1.1.2.2.8. Responders shall be able to view all information provided by facilitators. [IN PROGRESS]
    • 1.1.2.2.9. Responders shall be able to see their current and previous tasks. [IN PROGRESS]
    • 1.1.2.2.10. Responders shall be able to view all actions in a task assigned to them as a list and on a map. [NOT STARTED]
    • 1.1.2.2.11. Responders shall be able to mark actions as completed. [NOT STARTED]

  • 1.1.2.3. Facilitator

    • 1.1.2.3.1. Responders and victims shall be able to apply for a facilitator role through an additional verification process. [IN PROGRESS]
    • 1.1.2.3.2. Facilitators shall be able to create requests. [IN PROGRESS]
    • 1.1.2.3.3. Facilitators shall be able to create resources. [IN PROGRESS]
    • 1.1.2.3.4. Facilitators shall be able to view requests on a map and as a list. [COMPLETED]
    • 1.1.2.1.5. Facilitators shall be able to filter requests by name, category and distance. [COMPLETED]
    • 1.1.2.3.6. Facilitators shall be able to group requests made by victims into a larger request. [IN PROGRESS]
    • 1.1.2.3.7. Facilitators shall be able to update the status of requests as: to do, in progress, completed. [IN PROGRESS]
    • 1.1.2.3.8. Facilitator shall be able to provide feedback on any ongoing actions sent by the coordinators. [NOT STARTED]
    • 1.1.2.3.9. Facilitators shall be able to verify action requests from responders. [NOT STARTED]
    • 1.1.2.3.10. Facilitators shall be able to share and update information they provide. [IN PROGRESS]

  • 1.1.2.2. Coordinator

    • 1.1.2.2.1. Coordinators must be assigned by administrators. [NOT STARTED]
    • 1.1.2.2.2. Coordinators shall be able to suspend non-coordinator or non-administrator users. [NOT STARTED]
    • 1.1.2.2.3. Coordinators shall be able to create tasks consisting of a list of actions. [IN PROGRESS]
    • 1.1.2.2.3. Coordinators shall be able to specify details for actions, including name, type of action, location, recommended path from the previous action, and a comment in the form of free-form text. [IN PROGRESS]
    • 1.1.2.2.4. Coordinators shall be able to assign tasks to responders. [IN PROGRESS]
    • 1.1.2.2.5. Coordinators shall be able to remove assignees from tasks. [IN PROGRESS]
    • 1.1.2.1.6. Coordinators shall be able to view resources, requests and tasks as a list and on a map. [IN PROGRESS]
    • 1.1.2.1.7. Coordinators shall be able to filter resources, requests and tasks by whichever subset of name, category, amount, distance, urgency and status is applicable. [IN PROGRESS]
    • 1.1.2.2.8. Coordinators shall receive notifications for new responders signing up. [IN PROGRESS]
    • 1.1.2.2.9. Coordinators shall be able to view all user profiles, actions, and information provided by facilitators. [IN PROGRESS]
    • 1.1.2.2.10. Coordinators shall be able to view, delete or reply to the requests. [IN PROGRESS]
    • 1.1.2.2.11. Coordinators shall be able to share and update information they provide. [IN PROGRESS]
    • 1.1.2.2.12. Coordinators shall be able to delete or update information shared by facilitators. [IN PROGRESS]
    • 1.1.2.2.13. Coordinators shall be able to view, delete or reply to reported problems. [NOT STARTED]
    • 1.1.2.2.14. Coordinators shall be able to send messages to admins. [NOT STARTED]

  • 1.1.2.5. Administrator

    • 1.1.2.5.1. Administrators shall be able to assign and unassign coordinator and facilitator roles to designated users. [NOT STARTED]
    • 1.1.2.5.2. Administrators shall be able to revoke user roles in cases of abuse or misuse. [NOT STARTED]
    • 1.1.2.5.4. Administrators shall be able to provide technical assistance to coordinators. [NOT STARTED]
    • 1.1.2.5.5. Administrators shall be able to manually verify documents when needed. [NOT STARTED]
    • 1.1.2.5.7. Adminstrator role is granted by project owners. [NOT STARTED]
    • 1.1.2.5.8. Administrators shall be able to send notifications to other administrators. [NOT STARTED]
    • 1.1.2.5.9. Administrators shall have access to live system statistics. [NOT STARTED]

• 1.1.3. Location Services

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

• 1.1.4. Information Filtering

  • Users shall be able to search and filter information provided by facilitators. [IN PROGRESS]

• 1.1.5. Disaster Reporting

  • Users shall be able to add and view warnings about the current disaster to the map. [IN PROGRESS]

• Disaster Requirements

• 1.2.1. Multi-hazard support

  • 1.2.1.1. The system shall provide multi-hazard support. The system shall support various types of disasters and emergencies, including 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 based on the disaster type. [NOT_STARTED]

• 1.2.2. Multilingual Support

  • 1.2.2.1. The platform must support multiple languages to cater to a diverse user base. [NOT STARTED]

• 1.2.3. Resource Management

  • 1.2.3.1. Digital Resources

    • 1.2.3.1.2. Resources must be digitized and quantified in the system. [IN PROGRESS]

  • 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. [IN PROGRESS]

  • 1.2.3.3. Semantic relations between resources

    • 1.2.3.3.1. Resources should have semantic relationships for efficient categorization. [IN PROGRESS]

  • 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. [IN PROGRESS]

• 1.2.4. Actions

  • 1.2.4.1. Creating new actions

    • 1.2.4.1.1. The system shall allow authorized users to create new actions in response to disaster events. [IN PROGRESS]
    • 1.2.4.1.2. The system shall allow authorized users to provide action details such as the action type, the target group, and the due date. [IN PROGRESS]
    • 1.2.4.1.3. The system shall ensure that all required fields are filled in before an action can be created. [IN PROGRESS]
    • 1.2.4.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. [IN PROGRESS]

  • 1.2.4.2. Task Assignment:

    • 1.2.4.2.1. The system shall allow authorized users to assign specific tasks to other users. [IN PROGRESS]
    • 1.2.4.2.2. The system shall allow authorized users to set deadlines for task completion. [IN PROGRESS]

  • 1.2.4.3. Prioritization

    • 1.2.4.3.1. The system shall provide a feature to prioritize actions based on their urgency and impact on the affected population. [IN PROGRESS]

  • 1.2.4.4. Linking Actions to Events

    • 1.2.4.4.1. The system shall allow authorized users to link the action to the corresponding event. [IN PROGRESS]
    • 1.2.4.4.2. The system shall notify users who have expressed interest in the event. [IN PROGRESS]

  • 1.2.4.5. Actions Filtering

    • 1.2.4.5.1. The system shall allow users to filter actions based on various criteria, such as action type, location, and target audience. [IN PROGRESS]

  • 1.2.4.6. Tracking action progress

    • 1.2.4.6.1. The system shall allow authorized users to track the progress of each action and its associated tasks. [IN PROGRESS]
    • 1.2.4.6.2. The system shall notify users when tasks are overdue or completed. [IN PROGRESS]
    • 1.2.4.6.3. The system shall allow authorized users to update the status of each action and its associated tasks. [IN PROGRESS]

• 1.2.5. Reporting

  • 1.2.5.1. The system shall generate a live report on outstanding requests, showing the deficit in materiel by location. [NOT STARTED]
  • 1.2.5.2. The system shall generate a live report on the overall progress of the disaster response efforts, including completed and pending actions, as well as their impact on the affected population. [NOT STARTED]

• 1.2.7. Map-based operations

  • 1.2.7.1. The platform shall have a map interface that displays the appropriate subset of resources, requests, and tasks, along with warnings related to the current situation. [IN PROGRESS]
  • 1.2.7.2. The map shall be capable of filtering items by the applciable subset of name, category, amount, distance, urgency and status. [IN PROGRESS]

• 2.1.1. Data protection regulations

  • 2.1.1.1. The platform shall prioritize and fully comply with applicable data protection regulations, including but not limited to the General Data Protection Regulation (GDPR) in Europe and the KVKK (Kişisel Verilerin Korunması Kanunu) in Turkey, to ensure the lawful and ethical handling of user data. [IN PROGRESS]

• 2.1.2. Personal information protection and confidentiality

  • 2.1.2.1. The platform shall implement robust measures to safeguard the personal information and contact details of individuals affected by disasters, ensuring their privacy and confidentiality are maintained at all times. This includes encryption, access controls, and secure data storage practices. [IN PROGRESS]

Feedbacks to and Reflections to our Customer Milestone 2 Demo are collected, listed and explained.

The feedback received during Milestone 2 includes a point for improvement in the Mobile Responder application. Firstly, it is suggested that the Mobile Responder should allow users to manually adjust their location rather than relying solely on the current location.

Concerns are raised about the abstract nature of resource types, as users may not be aware of specific details such as the presence of baby food. The hierarchical category feature is deemed useful, but there are difficulties in understanding the category tree, especially on mobile devices.

Suggesting the utilization of the entire page instead of multiple pages to enhance user experience. There is also a comment about the lack of clarity in the skipping functionality.

Commented on the step-by-step design, acknowledging its effectiveness but suggesting that users should be able to see what they have already selected in each step. The concern is raised that users might forget their selections as they progress through the steps, and returning back becomes cumbersome in the current design.

Asked about a use case including a local lead collection needs of victims and gathering into a bigger request which was thought in requirements already. A feature proposed in that scenario was suggested, so that calculation of total people need should be available the local lead.

Suggestions and questions about the further plans on the application are asked, especially resource - request mapping which are included in the coordinates requirements. Those requirements are already planned to be implemented until the Customer Milestone 3.

Reflecting on our work in the first milestone and also in the process of preparing the deliverables for the second milestone, we identified several key areas where our workflows could be improved to increase efficiency and reduce needless conflict and communication.

The first of these was modifying the way we wrote our weekly progress reports. Our workflow was as follows: Every week, one person is tasked with communicating with every single member of the group about the progress on last week's items, and what their plan is for this week. Then, using this information and their general knowledge of the project's status, this person creates the report. We found that having one person tasked with verifying the status of last week's items works quite well, it reduces the probability of some issues falling through the cracks and makes inaccuracies in the report less likely. However, we found that asking everyone about their weekly plans, writing this in the report, then having everyone open their own issues results in much duplication of effort. Therefore, we have migrated to a system where every team makes their plan for next week in conjunction with other teams, then each person opens their issues for the week. Following this, the reporter carries these newly opened issues into this week's tasks, and only asks people their time estimates for each task. This successfully reduced the burden on the reporter, while preserving the accuracy of the report. We also tried every person inputting their own time estimates on the report themselves. However, this was abandoned after some issues were forgotten about.

Another shortcoming from the first milestone we later partially addressed was not having formal customer meetings. Up to the first milestone, we relied on informal feedback gathered in the weekly lab hours. However, after the first milestone, we discovered that there were significant differences between our concepts and the customer's. Thus, we planned a set of customer meetings, the first of which was held before the Milestone 2 demo. We found this meeting to be extremely productive, and allowed us to sync our perspective of the app with the customer in a significant way. We expect to hold a second customer meeting following the completion of Coordinator mockups on our side.

Overall, we have reflected on several of our process errors in the course of this project, and have successfully taken steps to rectify them.

The API documentation.

1. Introduction

The ResQ - Disaster Response Platform Application API Documentation for Backend Services. In order to use the API endpoints, you first need to use /auth/signup endpoint, after registering to the application, you need to use /auth/signin endpoint to get JWT token to use in your requests. In addition, every endpoints are authorized for specific set of user roles, if you don't satisfy the requirement for the endpoint, you will receive 401 Unauthorized access error. There are five roles: Admin, Coordinator, Responder, Facilitator, and Victim

---

2. Authentication

• /auth/signup

  This endpoint is for users to signup to the application with providing relevant information. After signup, every user gains Victim role as default.

  Request body: { "name": "string", "surname": "string", "email": "string", "password": "string" }.

  No need to send X-Selected-Role, since this endpoint is permitted for all users' usage.

• /auth/signin

  This endpoint is for users to signin to the application with their email and password. After signin, the service returns available roles for the user, their information, and JWT token.

  Request body: { "email": "string", "password": "string" }

  Response: { "jwt": "string", "id": 0, "name": "string", "surname": "string", "email": "string", "roles": [ "string" ] }

After JWT token is received, the requests must be sent with headers:

• Authorization: Bearer <jwtToken>

• X-Selected-Role: One of "Admin, Coordinator, Facilitator, Responder, Victim"

---

3. User Endpoint

• /user/requestRole

  This endpoint is designed for users to request a user role. If they provide eligible information, they are granted the role.

  Request Params:

  • userId: "integer"
  • role: "string"

• /user/getUserInfo

  This endpoint is designed to get user information. Response body is below.

  Request Params:

  • userId: "integer"

  Response:
  { "email": "string", "name": "string", "surname": "string", "roles": [ "COORDINATOR" ] }

---

4. Task Endpoint

• /task/createTask

  This endpoint is designed for coordinators to create tasks.

  Request Body:

  { "assignerId": 0, "assigneeId": 0, "description": "string", "actions": [ { "verifierId": 0, "description": "string", "startLatitude": 0, "startLongitude": 0, "endLatitude": 0, "endLongitude": 0 } ], "resources": [ { "senderId": 0, "categoryTreeId": "string", "gender": "MALE", "quantity": 0, "latitude": 0, "longitude": 0 } ], "urgency": "LOW", "status": "TODO" }

• /task/acceptTask

  This endpoint is designed for responders to accept tasks.

  Request Params:

  • taskId: "integer"
  • userId: "integer"

• /task/viewTasks

  This endpoint is designed for responders and coordinators to view tasks.

  Request Params:

  • userId: "integer"

  Response: [ { "id": 0, "assignee": 0, "assigner": 0, "actions": [ { "id": 0, "taskId": 0, "verifierId": 0, "description": "string", "startLatitude": 0, "startLongitude": 0, "endLatitude": 0, "endLongitude": 0, "dueDate": "2023-11-30T21:12:06.676Z", "createdDate": "2023-11-30T21:12:06.676Z", "completed": true } ], "description": "string", "resources": [ { "id": 0, "senderId": 1, "quantity": 0, "gender": "MALE", "categoryId": "string", "latitude": 0, "longitude": 0 } ], "feedbacks": [ { "id": 0, "taskId": 0, "userId": 0, "message": "string" } ], "urgency": "LOW", "status": "TODO" } ]

---

5. Resource Endpoint

• /resource/updateResource

  This endpoint is designed for responders to update resources they created.

  Request Params:

  • resourceId: "integer"

  Request Body: { "senderId": 0, "categoryTreeId": "string", "quantity": 0, "latitude": 0, "longitude": 0, "gender": "MALE" }

• /resource/deleteResource

  This endpoint is designed for responders and coordinators to delete resources.

  Request Params:

  • resourceId: "integer"

• /resource/createResource

  This endpoint is designed for responders and coordinators to delete resources.

  Request Body: { "senderId": 0, "categoryTreeId": "string", "quantity": 0, "latitude": 0, "longitude": 0, "gender": "MALE" }

• /resource/viewResource

  This endpoint is designed for users to view resources.

  Request Params:

  • resourceId: "integer"

  Response: { "id": 0, "senderId": 0, "receiverId": 0, "categoryTreeId": "string", "gender": "MALE", "quantity": 0, "latitude": 0, "longitude": 0, "createdDate": "2023-11-30T21:57:47.651Z" }

• /resource/filterByDistance

  This endpoint is designed for users to view resources with filtering by location and distance.

  Request Params:

  • longitude: "integer"
  • langitude: "integer"
  • distance: "integer"

  Response: [ { "id": 0, "senderId": 0, "receiverId": 0, "categoryTreeId": "string", "gender": "MALE", "quantity": 0, "latitude": 0, "longitude": 0, "createdDate": "2023-11-30T22:01:56.782Z" } ]

• /resource/filterByCategory

  This endpoint is designed for users to view resources with filtering by category, location and/or userId.

  Request Params:

  • categoryTreeId: "string"
  • longitude: "integer"
  • langitude: "integer"
  • userId: "integer"

  Response: [ { "id": 0, "senderId": 0, "receiverId": 0, "categoryTreeId": "string", "gender": "MALE", "quantity": 0, "latitude": 0, "longitude": 0, "createdDate": "2023-11-30T22:08:05.546Z" } ]

---

6. Request Endpoint

• /request/updateRequest

  This endpoint is designed for facilitators to update requests they created.

  Request Params:

  • userId: "integer"
  • requestId: "integer"

  Request Body: { "description": "string", "latitude": 0, "longitude": 0, "needs": [ { "id": 0, "createdAt": "2023-11-30T22:08:23.539Z", "modifiedAt": "2023-11-30T22:08:23.539Z", "requester": "string", "categoryTreeId": "string", "description": "string", "quantity": 0, "latitude": 0, "longitude": 0, "request": "string", "status": "INVOLVED" } ], "status": "TODO", "urgency": "LOW" }

• /request/deleteRequest

  This endpoint is designed for facilitators to delete requests they created.

  Request Params:

  • userId: "integer"
  • requestId: "integer"

• /request/createRequest

  This endpoint is designed for facilitators to create requests.

  Request Params:

  • userId: "integer"

  Request Body: { "description": "string", "latitude": 0, "longitude": 0, "needIds": [ 0 ], "status": "TODO", "urgency": "LOW" }

• /request/viewRequestsByFilter

  This endpoint is designed for users to view requests by location, status, urgency and/or userId.

  Request Params:

  • longitude1: "integer"
  • latitude1: "integer"
  • longitude2: "integer"
  • latitude2: "integer"
  • status: "string"
  • urgency: "string"
  • userId: "integer"

  Response: [ { "id": 0, "requesterId": 0, "needIds": [ 0 ], "urgency": "LOW", "status": "TODO", "latitude": 0, "longitude": 0, "description": "string", "createdDate": "2023-11-30T22:33:17.510Z" } ]

• /request/viewAllRequests

  This endpoint is designed for users to view all requests.

  Response: [ { "id": 0, "requesterId": 0, "needIds": [ 0 ], "urgency": "LOW", "status": "TODO", "latitude": 0, "longitude": 0, "description": "string", "createdDate": "2023-11-30T22:35:14.742Z" } ]

• /request/filterByDistance

  This endpoint is designed for users to view all requests.

  Request Params:

  • longitude: "integer"
  • latitude: "integer"
  • distance: "integer"

  Response: [ { "id": 0, "requesterId": 0, "needIds": [ 0 ], "urgency": "LOW", "status": "TODO", "latitude": 0, "longitude": 0, "description": "string", "createdDate": "2023-11-30T22:36:19.055Z" } ]

---

7. User Profile Endpoint

• /profile/updateProfile

  This endpoint is designed for users to update their profile.

  Request Params:

  • userId: "integer"

  Request Body: { "name": "string", "surname": "string", "birth_date": "2023-11-30", "gender": "MALE", "phoneNumber": "string", "bloodType": "string", "weight": 0, "height": 0, "state": "string", "country": "string", "emailConfirmed": true, "privacyPolicyAccepted": true, "city": "string" }

• /profile/getProfileInfo

  This endpoint is designed for users to view their profile.

  Request Params:

  • userId: "integer"

  Response: { "name": "string", "surname": "string", "birth_date": "2023-11-30", "gender": "MALE", "phoneNumber": "string", "bloodType": "string", "weight": 0, "height": 0, "state": "string", "country": "string", "emailConfirmed": true, "privacyPolicyAccepted": true, "city": "string" }

---

8. Need Endpoint

• /need/updateNeed

  This endpoint is designed for victims and facilitators to update needs.

  Request Params:

  • userId: "integer"
  • needId: "integer"

  Request Body: { "description": "string", "latitude": 0, "longitude": 0, "categoryTreeId": "string", "quantity": 0 }

• /need/updateNeed

  This endpoint is designed for victims and facilitators to delete needs.

  Request Params:

  • userId: "integer"
  • needId: "integer"

• /need/createNeed

  This endpoint is designed for victims to create needs.

  Request Params:

  • userId: "integer"

  Request Body: { "description": "string", "latitude": 0, "longitude": 0, "categoryTreeId": "string", "quantity": 0 }

• /need/cancelNeed

  This endpoint is designed for victims and facilitators to cancel needs.

  Request Params:

  • needId: "integer"

  Request Body: { "description": "string", "latitude": 0, "longitude": 0, "categoryTreeId": "string", "quantity": 0 }

• /need/viewNeedsByUserId

  This endpoint is designed for victims and facilitators to view needs by userId.

  Request Params:

  • userId: "integer"

  Response: [ { "id": 0, "userId": 0, "categoryTreeId": "string", "description": "string", "quantity": 0, "latitude": 0, "longitude": 0, "requestId": 0, "status": "INVOLVED", "createdDate": "2023-11-30T22:54:14.210Z" } ]

• /need/viewNeedsByFilter

  This endpoint is designed for victims and facilitators to view needs with filtering by location, categoryTreeId, and/or userId.

  Request Params:

  • longitude1: "integer"
  • latitude1: "integer"
  • longitude2: "integer"
  • latitude2: "integer"
  • categoryTreeId: "string"
  • userId: "integer"

  Response: [ { "id": 0, "userId": 0, "categoryTreeId": "string", "description": "string", "quantity": 0, "latitude": 0, "longitude": 0, "requestId": 0, "status": "INVOLVED", "createdDate": "2023-11-30T22:55:56.196Z" } ]

• /need/viewNeed

  This endpoint is designed for victims and facilitators to view need by needId and userId.

  Request Params:

  • userId: "integer"
  • needId: "integer"

  Response: { "id": 0, "userId": 0, "categoryTreeId": "string", "description": "string", "quantity": 0, "latitude": 0, "longitude": 0, "requestId": 0, "status": "INVOLVED", "createdDate": "2023-11-30T22:58:33.226Z" }

• /need/viewAllNeeds

  This endpoint is designed for victims and facilitators to view need all needs.

  Response: [ { "id": 0, "userId": 0, "categoryTreeId": "string", "description": "string", "quantity": 0, "latitude": 0, "longitude": 0, "requestId": 0, "status": "INVOLVED", "createdDate": "2023-11-30T23:00:21.821Z" } ]

• /need/filterByDistance

  This endpoint is designed for victims and facilitators to view need by filtering distance.

  Request Params:

  • longitude: "integer"
  • latitude: "integer"
  • distance: "integer"

  Response: [ { "id": 0, "userId": 0, "categoryTreeId": "string", "description": "string", "quantity": 0, "latitude": 0, "longitude": 0, "requestId": 0, "status": "INVOLVED", "createdDate": "2023-11-30T23:00:57.950Z" } ]

---

9. Action Endpoint

• /action/createAction

  This endpoint is designed for coordinators to create actions for the tasks they created.

  Request Body: { "taskId": 0, "verifierId": 0, "description": "string", "startLatitude": 0, "startLongitude": 0, "endLatitude": 0, "endLongitude": 0, "dueDate": "2023-11-30T23:03:40.722Z", "completed": true }

• /action/viewActions

  This endpoint is designed for coordinators and responders to view actions for the tasks.

  Request Params:

  • taskId: "integer"

  Response: [ { "id": 0, "taskId": 0, "verifierId": 0, "description": "string", "startLatitude": 0, "startLongitude": 0, "endLatitude": 0, "endLongitude": 0, "dueDate": "2023-11-30T23:19:15.745Z", "createdDate": "2023-11-30T23:19:15.745Z", "completed": true } ]

---

10. Notification Endpoint

• /notification/viewNotificationById

  This endpoint is designed for users to view their notifications by id.

  Request Params:

  • notificationId: "integer"
  • userId: "integer"

  Response: { "id": 0, "createdAt": "2023-11-30T23:22:12.471Z", "modifiedAt": "2023-11-30T23:22:12.471Z", "userId": 1, "title": "string", "body": "string", "relatedEntityId": 0, "notificationType": "REQUEST", "read": true }

• /notification/viewAllNotifications

  This endpoint is designed for users to view all of their notifications by userId.

  Request Params:

  • userId: "integer"

  Response: [ { "id": 0, "createdAt": "2023-11-30T23:22:12.471Z", "modifiedAt": "2023-11-30T23:22:12.471Z", "userId": 1, "title": "string", "body": "string", "relatedEntityId": 0, "notificationType": "REQUEST", "read": true } ]

---

11. Category Tree Node Endpoint

• /categorytreenode/getSubCategoryByName

  This endpoint is designed to provide users sub categories of a parent category.

  Request Params:

  • name: "string"

  Response: [ { "id": 0, "data": "string", "parent": "string", "children": [ "string" ] } ]

• /categorytreenode/getMainCategories

  This endpoint is designed to provide users main categories of the tree.

  Response: [ { "id": 0, "data": "string", "parent": "string", "children": [ "string" ] } ]

• /categorytreenode/getCategoryTree

  This endpoint is designed to provide return the whole category tree.

The link to the API.

Swagger API Documentation

In our frontend development cycle, comprehensive requirement validation was a priority to ensure our deliverables aligned with project specifications. This involved a systematic review of frontend functionalities, encompassing user interface elements and interaction flows. Our primary focus was on verifying feature completeness and adherence to predefined user experience guidelines, ensuring that every aspect of the frontend met design and functional specifications. This stage also included manual testing by our developers to validate the functionalities in real-world scenarios.

Concurrently, we engaged in detailed technical integration testing with backend systems, verifying the compatibility of frontend calls with backend APIs, and ensuring data consistency. Correct implementation of business logic in the integration layer was confirmed through rigorous testing. Our collaboration with the mobile development team was key to align our development strategies. This included focusing on API contract consistency and uniform cross-platform user experience, instrumental in maintaining a cohesive development approach across web and mobile platforms.

We implemented a customized testing strategy for user-centric features. This involved scenario-based validation to ensure the application accurately mirrored real-world user scenarios, particularly focusing on functionalities like victim assistance, resource allocation, and request logging. This approach was crucial for ensuring the application not only functioned as intended but also catered effectively to user needs.

We regularly showcased our application to stakeholders and potential users, gathering feedback and integrating it into development. This ongoing process was not a formal UAT but served a similar purpose, ensuring each development phase met user requirements and expectations. Through this, we ensured that our features remained user-centric and aligned with project goals.

Throughout the development process, aligning our efforts with the customer's direction was crucial. We addressed ease of use in critical functionalities, ensuring interfaces were user-friendly and capable of capturing detailed information. Our commitment to enhancing the user interface was evident in how we incorporated customer feedback into our design and development processes.

Despite our adherence to customer requirements, the final presentation indicated areas for improvement. We are planning further meetings to understand and address these concerns. This adaptive approach is a natural part of our development lifecycle, ensuring that our product continuously evolves with customer feedback and current project status.

After careful consideration, we have decided not to implement unit testing for our frontend development. We found that our combination of integration tests and thorough manual testing processes is sufficient and efficient for our current needs. This decision aligns with our goal to streamline our testing strategy while still maintaining high standards of quality and functionality in our application.

Functional Testing:

• Feature Verification: Manually test each feature for correct operation.
• Form Input Validation: Check all forms for validation rules, ensuring correct prompts for invalid inputs.
• Navigation and Workflow: Ensure the app's navigation is intuitive and all workflows function as expected.

User Interface (UI) Testing:

• Layout and Design: Verify that the UI elements are aligned, appropriately sized, and visually consistent across different screens.
• Responsiveness: Test on various screen sizes to ensure UI elements adjust properly.
• Graphics and Images: Check for clarity and proper loading of graphics and images.

User Experience (UX) Testing:

• Ease of Use: Evaluate the ease of performing common tasks.
• Error Messages: Ensure error messages are informative and guide the user towards resolving issues.
• User Journey: Follow typical user paths to assess overall experience and identify any friction points.

Performance Testing:

• Speed and Responsiveness: Check the application's response time and ensure it performs well under different network conditions.
• Resource Usage: Monitor the app's consumption of system resources like memory and battery.

Compatibility Testing:

• Different Devices: Test the app on various devices with different specifications to ensure compatibility.
• Operating System Versions: Verify the app's functionality across different OS versions.

Security Testing:

• Data Protection: Validate that sensitive data is appropriately protected and encrypted where necessary.
• Authentication and Authorization: Test login mechanisms and access controls.

Scenario-Based Testing:

• Real-World Scenarios: Simulate real-world use cases specific to your app's purpose, like resource allocation or request logging.
• Edge Cases: Test unusual or extreme scenarios to see how the app handles unexpected or rare situations.

Accessibility Testing:

• Screen Reader Compatibility: Ensure the app is navigable and understandable via screen readers.
• Color Contrast and Font Size: Check for adequate color contrast and adjustable font sizes for visually impaired users.

Regression Testing:

• After Updates: Re-test functionalities after each update to ensure new changes haven't affected existing features.

Backend team uses Unit tests to simulate edge cases and normal cases that can be encountered. Unit tests had already been implemented for the services that were already in place. We aim to expand the scenarios' cases. Additionally, if a test needs to be fixed, we should investigate the situation thoroughly to see if there are any other cases that might result in problems. A crucial part of our testing methodology is putting the unit tests into practice while we implement the services.

The feature of the ResQ app that will be implemented using annotations is designating points on the map as warnings, or useful places. This is reflected in requirement 1.1.5 as well as 1.2.7.1. As of Milestone 2, displaying points and information about them is currently implemented in the frontend, and this UI element was demonstrated in the demo using mock data. In the mobile application, work is in progress for implementing the same feature. The integration of these with an annotation server, as well as the UI for adding points, was planned for Milestone 3. To comply with the W3C specifications, the annotations will be stored in a separate database and server. A backend that responds to HTTP GET, POST and DELETE requests to serve, add/edit and delete annotations will be implemented and dockerised. The mobile app and the frontend will consume this API to retrieve annotations. The annotations will contain a link to the JSON content of the tag retrieved from the backend, as well as a Fragment Selector in the target field signifying the map coordinates of the annotation.

Kübra Aksu - Individual Contribution Report 2

Muhammet Ali Topcu - Individual Contribution Report 2

Harun Reşid Ergen - Individual Contribution Report 2

Alperen Dağı - Individual Contribution Report 2

Furkan Bülbül - Individual Contribution Report 2

Huseyin Turker Erdem - Individual Contribution Report 2

Elif Tokluoğlu - Individual Contribution Report 2

Ilgaz Er - Individual Contribution Report 2

Volkan Öztürk - Individual Contribution Report 2

Çağrı Gülbeycan - Individual Contribution Report 2