Update QoD_User_Story.md

documentation/API_documentation/QoD_User_Story.md

@@ -2,9 +2,9 @@
 
 | **Item** | **Details** |
 | ---- | ------- |
-| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service), stable latency or stable throughput for a specified App-Flow from a Communication Service Provider (CSP), so that I can ensure better quality of experience for our end users including under network congestion.  |
-| ***Roles, Actors and Scope*** | **Roles:** Customer:User<br> **Actors:** Application service providers, hyperscalers, application developers. Currently the API does not explicitly handle consent management (expects that the customer either owns the device subscriptions or has agreed to manage consent as a part of general Terms and Conditions) and hence end users are not included as Actors. As this changes, the actor list will be extended with end users. <br> **Scope:** *Order To Activate (OTA)* \- Create/Remove/Get service instance (QoD session resource)\, get notification about the instance (QoD session resource) |
-| ***Pre-conditions*** |The preconditions are listed below:<br><ol><li>The Customer:BusinessManager and Customer:Administrator have been onboarded to the CSP's API platform.</li><li>The Customer:BusinessManager has successfully subscribed to the QoD product from the product catalog.</li><li>The Customer:Administrator has onboarded the Customer:User to the platform.</li><li>The Customer either owns the device subscriptions or has agreed to the terms and conditions of the CSP for managing consent of subscription owners.</li><li>The means to get the access token are known to the Customer:User to ensure secure access of the API.|
-| ***Activities/Steps*** | **Starts when:** The customer application server makes a POST request to the QoD API to create a new QoD session resource and optionally registers a callback URL for receiving notifications.<br>**Ends when:** The customer application server makes a DELETE request to the QoD API, or the QoD session resource deletion was triggered automatically either because the customer specified duration has expired or the default expiration limit set by the QoD service provider has reached. |
+| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service), stable latency and/or stable throughput for a specified App-Flow from a Communication Service Provider (CSP), so that I can ensure better quality of experience for our end users including under network congestion.  |
+| ***Roles, Actors and Scope*** | **Roles:** Customer:Developer<br> **Actors:** Application service providers, hyperscalers, application developers. This User Story does not explicitly describe consent management and hence end users are not included as Actors.<br> **Scope:** *Order To Activate (OTA)* \- Create/Remove/Get service instance (QoD session resource)\, get notification about the instance (QoD session resource) |
+| ***Pre-conditions*** | The preconditions are listed below:<br><ol><li>Customer:Developer is eligible to use the QoD API, i.e. the Customer has successfully subscribed to the QoD API on the platform of an API Provider</li><li>the customer application server has requested and received an access token for the required scopes of the API. Which specific authorization flows are to be used will be determined during onboarding process.</li><li>Optional: the customer application server has requested the list of available QoS Profiles with the qos-profile API (alternatively an upfront agreed QoS profile will be used)|
+| ***Activities/Steps*** | **Starts when:** The customer application server makes a POST request to the QoD API to create a new QoD session resource with a specified duration and an available QoS Profile, and optionally registers a callback URL for receiving notification events.<br>**Ends when:** The customer application server makes a DELETE request to the QoD API, or the QoD session resource deletion was triggered automatically either because the set duration has expired or the session was terminated by the network (e.g. due to lack of resources). |
 | ***Post-conditions*** | The specified App-Flow was provided stable latency or stable throughput and if callback URL was specified, a QoD session resource termination notification was received at the end.  |
-| ***Exceptions*** | Several exceptions might occur during the QoD API operations<br>- Unauthorized: Not valid credentials (e.g. use of already expired access token).<br>- Invalid input: Not valid input data to invoke operation (e.g. IP address format not as expected).<br>- Conflict: Internal configuration policies didn’t allow for operations.<br>- Session-not-created: Due to other internal errors, QoS session resource could not be created|
+| ***Exceptions*** | Several exceptions might occur during the QoD API operations<br>- Unauthorized: Not valid credentials (e.g. use of already expired access token).<br>- Invalid input: Not valid input data to invoke operation (e.g. IP address format not as expected).<br>- Conflict: Internal configuration policies didn’t allow for operations, e.g. a second QoD session for one device.<br>- Session-not-created: Due to other internal errors, QoS session resource could not be created|