search

bounswe / bounswe2023group1

Disaster Response Platform, Software Development
8 stars 2 forks source link

Review Requirement Specification #240

Closed kubraaksux closed 1 year ago

kubraaksux commented 1 year ago

Review Requirement Specification

Revisit requirement specifications, check on inconsistencies with mock ups and diagrams. Consider feedbacks from last semester. Pursue enhancements.

Assignees: Team

Deadline: 17.10.2023

Deadline: 03.11.2023

kubraaksux commented 1 year ago
kubraaksux commented 1 year ago

mockup shows system can be used without registration, if it is correct then this is not clear at requirements. -> 1.1.1, 1.1.2.1.1. changed 1.1.1 this is still an ongoing discussion. it should be finalized with a decision of unregistered user role/status.

kubraaksux commented 1 year ago

Language was ambiguous. Changed many lines for clarification: Date: 10.10.2023

previous

- 1.1.2.1 Victim

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

changed to

  • 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 asistance is available for him/her.

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.

changed to

  • 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.

added those

  • 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

previous points

  • 1.1.2.2.6 Coordinator shall be able to remove the assignee(s) from the task.
  • 1.1.2.2.7 Coordinators shall be able to get notifications for new responders signed up to the system for specific needs.

changed to

  • 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.

added those

  • 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.

previous points

  • 1.1.2.2.10 Coordinators shall be able to share information and update information shared by themselves.

changed to

  • 1.1.2.2.10 Coordinators can share and update information they provide.

added those

  • 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.

added

previous

  • 1.1.2.3.2 Facilitator role shall require an additional verification mechanism.

changed to

  • 1.1.2.3.2 Facilitator role requires an additional verification process.

added

  • 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.

previous

  • 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.

changed to

  • 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.

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.

changed to

  • 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.

previous

  • 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.

changed to

  • 1.1.2.4.7 Responders can check off items in to-do lists provided by coordinators to track their actions.

added

  • 1.1.2.4.8 Responders shall be able to see their current and previous tasks.

added

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.

changed to

  • 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.

added

previous

changed to

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.

changed to 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.

changed to 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.

Sub-titles are created and gathered under a title.

previous

1.2.3.1.2. Resources should be quantized and digitized on the system.

changed to with the addition of sub-title:1.2.3.1. Digitized resources 1.2.3.1.2. Resources must be digitized and quantified in the system.

added point and sub-title

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.

previous

  • 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.

changed to

  • 1.2.3.3.1. Resources should have semantic relationships for efficient categorization.

added point and sub-title

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.
kubraaksux commented 1 year ago

requirements should be updated according to the mockups. req and mockups are not on the same line and since mockups follow app developm closer now and some points has to be changed at req and some are not defined so, they has to be defined at req. check mockups for mobile and front and confusions mob front

kubraaksux commented 1 year ago

12.10.2023

previous

  • 2.1.1.1 The platform should prioritize and comply with data protection regulations such as GDPR/KVKK

changed to

  • 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.

previous

  • 2.1.2.1 Personal information and contact details of individuals affected by the disaster should be protected and kept confidential.

changed to

  • 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.
kubraaksux commented 1 year ago

13.10.2023 previous

changed to

previous

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

changed to

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.
kubraaksux commented 1 year ago

14.10.2023

  • Users shall be able to create an account on the system. changed to
  • Users shall be able to create an account on the system. Considering emergency situations, account creation is not mandatory situation.

this added to the version of requirements: | 6 | 2023/10/10 | 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. | 0.3 |240 []()|

kubraaksux commented 1 year ago

02.11.2023

Identified inconsistencies between the project requirements, the mockup designs, and the web application (APK) have been successfully resolved. I'm adding my revision:

previous

Users shall be able to create an account on the system. Considering emergency situations, account creation is not mandatory situation.

changed to

Users shall be able to create an account on the system. Considering emergency situations, account creation is not mandatory situation.. Unregistered users are, by default, assigned the "victim" role for immediate access to essential features without mandatory account creation.

previous

> - 1.1.2.4.1 Responders must provide information about the resources they can offer and add them to their profiles.

changed to

  • 1.1.2.4.1 Responders must provide information (location, quantity, type, status, priority also preferably additional description) about the resources they can offer and add them to their profiles.

previous

  • 1.1.2.4.2 Any user can become a responder after providing sufficient information to the system.

changed to

Any user wishing to become a responder must upload a valid identification document as a necessity for their role transition in the system.

previous

1.1.2.4.5 Responders can update the status of their tasks as: not started, in progress, completed.

changed to

1.1.2.4.5 Responders can update the status of their tasks as: to do, in progress, completed.

previous

  • 1.1.2.1.3 Victims should be able to access critical locations (Help centers, soup kitchens etc.).

changed to

Victims should be able to access critical locations (Help centers, soup kitchens, etc.). Additionally, they should have the capability to view resources provided by responders, including the status of these resources (such as "to be delivered," "in progress," "completed"), and access information about other requests shared by fellow victims.

kubraaksux commented 1 year ago

mockup shows system can be used without registration, if it is correct then this is not clear at requirements. -> 1.1.1, 1.1.2.1.1. changed 1.1.1 this is still an ongoing discussion. it should be finalized with a decision of unregistered user role/status.

this problem solved by:

changing this: 1.1.1 User Registration

Users shall be able to create an account on the system. Considering emergency situations, account creation is not mandatory situation. Unregistered users are, by default, assigned the "victim" role for immediate access to essential features without mandatory account creation.

to that

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.

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.

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.

1.1.1.4 Role Selection

Upon logging in, users must choose their role to proceed. Initially, users will only see the "victim" role. After submitting a successful role request, users will have access to view and select from their approved roles on the user role selection page after signing in.

kubraaksux commented 1 year ago

This point added according to customer's request for easy and quick sign in process. We have considered customer's needs and points and found this as a most suitable form for our project: 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.

kubraaksux commented 1 year ago

Check document: https://github.com/bounswe/bounswe2023group1/wiki/Requirements-Revision-for-Cmpe451-%E2%80%90v1-%E2%80%90%E2%80%90-Req-Version-0.3

Rolled over to https://github.com/bounswe/bounswe2023group1/issues/363 with latest improvements.