Closed chinaunicomyangfan closed 6 months ago
LGTM. If there is no other comment, we can initialize a pr to put in the docs.
If the goal is "to quickly understand the population density in the area" why do not use Population Density API for that?
UC does cover how emergency rescue worker will estimate population density based on device number. How should they estimate population without a connected devices?
Acceptance criteria says that API provides number of users. However, we have agreed that API will expose number of connected devices.
@gregory1g As we discussed before, MNs can only obtain information on the number of connected devices. However, in user stories, rescue personnel are more concerned about the number of people, so they can use this API to estimate the number of people based on the number of devices. As far as I know, in Population Density API, population is also involved. Can they only count the number of connected devices and how do they solve this problem
PplDensity API expose population estimation, not number of devices.
Still, my concern here is: an API which exposes number of connected devices does not meet requirements of the UC description as this is done above. Therefore, UC description needs some adjustment. Or API must be redesigned to really expose number of users (where a single user can have multiple connected devices on them).
Suggestion for the UC: User Story 1 - Emergency Rescue As an emergency rescue worker, I hope to be able to obtain the number of users in an area where a special emergency activities could be needed through an API, so as to quickly understand the situation, plan and guide the rescue work. Background In the event of a disaster or emergency, understanding the population within the affected area is crucial for timely scheduling of rescue operations. Therefore, we need an interface to obtain this information. User requirements: 1.I hope to obtain the number of connected devices on people in the area by providing coordinates or boundary information. 2.I need the information returned by the API to include the total number and distribution of the devices in that area. 3.I need the response time of the API is very short, so that information can be quickly obtained in emergency situations.
Acceptance criteria 1.I can provide the coordinates or boundary information of the area by calling the API, and successfully obtain the number of connected devices on people in that area. 2.The information returned by the API includes the total number and distribution of the devices (using a grid). 3.The response time of the API should be within a few seconds to meet the needs of emergency rescue.
Thanks, @gregory1g LGTM
Thank a lot! @gregory1g This description is more in line with the functionality of this API. If there are no other modification suggestions, I will make the changes and put it in the document. Another question is whether the community has requirements for the format of user stories, and whether the format of QOD's user story is standard
There is some reference. But I think there is no requirements on that. Only if we elaborate it clear.
There is some reference. But I think there is no requirements on that. Only if we elaborate it clear.
Thanks:)
User Story has been added: PR is here: add User Story
Problem description Add the first User Story for Region User Count
User Story 1 - Emergency Rescue As an emergency rescue worker, I hope to be able to obtain the number of users in a certain area through an API, so as to quickly understand the population density in the area and guide the rescue work in emergency situations. Background In the event of a disaster or emergency, understanding the population size and density within the affected area is crucial for timely scheduling of rescue operations. Therefore, we need an interface to obtain this information. User requirements: 1.I hope to obtain the number of users in the area by providing coordinates or boundary information. 2.I need the information returned by the API to include the total number and distribution of users in that area. 3.I hope the response time of the API is very short, so that information can be quickly obtained in emergency situations. Acceptance criteria 1.I can provide the coordinates or boundary information of the area by calling the API, and successfully obtain the number of users in that area. 2.The information returned by the API includes the total number and distribution of users. 3.The response time of the API should be within a few seconds to meet the needs of emergency rescue. Remarks 1.This API can be implemented through the operator's data platform or relevant location service providers. 2.In practical use, it is necessary to ensure user privacy and data security, and ensure that user information is not abused.