Open egekorkan opened 7 months ago
A discussion/suggestion/proposal in another issue that I think belongs here: https://github.com/w3c/wot-usecases/issues/257#issuecomment-1907308039
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).
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".
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.
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.
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:
Backtracking some additions in TD 1.1 and 1.0:
Note: I can add more backtracking examples.