First version of user stories doc

[jpengar]

This PR address issue #9

Upload first version of user stories doc in API documentation as agreed in 24/11 follow-up meeting.
https://github.com/camaraproject/HomeDevicesQoD/blob/main/documentation/MeetingMinutes/MOM-2022-11-24.md

[jpengar]

@bigludo7 If it is fine with u as a first version of user stories info, please approve the PR for me to be able to merge it.

[bigludo7]

Thanks !! it helps.
I have a couple of comments.

We need probably to clarify what is the target device - From your perspective, is it always the device where the app is running (meaning that from a device we can only prioritize the connectivity from/to this device) ? or can you imagine than from an app running on device A you can prioritize flow from router to device B, C, etc...?
If we are in this later it means than we need another endpoint to get all device connected.

Another point, don't you think that we have also a user story about retrieving current DSCP for the device?

Thanks

[JosueIgual]

We need probably to clarify what is the target device - From your perspective, is it always the device where the app is running (meaning that from a device we can only prioritize the connectivity from/to this device) ? or can you imagine than from an app running on device A you can prioritize flow from router to device B, C, etc...?
If we are in this later it means than we need another endpoint to get all device connected.

The expected behaviour is that the target device is the same device where the app is running. Due to this we do not need another endpoint to get all devices connected. [It is important also to mention that an endpoint that provides information about connected devices will be much more sensible and risky from Privacy point of view, and therefore we decided to not include this on the API]

Another point, don't you think that we have also a user story about retrieving current DSCP for the device?

Currently we do not needed. DSCP marks are removed from all WiFi Access Point every night, so the most probable baseline scenario each time a developer calls the API is that DSCP is set to CS0 unless the same developer has requested another DSCP during the same day.

[bigludo7]

Thanks @JosueIgual for the clarification.
As the user story should self-sufficient could we update the user story accordingly?

• perhaps in the scope part to indicate that the target device is the same device where the app is running (from which the request is triggered).
• In the post-condition indicating that the 'reset' could be triggered by the the BE (at a given frequency) or by another call to the API.

Thanks

[jpengar]

Another point, don't you think that we have also a user story about retrieving current DSCP for the device?

@bigludo7 Just to complete Josue's answer. We tried to keep API design as simple as possible. Considering the use case defined, having a get operation to just know the dscp set in a device does not provide so much value. Service developer does not need to perform 2 operations (a get first + a subsequent put). Actually, the developer could just set on demand the desired DSCP value when needed (without doing any get first). And in case they want to restore the default DSCP value when a device is already set with the default DSCP valule there is an specific 409 response defined HOME_DEVICES_QOD.QOS_ALREADY_SET_TO_DEFAULT: Device DSCP value is already set to default value. to let them know.

[jpengar]

Thanks @JosueIgual for the clarification.
As the user story should self-sufficient could we update the user story accordingly?

@bigludo7 Done. Please have a look at it.

[bigludo7]

Good for me.
Thanks