Thoughts from the TD Use Case Discussions

[egekorkan]

In the previous TD meetings, we had some discussions about what we need from use cases process. These are currently documented in the meeting agenda but I would like to move them here. I am copying them below to give them a place. We can discuss this in a use case call:

Overall thoughts:

• Use Cases should be iterated to extract the information we need.
  • Relates to Adding new fields to templates #192
• New use cases should at least have the information we need as a TF. We can filter out current use cases if they cannot fulfill the new template requirements, thus at least the TD TF requirements.
• We can extract User Stories from Use Cases. A User Story contains what the user (developer) wants to do with WoT (TDs) and whether are they able to do it. E.g. as User X, I want to ABC so I can achieve XYZ. It is better if the user or the persona is visible in the User Story.
  • The TD TF thinks that if they are submitting a User Story, they are not able to do what they want to do.

Backtracking some additions in TD 1.1 and 1.0:

• Thing Models
  • Use Case: Managing/Representing a set of instantiations of the same model of a device. Correlating (search) in a collection of TDs that represent the same model of the device.
  • User Story: As a device manufacturer, I want to write a TD-like document only once. TDs represent an instance but I need to represent the generic model of that device that each instance refers to via their TDs. If this is not standardized, I cannot guarantee that my customers understand this generic model representation.
  • Requirement: One file to represent a model of the device
  • Feature: Thing Model mechanism
• Extension/Submodel in Thing Models
  • Use Case: Reusability. Consistent affordance definition for reuse, e.g. of temperature.
  • User Story: As a device manufacturer, I want to reuse existing definitions and vocabularies in Thing Models. Semantic Ontologies are not enough since they may not result in concrete JSON serialization in a TM or TD.
  • Requirement: Reuse of existing definitions found in Thing Models
  • Feature: tm:submodel, tm:extends etc.
• synchronous word in actions
  • Use Case: Interacting with two robots that behave slightly differently (one replying right away and moving, the other moving and then replying)
  • User Story: As a Consumer application programmer, I want to do less trial and error when programming a new Consumer application. However, invoking an action can return a response right away or after the physical process has finished. Not knowing the difference in advance results in a trial-and-error process.
  • Requirement: A keyword indicating this behavior
  • Feature: "synchronous" keyword with boolean type

Note: I can add more backtracking examples.

[mmccool]

A discussion/suggestion/proposal in another issue that I think belongs here: #257 (comment)

[mmccool]

I do think the above examples are "user stories", not use cases. To me a use case is more comprehensive (e.g. "smart agriculture") and may lead to several user stories. A user story addresses a specific gap. So another way to look at this is that user stories are derived from use cases, and are really just a way to express a requirement. (As an S, I need/want R, in order to P) - S is stakeholder, R is requirement, P is purpose. Here P is an identified gap (something that can't be done with the current feature set).

So... this does relate to #257 after all - are user stories functional (what we want to do) or technical (how to do something)? I still think user stories in the UC&R document can be high-level and functional, and there can be more detailed technical ones maintained for each deliverable (if necessary).

[mmccool]

Related to discussion in meeting Jan 24: sometimes the user story comes first, but it still needs to be related to one (or more) use cases. To take an example above, the "synchronous word in actions" relates to robots, which are used in Factory automation. But then it talks about the stakeholder as a "Consumer application programmer", but probably this should be "Factory automation engineer"? Anyway, thinking about the use case can clarify the user story :)

Unless "Consumer" here is used in the TD Consumer sense... but then the stakeholder definition can be extended to include the use case: "Consumer application developer working on factory automation".

[mmccool]

Also related to point of how to get "detailed" use cases: we could ask submitters to provide a use case (a usage scenario from a specific application domain) and then also submit a set of user stories. If there aren't any user stories motivated by a use case then there are no gaps and...

See also #258 - this would be a form of gap analysis.

[chachamimm]

Features that we want to implement should be based on needs (requirements) from industry. So we have to collect a lot of use cases from industry and analysis them and get needs (requirements). If you can get the needs from user stories, I think user stories are also important.