Expectations of the TD stakeholders from the Use Case process

[egekorkan]

In the previous TD TF calls, we have discussed (based on the request of @ashimura) what the stakeholders expect from the use case process. By stakeholders we mean two entities, TD TF participants and the users/implementers of TD. This can be used as inputs to the use cases process.

TD TF Participants

• @egekorkan

  1. As a result of the UC process, an issue is created in the TD repository that has all the information needed to start working on the discussions to design the feature. This means that the TD TF is not required to contact the people involved in the creation of the use case and requirement and that no other document but the issue is required to create the feature
  2. The person to contact who is interested in implementing it in a WoT implementation (Thing or Consumer). If TD TF participants need the feature, this can be omitted by putting the TF participant as the contact. This is important so we do not work on features that no one is interested in implementing. A not implemented feature will end up removed after testing for the implementation report. (+1 from @relu91)

• @lu-zero: We get use cases and document them so that we do not lose something. E.g. there is a whole application area that we cannot address due to a missing feature.

• @relu91: The result of the UC process should be something actionable that we can discuss in the TD TF and implement into the spec.

Users or Implementors of TD (and WoT)

Note: This stakeholder group should be further clarified. E.g. do we mean developers, architects, end users (nontechnical person), etc.

• @egekorkan: Identify a similar use case to theirs and get more context about a specific feature.
• @lu-zero:
  1. There should be no need to go to the use cases document to understand something. If that happens, our spec is not clear enough. For a more advanced user, we can show a way to submit a UC if they find a gap in the respective chapter of the spec. This will help us get more specific input. This can be guided via an issue template.
  2. From a Marketing POV: People who are looking for a problem can find the solution to their problem. -> That implies that from use cases and requirements, we point to the features (UC -> req -> feature)
• @relu91: It would help to know if they are in "uncharted" territories. In that case, we can say that "you may have issues since we did not explore this area yet". If it already exists, then they can refer to the existing work and even contact the people (including WG/IG people) who were involved in that use case.