Milestone 1 report
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.
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.
| 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 |
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.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.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.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.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.
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.
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.
Mainly used for meeting confirmations and other daily human interactions.
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
- 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
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
- 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.
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.
- Ömer Şahin Albayram - Individual Contribution Report
- Begüm Arslan - Individual Contribution Report
- Hasan Bingölbali - Individual Contribution Report
- Aras Güngöre - Individual Contribution Report
- Halil İbrahim Gürbüz - Individual Contribution Report
- Merve Gürbüz - Individual Contribution Report
- Mehmet Emin İpekdal - Individual Contribution Report
- Cahid Enes Keleş - Individual Contribution Report
- Mehmet Kuzulugil - Individual Contribution Report
- Ramazan Burak Sarıtaş - Individual Contribution Report
- Egecan Serbester - Individual Contribution Report
Software Requirement Specification
March, 27 2023
Prepared by:
Group 2
Members
- Begüm Arslan
- Merve Gürbüz
- Cahid Enes Keleş
- Aras Güngöre
- Ersel Çanakçili
- Egecan Serbester
- Mehmet Emin İpekdal
- Halil İbrahim Gürbüz
- Ömer Şahin Albayram
- Hasan Bingölbali
- Ramazan Burak Sarıtaş
- Mehmet Kuzulugil
Prepared for
BOUN - CMPE 352 - Spring 2023
| 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 |
- 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).
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.
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:
- Facilitating the efficient allocation and distribution of resources, such as food, clothing, shelter, and medical supplies.
- Providing real-time location tracking and mapping to optimize aid delivery to affected areas.
- Streamlining communication between relief teams, local authorities, and affected individuals.
- 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:
- Improved coordination and organization of relief efforts, reducing redundancy and ensuring that aid is delivered to those who need it most.
- Enhanced efficiency in the allocation of resources, minimizing waste, and ensuring that resources are used effectively.
- Better communication and collaboration between relief teams, local authorities, and affected individuals, leading to more effective disaster response.
- Providing a centralized platform that can be easily accessed by various users, simplifying the management of disaster response efforts.
-
- 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.1.1 Registration
-
-
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.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.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.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.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.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.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.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.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.1. A resource shall have these attributes:
-
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.1.2.1. Subtypes of food shall include:
-
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.2.1 Events shall have these attributes:
-
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.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.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.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.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.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.1: The system shall support remember me feature.
- 1.2.9.2: The system shall support keep me logged in feature.
- 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.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.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.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
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.
- Aims to subscribe to a notification topic.
- Ayşe is already a role-based user in the system.
- She has the mobile application.
- 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.
| User photo | Persona |
|---|---|
 |
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. |
- Aims to find a resource on map.
- Egecan is already a authenticated-user in the system.
- He has the mobile application.
- 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.
Kadir is volunteering at Besni Food Collection Center after the earthquake. He is managing the inputs and outputs of the collection center.
- 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.
- Kadir is already an authenticated user in the system.
- 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.
| User photo | Persona |
|---|---|
 |
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. |
- Aims to create an emergency.
- Emin is a guest user in the system.
- He has the mobile application.
- 1.1.3.1.1 Guest users shall be able to create only one emergency.
Other Mockups
- Mockups reside in app.diagrams.net and lucidchart
-Account Profile \
Account profile in users's own perspective:
Account profile in authorized other users's perspective:
Account in general:
-
Main Page
-
Maps
-
User Actions
-
Admin
-
Resource
-
Event
-
Delete
-
Filter & Sort
