Requirements Revision for Cmpe451 ‐v1 ‐‐ Req Version 0.3 - bounswe/bounswe2023group1 GitHub Wiki
Mockup Showing Unregistered User Access Clarification
In response to feedback and ongoing discussions, the requirements have been updated to clarify the system's usage without registration. The relevant changes are as follows:
Previous:
1.1.1 Users shall be able to create an account on the system. 1.1.2.1.1 Everyone shall be able to be a victim after providing sufficient information to the system.
Revised:
1.1.1 User Registration Users shall be able to create an account on the system. Considering emergency situations, account creation is not mandatory.
Ongoing Discussion and Clarification
Additionally, the following changes and clarifications have been made to ensure a better understanding of the system's roles and functionalities:
Victim Role
Previous:
1.1.2.1.1 Everyone shall be able to be a victim after providing sufficient information to the system. 1.1.2.1.2 Victim shall be able to give information about the current situation (primarily his/her needs.) 1.1.2.1.3 Victim shall be able to see important locations (Help centers, soup kitchens, etc.) 1.1.2.1.4 Victim shall be able to get notifications and directions whenever any kind of help is available for him/her.
Revised:
1.1.2.1.1 Any user should be able to assume the role of a victim after providing the necessary information to the system. 1.1.2.1.2 Victims must have the capability to report their current situation and needs. 1.1.2.1.3 Victims should be able to access critical locations (Help centers, soup kitchens, etc.) 1.1.2.1.4 Victim shall be able to get notifications and directions whenever any relevant assistance is available for him/her.
Coordinator Role
Previous:
1.1.2.2 Coordinator 1.1.2.2.1 Coordinators shall be assigned by admins. 1.1.2.2.2 Coordinators shall be unassigned by admins only. 1.1.2.2.3 Coordinators shall be able to suspend a user if this user is not a coordinator or admin. 1.1.2.2.4 Coordinators shall be able to request a responder to take a specific action. The coordinator must provide all the necessary information for the action.
Revised:
1.1.2.2 Coordinator 1.1.2.2.1 Coordinators must be assigned by administrators. 1.1.2.2.2 Only administrators can unassign coordinators. 1.1.2.2.3 Coordinators should have the authority to suspend non-coordinator or non-administrator users. 1.1.2.2.4 Coordinators can request responders to take specific actions with providing all necessary details. 1.1.2.2.5 Coordinators shall be able to create tasks consisting of to-do action lists that can be marked as completed by responders, allowing for easy progress tracking of the tasks. 1.1.2.2.6 Coordinators have the ability to remove assignees from tasks. 1.1.2.2.7 Coordinators shall receive notifications for new responders signing up for specific needs. 1.1.2.2.8 Coordinators shall be able to view all user profiles, actions, and information provided by facilitators. 1.1.2.2.9 Coordinators shall be able to view, delete or reply to the requests. 1.1.2.2.10 Coordinators shall be able to share and update information they provide. 1.1.2.2.11 Coordinators shall be able to delete or update information shared by facilitators. 1.1.2.2.12 Coordinators shall be able to view, delete or reply to reported problems. 1.1.2.2.13 Coordinators shall be able to send requests to the admins.
Facilitator Role
Previous:
1.1.2.3.2 Facilitator role shall require an additional verification mechanism. 1.1.2.3.6 Facilitators should be able to view the needs of the victims and include the victims' needs in the facilitators' requests. 1.1.2.3.7 Facilitator shall be able to update requests. Updates should be trackable. 1.1.2.3.8 Facilitator shall be able to give feedback about any ongoing actions that are sent by the coordinators. 1.1.2.3.9 Facilitators should verify action requests that are sent by responders. 1.1.2.3.10 Facilitators shall be able to share information and update information shared by themselves.
Revised:
1.1.2.3 Facilitator 1.1.2.3.1 Responders and victims can apply for a facilitator role. 1.1.2.3.2 Facilitator role requires an additional verification process. 1.1.2.3.3 The facilitator role shall be granted through automatic authentication by the system, or through manual authentication by a coordinator or an admin. 1.1.2.3.4 Facilitators shall be able to create requests. 1.1.2.3.5 Facilitators shall be able to create resources. 1.1.2.3.6 Facilitators can view victims' needs and include them in their requests. 1.1.2.3.7 Facilitators can update requests with trackable changes. 1.1.2.3.8 Facilitator shall be able to provide feedback on any ongoing actions sent by the coordinators. 1.1.2.3.9 Facilitators should verify action requests from responders. 1.1.2.3.10 Facilitators shall be able to share and update information they provide.
Responder Role
Previous:
1.1.2.4.1 Responder shall provide the necessary resources. Responders shall be able to add information about resources they can provide to their profiles to be used later 1.1.2.4.2 Everyone shall be able to be a responder after providing sufficient information to the system. 1.1.2.4.3 Responders shall be able to accept or decline an offer to accomplish a task assigned by the coordinator. 1.1.2.4.4 Responders shall be able to comment using the sections on the windows provided for their actions. 1.1.2.4.5 Responders shall be able to update the statuses of their tasks. The statuses are: not started, in progress, and completed. 1.1.2.4.7 Responders shall be able to tick boxes in a to-do list if a to-do list is provided by coordinators for action in order to track the series of actions.
Revised:
1.1.2.4.1 Responders must provide information about the resources they can offer and add them to their profiles. 1.1.2.4.2 Any user can become a responder after providing sufficient information to the system. 1.1.2.4.3 Responders can accept or decline task assignments from coordinators. 1.1.2.4.4 Responders can comment on their actions using the sections on the windows provided for their actions. 1.1.2.4.5 Responders can update the status of their tasks as: not started, in progress, completed. 1.1.2.4.6 Responders shall be able to view all information provided by facilitators. 1.1.2.4.7 Responders can check off items in to-do lists provided by coordinators to track their actions. 1.1.2.4.8 Responders shall be able to see their current and previous tasks.
Admin Role
Previous:
1.1.2.5.2 Admins shall delete the user roles if there is any abuse or misuse related to that user. 1.1.2.5.3 Admins shall see any bug reports about the system and respond & fix it. 1.1.2.5.4 Admins shall help to the coordinators whenever technical assistance is needed. 1.1.2.5.5 Admins shall manually verify any document that requires verification whenever needed. 1.1.2.5.6 Admins should dynamically provide new additions to the system according to user needs and feedback. 1.1.2.5.7 Admin role shall only be given by the project owners. 1.1.2.5.8 Admin shall send notifications to other admins. 1.1.2.5.9 Admin shall see the live statistics of the system.
Revised:
1.1.2.5 Admin 1.1.2.5.1 Admins shall be able to assign coordinator and facilitator roles to designated users. 1.1.2.5.2 Administrators can revoke user roles in cases of abuse or misuse. 1.1.2.5.3 Administrators can handle bug reports, respond to them, and apply fixes. 1.1.2.5.4 Administrators can provide technical assistance to coordinators. 1.1.2.5.5 Administrators can manually verify documents when needed. 1.1.2.5.6 Administrators can dynamically expand the system based on user needs and feedback. 1.1.2.5.7 Admin roles are exclusively granted by project owners. 1.1.2.5.8 Administrators can send notifications to other administrators. 1.1.2.5.9 Administrators have access to live system statistics.
Previous:
1.1.4. Users shall be able to search and filter among the information provided by facilitators. 1.1.5. Users shall be able to report a warning about current disasters.
Revised:
1.1.3. Location Services
Users shall be able to view the map and share their current location information on the map. 1.1.4. Information Filtering Users shall be able to search and filter the information provided by facilitators. 1.1.5. Disaster Reporting Users can report warnings about current disasters.
Previous:
1.2.1.1 The system shall provide multi-hazard support, meaning that it should be able to handle and respond to multiple types of disasters and emergencies, such as natural disasters (e.g. earthquakes, floods, hurricanes), man-made disasters (e.g. explosions, fires, terrorist attacks), and public health emergencies (e.g. pandemics, epidemics). The system must be flexible enough to accommodate different needs and response strategies depending on the type of disaster.
Revised:
with the addition of sub-title: 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.
Previous:
1.2.2.1. The platform must be multilingual to provide use for multinational people.
Revised:
with the addition of sub-title: 1.2.2. Multilingual Support 1.2.2.1. The platform must support multiple languages to cater to a diverse user base.
Previous:
1.2.3.1.2. Resources should be quantized and digitized on the system. 1.2.3.3.1. Resources should have semantic relations. For example, boots and shoes or heaters and blankets should have the same categories as they meet similar needs.
Revised:
Sub-titles are created and gathered under a title. 1.2.3 Resource Management title includes: 1.2.3.1. Digitized resources, 1.2.3.2. Categorization of resources, 1.2.3.3. Semantic relations between resources, 1.2.3.4. Dynamic needs Dynamic Needs currently created.
1.2.3.1. Digitized resources 1.2.3.1.2. Resources must be digitized and quantified in the system. 1.2.3.2. Categorization of resources 1.2.3.2.1. To facilitate distribution, sent resources should be categorized in detail, including the contents of each box, quantity, shoe/clothing size, etc. 1.2.3.3.1. Resources should have semantic relationships for efficient categorization. 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.
Previous:
2.1.1.1 The platform should prioritize and comply with data protection regulations such as GDPR/KVKK 2.1.2.1 Personal information and contact details of individuals affected by the disaster should be protected and kept confidential.
Revised:
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. 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.
These changes aim to provide more clarity and comprehensiveness to the requirements, ensuring a better understanding of the system's functionalities. The ongoing discussions and revisions reflect commitment to delivering a robust and effective system.
Version details: Reviewing and enhancing requirements due to requirements language syntax and former feedback from the last semester. Inconsistencies are eradicated with overall design (mockups, diagrams), any ambiguities are eliminated with regards to the syntax of requirements for clear understanding.
Report Prepared By: Kübra Aksu 14.10.2023