User Stories in Work Item Descriptions

planning/work-items/usability-and-design.md

@@ -50,14 +50,39 @@ Checking overlaps with architecture.
 
 ![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/reusable%20connections)
 
+TODOs:
+
+- The use case should be linked to the user stories above.
+- Bring the text from the issues comments such as https://github.com/w3c/wot-thing-description/issues/1248#issuecomment-2247656558 and
+- Collect Stakeholders: People who submitted issues/UCs (who wants it first), spec writers (people from the TF who want to help writing the spec on this feature), people who want to implement the feature in their implementation, people who will be impacted by the change (this is probably the whole community). These stakeholders each need a clear definition and example. The kind of impact (implementation, security, privacy, etc.) needs to be defined as well.
+
+**User Stories:**
+
+1. Connection Oriented Protocols
+
+- **Who:** Deployer of devices with connection oriented protocols
+- **What:** Reusable Connection descriptions in a TD
+- **Why:** Better describe connection oriented protocols such as MQTT and WebSockets (Problem nb. 4 below)
+
+- Sentence: **As a** deployer of devices with connection oriented protocols, **I need** reusable Connection descriptions in a TD, **so that I can** better describe connection oriented protocols such as MQTT and WebSockets (Problem nb. 4 below)
+
+2. Reusable Defaults per TD
+
+- **Who:** Designer/Developer of TDs
+- **What:** Reusable Connection descriptions in a TD
+- **Why:** Simplify TDs in cases without usage of default terms or to avoid redundancy (Problem nb. 1, 2 and 3 below)
+
+- Sentence: **As a** designer/developer of TDs, **I need** reusable connection descriptions in a TD, **so that I can** simplify TDs in cases without usage of default terms or to avoid redundancy (Problem nb. 1, 2 and 3 below).
+
 **Problem:**
+
 Currently, each form of an affordance has information on the endpoint, media type and other protocol related information.
 It is possible to use the base term for simplifying the endpoint but it has limitations such as:
 
-- If the media type is common across forms but is not `application/json`, it is repeated in each form.
-- If there are common protocol stack configurations such as different default verbs, baud rates, and endianness, they are repeated in each form
-- Multiple bases are not possible. Thus, each form repeats multiple bases. This is relevant when a TD has local and public IP addresses
-- For protocols that are based on an initial connection and then subsequent messages, the semantics are not clear. Thus, a Consumer can establish multiple connections instead of reusing the initial connection. See the Example of the Message Flow section below
+1. If the media type is common across forms but is not `application/json`, it is repeated in each form.
+2. If there are common protocol stack configurations such as different default verbs, baud rates, and endianness, they are repeated in each form
+3. Multiple bases are not possible. Thus, each form repeats multiple bases. This is relevant when a TD has local and public IP addresses
+4. For protocols that are based on an initial connection and then subsequent messages, the semantics are not clear. Thus, a Consumer can establish multiple connections instead of reusing the initial connection. See the Example of the Message Flow section below
 
 Related Issues:
 
@@ -75,8 +100,10 @@ Related Issues:
 
 - Basic Requirement: A mechanism to describe connection and protocol information that other forms can use is needed. In protocols with initial connection, this can also be used to indicate what needs to be done by the Consumer before executing any operation.
 - Detailed Requirements:
-  - Each connection needs to be identifiable, but we need to make sure not to include privacy or security risks
+  - Each connection needs to be identifiable
+  - Each connection needs to be linkable from affordances or forms
   - The initial connection must not be mandatory to establish upon TD consumption and should left to the implementation when to establish and close it.
+- Requirements are available at <https://github.com/w3c/wot-thing-description/issues/1248#issuecomment-2247656558>
 
 **Notes:**