Skip to content

Milestone 1 report

Sahin-Albayram edited this page May 24, 2023 · 27 revisions

CMPE352 Group 2 - Disaster Response Platform

We are students who are taking the CMPE352 FUNDAMENTALS OF SOFTWARE ENGINEERING. We are Group 2 . Our aim is to create a disaster response platform that will help to communicate between different sources to respond disasters. While most applications aim to point the area needing to help, by using our app; users will also see actions that are being taken, so that resource allocation will be efficiently done.

Contributors

Aras
Güngöre
Begüm
Arslan
Cahid Enes
Keleş
Egecan
Serbester
Ersel
Çanakçılı
Halil İbrahim
Gürbüz
Hasan
Bingölbali
Mehmet Emin
İpekdal
Mehmet
Kuzulugil
Merve Gürbüz
Ömer Şahin Albayram
Ramazan Burak Sarıtaş

Table of Contents

1. Executive Summary

Our project team has been diligently working on a complex task since the initial meeting. We have utilized various communication channels, including:

  • Weekly face-to-face meetings
  • Urgent online meetings
  • Our Discord channel
  • WhatsApp for quick communication
  • GitHub discussions
  • Issue comments

The contentious points of the project have required constant discussion and goal updating.

Upon receiving the task guidelines, we engaged in a series of questions with the project owner to gain a clear understanding of the core idea. However, as we progressed with the development, we found it necessary to continue discussions to finalize the finer details.

To ensure the project's success, we met with experts who have firsthand experience in managing helping organizations in disastrous environments. These meetings proved to be invaluable in directing our goals.

Our team drafted requirements, mockups, scenarios, use case diagrams, class diagrams, and sequence diagrams to better communicate with the project owner. We used milestones to track our progress.

Throughout the project's development, we continuously checked, corrected, and fine-tuned our work to achieve perfection. However, no major changes were made to the project's plans.

Currently, we have finalized our requirements, mockups, scenarios, use case diagrams, class diagrams, and sequence diagrams, with the possibility of fine-tuning them further in the future.

2. List and Status of Deliverables

Deliverable Name Delivery Status Due Date Delivery Date
1. Project Repository Delivered 04.03.2023 04.03.2023
2. Requirements Delivered 18.03.2023 21.03.2023
3. Software design documents in UML Delivered 10.04.2023 10.04.2023
4. Project plan, RAM Delivered 10.04.2023 10.04.2023
5. Milestone Report Delivered 10.04.2023 10.04.2023

3. Evaluation of Deliverable Status and Impact on Project Plan

3.1. Project Repository

Github repository provides us collaborative and asynchronous work area so it is a good tool to use in group work. We have used the repository created by our assistants. Our repository is named bounswe2023group2 , and we are group of 12 people who are taking CMPE352 class. We have used many features of GitHub.

  • 3.1.1 README.md page welcomes the users at the first sight. We provide a short description for everyone, interested to our repository, and we list the team members in there, First we just wrote our names, but we decided to put our photos since it is our first meetings. we provide wiki page links, if someone wants to learn further about the project, they can click the wiki page link provided in there.
  • 3.1.2 Wiki Pages: It is heart of our project. You can see the main content in the first wiki page, we have used sidebar in order to navigating between pages without any difficulties. When we try to write the same page at the same times, GitHub only keeps the one of them works. It took time to find a way to work together in the same page. Requirements, descriptions, our own profiles, to sum all the information apart from code is resides there.
  • 3.1.3 Wiki/Issue Templates: We wanted to create a consistent way for our work. We have created meeting note, personal page, issue templates to avoid any wrong usages.
  • 3.1.4 Labels and milestones: It is good to understand concept of the issue without opening it. So we focused on labeling our issues in a meaningful way (effort, urgency, status, type...). Since the project contains many subtasks in it, we used milestones for creating due dates, and reviewing our situation in the tasks.
  • 3.1.5 Discussion: We needed to decide many feature of our project, at first we tried to discuss them on discord but we always forgot our ideas while implementing. So we decided to use discussion for conflicts and further development. It would be great if we would decided to use discussions before.
  • 3.1.6: Issue Tracking: We tend to work on issues as a pair, one is reviewer and the other is assignee. But team members were not available enough to track daily the issues. So we had some delays on reviewing and closing issues.

3.2. Requirements

  • 3.2.1 We initially created the questions to the customer, after this meeting we had a long meeting notes in notion application. After requirements, we split the tasks between team members. we had some interviews at the same time with the people who had experiences in disaster , as victims or as volunteers. We completed our first draft, but it has ceration conflicts since we wrote the parts seperately. While merging them, we resolve the conflicts and found out some missing features. So we revise the requirements couple of times. We have reliazed lots of different aspects of our project that we need to specify in the requirements while doing use cases. To conclude, we are eager to define the project clearly and comprehensively to obtain a good result.

3.3. Software design documents in UML

  • 3.3.1 Deciding tool: we first used diagrams.net but it is not a useful tool for collaborative work. We seaarched for other tools and found lucidchart. Lucidchart has simpler usage and faster designing tools. Moreover, team members can be able to work simultaneously in the application.
  • 3.3.2 Use Case Diagram: We first designed use case diagrams, since we cannot work on other diagrams without completing that one. Use case diagram reveal a big problem in our app structure, first we resolved the problem and revise the requirements and continue on diagram. While writing use cases, we decided to change the view for better understanding. We used arrow colors and colorful backgrounds to better visualizing the user scope. We decided to list the use cases and then assign them between ourselves. But since use cases are not seperate completely, we work on the same document.
  • 3.3.3 Class Diagram: We separate the class diagram related issues according to distribution in use case diagrams. Each one of us is more knowledgeable than others so we want to keep it that way. Class diagram helped us to define entities types and enumerations.
  • 3.3.4 Sequence Diagram: We decided that everyone should also do the sequence of the use cases they wrote. We define some services since we will use the functions created there. While everyone worked on sequence diagrams seperately, we designed a templatestructure. for sequences so they have a consistent

3.4. Project plan, RAM

  • 3.4.1 The group developed the sections for Project Plan and RAM in parallel with this report. Initially, we listed all the tasks that were completed by the group. Subsequently, we created an Excel sheet for RAM and each member filled in their respective columns with their past responsibilities. For the Project Plan, we elaborated on the RAM by adding more details and extending the timeframe. We used ProjectLibre, an application where we entered weekly tasks, their duration, and the contributors involved. This allowed us to create a Gantt Chart. The Project Plan encompasses all the completed tasks so far, as well as possible future tasks. We also have the Project Plan in PDF format.

3.5. Milestone Report

  • 3.5.1 We barely finished the report. We wrote our experiences during the milestone. Some parts are duplicated, and we need to design the headers again since it is a bit confusing.

4. Evaluation of Tools and Processes

4.1. Tools for Collaboration

Github

Collaboration: Github was the platform for collaboration, organizing the group work and documentation. We have benefited the standard wiki features as well as the code repository.

Issue tracking features contributed to the team work and increased our efficiency. Using Discussions feature we made it possible to make decisions in a much more efficient and creative way.

Source control: We made use of code repository to share and deploy design elements by third party tools. This also made possible to track the work and cooperate without loss of data, information or design.

Use of a centralized repository also made possible to use hyperlinks for related documents within the group's work. Using markdown as an authoring standard, made copying text between discussions, issue evaluations, wiki pages even comments possible.

Another feature of Github, which was useful for organizing team work is the use of templates. Templates for different areas of documentation (meeting notes, issue, team member pages) increased the standards and group communication.

Last but not least, putting all the work on an online tool (which provides flexible and visual elements also) is a must for modern day projects.

Discord

Issue tracking and Discussion features are not as flexible and quick as any realtime communication tool. But any realtime communication tool has the draw back of introducing information loss and distraction. Without neglecting this, we made use of discord and whatsapp for fast communication on details. Discord was also the tool for quick communication with our instructors.

Whatsapp

Mainly used for meeting confirmations and other daily human interactions.

Zoom for video conferences and online meetings

Being a tool widely used for online meetings, zoom provided us the facility to recruit team members to meetings which were not possible for them to join face to face. Zoom was also useful to organize short quick discussions which are crucial for efficient collaboratin.

Advantages and Disadvantages of Zoom

  • Advantages
    • Having a well developed engine, Zoom well optimizes the simultaneous talks by many members at the same time.
    • Sharing user screen, documents, links (via chat feature) is useful
  • Disadvantages
    • Limited meeting times

4.2. Design and documentation tools

Lucid charts

After a short trial period on diagrams.net we decided to use lucid for our design work:

  • Mockups (diagrams.net and Lucid)
  • UML Designs including:
    • Use cases
    • Use case diagram
    • Sequence diagrams
    • Class diagrams

Advantages and Disadvantages of Lucid

  • Advantages
    • Real time collaboration provides real time collaboration.
    • Design templates provided are useful
    • Training supports with videos are useful
  • Disadvantages
    • Direct integration with github repositories are missing
    • Limitations exist for free education package.

ProjectLibre

We used ProjectLibre for project plan.

  • Advantages
    • Visualization: Gantt charts provide a visual representation of project tasks, timelines, assignees.
    • Time management: It can be used to manage time.
  • Disadvantages
    • Complexity: Gantt charts can be complex to create and maintain, especially for large and complex projects. This can be time-consuming and require significant effort.
    • Limited flexibility: Gantt charts are best suited for projects with well-defined tasks and timelines. They may not be suitable for projects that are more flexible and require frequent changes to the plan.
    • Windows dependency: The software was not usable by some of us.

5. Individual Contribution Reports

6. Requirements

Software Requirement Specification

Software Requirements Specification for Disaster Response and Recovery

March, 27 2023

Prepared by:
Group 2

Members

Prepared for
BOUN - CMPE 352 - Spring 2023

Table of Contents

Revision History

Name Date Reason for Change Version
Requirements March, 23 2023 Document revised after work 1.0
Requirements April, 10 2023 Document revised before milestone 1 report 2.0

Glossary

  • Admin: User who has the highest level of authority and who can control the application by banning users, editing posts, etc.
  • Activity: Various types of information circulating on the application (event, action, resource, need).
  • Action: Disaster-related dynamic happenings created by users (dispatch of a relief team, search for survivors).
  • Authenticated user: Anyone who is using the application with signing up and entering personal information (name, surname, phone number, etc.).
  • Confirmer: A user who validates an activity (event, action).
  • Creator: A user that creates an activity (event, action, resource, need).
  • Credible user: Users who are trusted by admin. This type of user is able to create prioritized activities.
  • Demander: Users who need resources due to suffering damage from disasters.
  • Downvote: Registered users can downvote the action or event to affect its reliability scale. (in case if users don't agree created an action or event)
  • Event: Disaster-related static happenings created by users (the road is blocked, buildings are destroyed, power cut).
  • Emergency: Situations that require minimum attributes (description (included name&surname), location and type) in case there isn't enough time. It can be created by any type of user including guest users. (i.e enkaz altindayim)
  • Guest user: Anyone who is using the application without registration. A guest user can view general activities about disasters.
  • Interaction rate: An activity sorting metric which measures how many times the activity has been viewed/shared/reacted to by other users.
  • Need/Demand: Needs that are needed by demanders.
  • Profile: A page containing static data related to registered users (name, surname, phone number, etc.).
  • Provider: Users who can provide material resources or him/herself as human resources to demanders.
  • Reliability scale: An activity sorting metric which measures the trustworthiness of the activity based on feedback from other users. Calculated by #approvals/(#approvals+#rejections) ("#" is used for number of)
  • Report: Reports are for informing admin. After a registered user complains about the action or user reports go to the admin dashboard. The type of user that reports is also stored in reports to help the admin to decide whether it should be deleted or banned.
  • 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.).
  • Role-Based user: Special users who have proficiency might help (headman, pharmacist, etc.).
  • Topic: Topics consist of activity, type and event. Any of the three can be "any". Users can subscribe to the topics for notifications
  • Upvote: Registered users can upvote the action or event to affect its reliability scale. (in case if user wants to increase its reliability scare so the visibility)
  • User: Anyone who is using the application. Can have static types (guest, authenticated, rol-based and credible).

Introduction

Purpose

Every year, tens of thousands of people suffer from disasters. In particular, the 2023 Turkey–Syria earthquake is one of the biggest disasters to impact the region in recent times. The earthquake affected over 10 cities and caused tens of thousands of deaths and left many more injured and exposed to cold, hunger, and thirst. Some regions did not receive the help they desperately need due to significantly damaged logistics infrastructure and poor organization of aid distribution. To address this issue, we are developing a disaster response system that aims to facilitate the organization of relief teams and aid distribution.

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.

Product scope

The proposed disaster response system is a software application that enables effective coordination and distribution of relief efforts during a disaster. The system aims to provide a reliable and efficient platform for coordinating aid distribution, reducing redundancy, and ensuring that resources are used effectively to support those affected by the disaster.

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.

References

  1. https://en.wikipedia.org/wiki/2023_Turkey%E2%80%93Syria_earthquake
  2. https://deprem.io/

1. Functional Requirements

1.1 User Requirements

  • 1.1.1 Account Features

    • 1.1.1.1 Registration
      • 1.1.1.1.1 Users shall be able to create an account using a valid and unique email address or phone number, a unique username, their name, their surname and a password.
    • 1.1.1.2. Log In
      • 1.1.1.2.1. Users shall be able to log into their account using their email, username or phone number; and password combination.
      • 1.1.1.2.2. Users shall be able to reset their password via email verification or sms verification.
    • 1.1.1.3 Log Out
      • 1.1.1.3.1 Users shall be able to log out of their accounts.
  • 1.1.2 Profile

    • 1.1.2.1 Authenticated User Profile:

      • 1.1.2.1.1 Authenticated users shall be able to edit their profile info.
      • 1.1.2.1.2 If users have not added their phone number or email address to their profile, they shall be able to do so.
      • 1.1.2.1.3 Authenticated users shall be able to choose a role after adding a valid phone number.
      • 1.1.2.1.4 Authenticated users shall be able to select who can see their contact information.
    • 1.1.2.2 Role-Based User Profile:

      • 1.1.2.2.1 Role-Based Users shall be able to add information about their proficiency and how they can help.
  • 1.1.3 User Actions

    • 1.1.3.1 Guest User Actions:
      • 1.1.3.1.1 Guest users shall be able to create only one emergency.
      • 1.1.3.1.3 Guest users shall be able to view emergencies and activities about disasters, including event types, resources available, and actions taken.
      • 1.1.3.1.4 Guest users shall be able to filter and sort activities about emergencies, events, resources, actions, and needs based on location, date, type etc.
    • 1.1.3.2 Authenticated User Actions:
      • 1.1.3.2.1 Authenticated users shall have all functionalities that guest users have.
      • 1.1.3.2.2 Authenticated users shall create activities.
      • 1.1.3.2.3 Authenticated users shall be able to update and delete their current active activities.
      • 1.1.3.2.4 Authenticated users shall verify their accounts by verifying their phone numbers or emails which are not entered.
      • 1.1.3.2.5 Authenticated users shall be able to delete their accounts.
      • 1.1.3.2.6 Authenticated users shall be able to edit their profiles.
      • 1.1.3.2.7 Authenticated users shall be able to confirm or reject other users' activities.
      • 1.1.3.2.8 Authenticated users shall be able to report malicious users or activities to the admins.
      • 1.1.3.2.9 Authenticated users should be able to receive notifications about certain topics based on location, date, type etc.
      • 1.1.3.2.10 Authenticated users shall be able to search activities and emergencies.
      • 1.1.3.2.11 Authenticated users shall be able to search profiles.
      • 1.1.3.2.12 Users should be able to subscribe to a topic based on their filter and search
      • 1.1.3.2.13 Authenticated users should be able to add and delete topics for notifications.
      • 1.1.3.2.14 Authenticated users should be able to view details or dismiss when they receive a notification
    • 1.1.3.3 Role-Based User Actions:
      • 1.1.3.3.1 Role-Based users shall have all functionalities that authenticated users have.
      • 1.1.3.3.2 Role-Based users shall be able to search for activities that are related to their proficiency.
      • 1.1.3.3.3 Role-Based users shall be able to contact people who state their needs are related to Role-Based user proficiency.
    • 1.1.3.4 Credible User Actions:
      • 1.1.3.4.1 Credible users shall have all functionalities that role-based users have.
      • 1.1.3.4.2 Credible user shall be able to create a special activity which is prioritized on lists and maps.
  • 1.1.4. Admin

    • 1.1.4.1 Admin users shall be able to create actions, such as relieving needs, sending rescue teams, etc...
    • 1.1.4.2 Admin users shall be able to search users and see the contact information of other users.
    • 1.1.4.3 Admin users shall be able to view the misinformation reports.
    • 1.1.4.4 Admin users shall be able to accept or reject a misinformation report. When the misinformation report is accepted, the event will be removed.
    • 1.1.4.5 Admin users shall be able to remove activities from the platform.
    • 1.1.4.6 Admin users shall be able to see authenticated and verified users' activities.
    • 1.1.4.7 Admin users shall be able to cancel verified users' verification or authenticated user's authentication. Once admin users cancel verification/authentication, they shall not be able to be verified or authenticated again.
    • 1.1.4.8 Admin users shall be able to see and recover cancelled verification or authentication.
    • 1.1.4.9 Admin users shall be able to select or approve users as credible users.
    • 1.1.4.10 Admin users shall be able to cancel credible users' credibility.
    • 1.1.4.11 Admin users shall be able to pin some activities at the top to increase their visibility.

1.2 System Requirements

  • 1.2.1 Profile Page

    • 1.2.1.1. A user profile shall have these attributes:

      • Name and surname (required)
      • Email, Phone (at least one of them is required)
      • Date of birth (optional)
      • Nationality (optional)
      • ID number (optional)
      • Education (optional)
      • Condition of healt (Free format information about chronic diseases, allergies, regular medications etc.) (optional)
      • Blood type (optional)
      • Address (optional)
      • Social media links (optional)
      • Expertise (optional)
        • Definition
        • Experience level
        • Documented/certified by
        • Uses
          • Device, vehicle, instrument, etc.
          • Certificates (e.g. driver's license info)
      • Languages are spoken (optional)
        • Language
        • Proficiency
      • Professions (optional)
      • Other skills (optional)
    • 1.2.1.2. The system should show related actions, needs, resources and events to the authenticated user that has related proficiency. (i.e A doctor should see the event that medications arrive in the area.)

  • 1.2.2 Feedback System

    • 1.2.2.1: The system shall allow users to report malicious users and activities.
    • 1.2.2.2: The system shall allow users to check for a number of other users' confirmations or rejections about users, activities.
    • 1.2.2.3: The system shall carry on reports to the administration system.
    • 1.2.2.4: The system shall not accept the restricted accounts to register again.
  • 1.2.3 Activities

    • 1.2.3.1 Resources

      • 1.2.3.1.1 Resource Entry

        • 1.2.3.1.1.1. A resource shall have these attributes:
          • Type, it can be predefined or other typed. (The platform shall offer some predefined types for a user to select, but the platform shall also let the user enter the type manually in cases of unexpected types.) (required)
          • Subtype, can be predefined or other typed.
          • Location
          • Quantity
          • username
          • creation time
          • last update time
          • status: allocated, used, cancelled
          • number of approvals and rejections
          • reliability scale
      • 1.2.3.1.1.2. A resource should have attributes:

        • different resources should have additional attributes if needed
        • available at certain times
        • extra information
        • related needs (related needs are for predefined needs and resources) (optional)
    • 1.2.3.1.2. Resource Structure

      • 1.2.3.1.2.1. Resources should be organized in a structured manner to allow for easy access and management.
      • 1.2.3.1.2.2. The following predefined resources shall be included: food, clothing, accommodation, and human resources.
        • 1.2.3.1.2.1. Subtypes of food shall include:
          • Non-perishable items such as pasta, rice, canned goods, and other relevant items.
          • Baby food and similar items for infants and young children.
          • Dietary-specific items such as gluten-free, vegetarian, and other relevant items for individuals with specific dietary needs.
        • 1.2.3.1.2.2. Subtypes of human resources shall include:
          • Medical professionals such as doctors, nurses and pharmacists.
          • Emergency responders such as firefighters and police officers.
          • Support staff such as drivers, translators and other relevant roles necessary for disaster response.
        • 1.2.3.1.2.3. Subtypes of clothes shall include:
          • Seasonal clothing which is appropriate for the weather conditions: coats, hats, sweaters, gloves and shoes.
          • Underwear clothing which is necessary for personal hygiene.
    • 1.2.3.2 Events

      • 1.2.3.2.1 Events shall have these attributes:
        • 1.2.3.2.1.1 Type (it can be predefined or other typed)
        • 1.2.3.2.1.2 Creation time
        • 1.2.3.2.1.3 Creator username
        • 1.2.3.2.1.4 Location
        • 1.2.3.2.1.5 Interaction rate
        • 1.2.3.2.1.6 Related needs (Ex. enkaz altinda canli var, related needs: vinc, kurtarma ekibi vs)
        • 1.2.3.2.1.7 Confirmer username
        • 1.2.3.2.1.8 Last confirmation time
        • 1.2.3.2.1.9 Approval and Rejection number
        • 1.2.3.2.1.10 Reliability scale
      • 1.2.3.2.2 The following predefined event types shall be included:
        • Road Blocked Event (Debris)
        • With Live Human Collapsed Event (Debris)
        • Power Cut (Infrastructure)
        • On-Fire Event (Disaster)
        • Building Tent City Event (help-arrived)
    • 1.2.3.3 Actions

      • 1.2.3.3.1 Actions shall have these attributes:

        • 1.2.3.3.1.1 Type (it can be predefined or other typed)
        • 1.2.3.3.1.2 Creation time
        • 1.2.3.3.1.3 Creator username
        • 1.2.3.3.1.4 Interaction rate
        • 1.2.3.3.1.5 Related resources, needs and events (Using these resources, handling these needs, related to these events etc)
        • 1.2.3.3.1.6 Confirmer username
        • 1.2.3.3.1.7 Last confirmation time
        • 1.2.3.3.1.8 Approval and Rejection number
        • 1.2.3.3.1.9 Reliability scale
        • 1.2.3.3.1.10 Current status
      • 1.2.3.3.2 Actions should be created with the following attributes:

        • 1.2.3.3.2.1 Start location
        • 1.2.3.3.2.2 End location
    • 1.2.3.4 Needs

      • 1.2.3.4.1 Needs shall have these attributes:

        • 1.2.3.4.1.1 Type: can be food, clothes, shelter, medical assistance, heat; should be flexible
        • 1.2.3.4.1.2 Subtype according to type
        • 1.2.3.4.1.3 Creation time
        • 1.2.3.4.1.4 Creator/Demander username
        • 1.2.3.4.1.5 Location
        • 1.2.3.4.1.6 Quantity
        • 1.2.3.4.1.7 Urgency
        • 1.2.3.4.1.8 Approval and Rejection number
        • 1.2.3.4.1.9 Reliability scale
        • 1.2.3.4.1.10 Current status
      • 1.2.3.4.2 Needs should be flexible enough to accommodate changing needs and priorities over time, as the disaster situation evolves.

      • 1.2.3.4.3 Needs should allow users to assign themselves for providing the resource of it.(?)

      • 1.2.3.4.4 Status of needs should be in a timely update and demanders shall receive status notifications for each update.

  • 1.2.4 Filter, sort

    • 1.2.4.1: The system shall sort activities based on location, reliability scale, date, emergency level etc.
    • 1.2.4.2: The system shall sort emergencies based on location, reliability scale, date, emergency level etc.
    • 1.2.4.3: The system shall sort users based on their roles and locations.
  • 1.2.5 Map visualization

    • 1.2.5.1: Maps shall contain some annotation on them. Annotations shall have different colours based on the emergency level.
    • 1.2.5.2: The map shall be zoomed in and out and interactable. The annotations in the map should scale up and down accordingly.
    • 1.2.5.3: The user’s location shall appear on the map so that users are able to understand what’s happening around them
    • 1.2.5.4: The map shall show the locations that are filtered.
  • 1.2.6 Annotation

    • 1.2.6.1 The system shall use the W3C Geolocation API standard for implementing location-related information.
    • 1.2.6.2 The system shall provide all kinds of search functionality (e.g., search with filters, sort by date) for models.
    • 1.2.6.3 Users should retrieve results that are semantically similar to their queries.
    • 1.2.6.4 Users should be able to annotate different models, and annotations should comply with W3C Web Annotation Data Model.
  • 1.2.7 Notifications

    • 1.2.7.1: The system shall create in-app and push notifications.
    • 1.2.7.2: The system should create notifications, if users click the “want to be notified” button on the activity.
    • 1.2.7.3: The system should create notifications if users' profession might be implying that they can be a resource to a certain need. *
      • 1.2.7.3.1: The system should be able to add (resource | translator | any topic) to notification settings as default when the user has a role.
    • 1.2.7.4: The system should create notifications if an event takes place near users' addresses when they provide their addresses. 1.2.7.4.1: The system should be able to add event | any | (user's city) topic to notification settings as default.
  • 1.2.8 Administrations

    • 1.2.8.1: The system shall collect users' reports about other users in the admin dashboard.
    • 1.2.8.2: The system shall collect users' reports about activities and events in the admin dashboard.
    • 1.2.8.3: The system shall sort the reports according to the number of reports.
    • 1.2.8.4: The system shall hold a list of restricted users and their phone numbers.
    • 1.2.8.5: The system shall track the restricted users by their phone number in order to prevent new signs up.
    • 1.2.8.6: The system shall hold the admins' logs.
  • 1.2.9 Account Features

    • 1.2.9.1: The system shall support remember me feature.
    • 1.2.9.2: The system shall support keep me logged in feature.

2. Non-Functional Requirements

2.1 Availability

  • 2.1.1. The application shall be available as a native website via modern web browsers. (Chrome, Edge, Firefox, Opera, Safari)
  • 2.1.2. The application shall be available as a native mobile application on Android platforms.
  • 2.1.3. Language
    • 2.1.3.1. The application shall support the English and Turkish characters.
    • 2.1.3.2. The application should be available in multiple languages to ensure that it can be used by people from diverse linguistic backgrounds
  • 2.1.4. The application should support UTF-8 character encoding.
  • 2.1.5 High availability
    • 2.1.5.1 The application shall be available 7/24 to ensure that it can be accessed by emergency responders, government agencies, and affected communities at any time.
  • 2.1.6. Scalability
    • 2.1.6.1 The application shall be designed to handle a large volume of traffic and users during peak times, such as during a disaster.
  • 2.1.7. The application shall be easy to use, with a simple and intuitive interface that does not require extensive training or technical knowledge.

2.2 Privacy

  • 2.2.1. The system shall follow the regulations and guidelines defined by GDPR and KVKK.
  • 2.2.2. Users shall read and accept the Privacy Policy and User Agreement based on GDPR and KVKK before registration.
  • 2.2.3. Users shall be notified if any change happens in the policy.

2.3 Security

  • 2.3.1. Passwords should be at least 8 characters long and contain at least one uppercase letter, one lowercase letter and one number.
  • 2.3.2. API endpoints should be protected by access tokens in order to prevent users to access permissions that are not in the scope of their roles.
  • 2.3.3. Password should be encrypted with SHA-256 algorithms for account security.
  • 2.3.4. The system shall use HTTPS protocol to prevent network-related attacks.
  • 2.3.5. The system shall use encryption to protect all sensitive information stored or transmitted over insecure channels.

2.4 Performance and Reliability

  • 2.4.1. Response time: The system should respond to user requests within 5 seconds.
  • 2.4.2. Throughput: The system should be able to handle a minimum of 10000 concurrent users.
  • 2.4.3. User Accounts: The platform shall support at least 100000 user accounts.
  • 2.4.4. Fault Tolerance: The system should be designed to recover quickly from any failure, and data should not be lost during failures.
  • 2.4.5. Capacity: The system should be designed to handle a large volume of data and user requests without any slowdowns.
  • 2.4.6. Data integrity: The system should ensure that all data stored is accurate, complete, and consistent.

2.5 Backup and Recovery (Consistency)

  • 2.5.1 The system shall have a backup mechanism to ensure that all data is regularly backed up.
    • 2.5.1.1 The backup process should be automatic and take place at regular intervals.
    • 2.5.1.2 The system should maintain multiple copies of backups in different locations to ensure redundancy.
  • 2.5.2 The system shall have a recovery mechanism to restore data in case of system failure or data corruption.
    • 2.5.2.1 The recovery process should be automatic and take place as soon as possible after the detection of failure.
  • 2.5.3 The system should ensure data consistency during backup and recovery processes to avoid data loss or corruption.
  • 2.5.4 The system should allow the users to create needs, resources, actions, and events even when the app is not connected to the internet.
  • 2.5.5 The system should integrate the local actions of users with the app's data once the user is able to connect to the internet.
Scenerios

Scenerios

Scenerio 1

The User, Persona

michael-mims-fWWiaDox0BU-unsplash

Ayşe is a 33 years old truck driver. After the earthquake happened, she volunteered as a driver and wants to get notifications whenever a broken road event happens.

User Goals

  • Aims to subscribe to a notification topic.

Preconditions

  • Ayşe is already a role-based user in the system.
  • She has the mobile application.

Acceptance Criteria

  • 1.1.3.2.10 Authenticated users should be able to receive notifications about certain topics based on location.
  • 1.1.3.2.12 Authenticated users should be able to add and delete topics for notifications.
  • 1.1.3.2.13 Authenticated users should be able to view details or dismiss when they receive a notification.

Mockup

Web Mockup

Website wireframe - Page 1-3

Scenario 2 Use Map

The User, Persona

User photo Persona
image Egecan is a 23 years old student from Gaziantep. There wasn't any water supply in the area after the earthquake. He opened the app and used map to find a water resource.

User Goals

  • Aims to find a resource on map.

Preconditions

  • Egecan is already a authenticated-user in the system.
  • He has the mobile application.

Acceptance Criteria

  • 1.1.3.1.3 Guest users (Authenticated user also can do) shall be able to view emergencies and activities about disasters, including event types, resources available, and actions taken.
  • 1.1.3.1.4 Authenticated users shall be able to filter and sort activities about emergencies, events, resources, actions, and needs based on location, date, type etc.
  • 1.2.5.2: The map shall be zoomed in and out and interactable. The annotations in the map should scale up and down accordingly.
  • 1.2.5.3: The user’s location shall appear on the map so that users are able to understand what’s happening around them
  • 1.1.3.2.13 Authenticated users should be able to view details or dismiss when they receive a notification.

Mockup

Mobile Mockup

Scenario 3

The User, Persona

Profile Photo

Kadir is volunteering at Besni Food Collection Center after the earthquake. He is managing the inputs and outputs of the collection center.

User Goals

  • Find some people who are in need of food.
  • Create an action related to sending these people food.
  • Add related resources and needs in this action.
  • Visualize and track the action.

Preconditions

  • Kadir is already an authenticated user in the system.

Acceptance Criteria

  • 1.1.3.2.2 Authenticated users shall create activities.
  • 1.1.3.2.10 Authenticated users shall be able to search activities and emergencies.
  • 1.2.5.4: The map shall show the locations that are filtered.

Web Mockup

image

Scenerio 4

The User, Persona

User photo Persona
Ekran Resmi 2023-04-10 23 07 04 Emin is a 25-year-old remote software developer living in Kahramanmaraş. Mehmet was caught in the earthquake at his home and stuck in the triangle of life. He immediately opened the application as a guest user and created an emergency.

User Goals

  • Aims to create an emergency.

Preconditions

  • Emin is a guest user in the system.
  • He has the mobile application.

Acceptance Criteria

  • 1.1.3.1.1 Guest users shall be able to create only one emergency.

Mockup

Mobile Mockup

MainOperationsMockup-Create emergency drawio-2

Other Mockups

Other Mockups

-Account Profile \

Account profile in users's own perspective:

Account profile in authorized other users's perspective:

Account in general:
Website wireframe

  • Main Page

  • Maps

  • User Actions

  • Admin

  • Resource

  • Event

  • Delete

  • Filter & Sort

7. Software design documents in UML

Use Case Diagrams

Use case Diagrams

Links for use cases are under use-case label

Class Diagrams

Class Diagrams

Sequence Diagrams

Sequence Diagrams

Uses cases for needs - Sequence diagrams (1)

Uses cases for needs - SDs for Events

Uses cases for needs - SD for Actions (1)

8. Project plan, RAM and Communication plan

8.1. Project Plan

DPRfinal.pdf

8.2. Ram (Responsibility Assignment Matrix)

Ram.csv

Group 2 Disaster Response Platform

CMPE451

📌 Communication Plan
📌 Docker and local deployment tutorial
📌 RAM
📌 Test Traceability Matrix

📜 Rules
📝 Lab Reports
📅 Meetings
📅 Backend Team Meetings
📅 Mobile Team Meetings
👥 Team Members

CMPE352

📌 Milestone Report 1

📌 Milestone Report 2

📅 Meetings
👥 Team Members
📁 Project
🔍 Research
📜 Rules
📝 Templates
💬 Interviews
Clone this wiki locally