How to deal with gap analysis? Need clear definition for "gap analysis"

[chachamimm]

From the previous minutes:
McCool: we need a document on the current features.
... I agree we should not accept proposals which are already covered.
... Btw, I think user stories are good way to see the gaps also see issue 261 also
... #261
kaz: we need to define "gap analysis" a bit more
... user story is important but it's already required for the use case definition phase as the starting point
... my understanding on what Mizushima-san meant by "gap analysis" is evaluating if the requirements extracted from the use cases are already covered by the existing WoT standards or not
... but we still need to clarify what we mean by "gap analysis"

[egekorkan]

For me a gap analysis can be one of the following:

• A concrete feature description (of course one that doesn't exist in the respective spec)
• A requirement that is currently not satisfied. This can be simply labeling a requirement with "not met"

[egekorkan]

@chachamimm this would be a good issue to continue the lacking information I have identified in #299 . My main problem is having enough information to identify the gaps. I propose adding some questions in the gap section of the template that the submitter can pick and answer such as:

• Do you think some vocabulary keywords or mechanisms are missing in the TD standard to satisfy your use case? If so, please indicate.
• Do you think a new WoT standard is needed to satisfy your use case? If so, please indicate. (Note: This is probably the case for [TEST] Smart home: Leaving and Coming Home #299).
• Is there a missing binding to satisfy your use case? If so, please indicate.

[chachamimm]

@egekorkan It is good for your opinions. I think we should discuss this issue.

I think we have a lot of questions to ask our stakeholders. However, asking all of these questions would complicate a questionnaire. Then, it may be difficult for stakeholders to write their use cases.

For example, your proposals require stakeholders to have knowledge of TD and binding. Then, stakeholders need time to write their use cases. This makes it difficult for stakeholders to write use cases.

It's not that I want to reject your proposals.

The Use Cases Template should be easy for stakeholders to write their use cases. On the other hand, the Use Cases Template should be for WoT WG/IG to take many informations to standardize. I think their balance is important. I think we need to think about the best way to write your proposals in the use case template.

[chachamimm]

@egekorkan I think that explanatory text for each question item should be added in the Use Cases Issue Template. Because there are not enough information for each question items for stakeholders to write. @egekorkan, could you please add explanatory text for each question item in the Use Cases Issue Template?

[k-toumura]

There is a discussion about the classification of 'use cases' in #268.

1. Use cases to guide what should be standardized:
   • Including specific user stories: these should allow us to understand situation where TD is used, what to describe in it, etc.
   • It enables us to identify functions that are currently lacking in TD, discovery, etc. (= gap analysis)
2. Use cases to explain the applicability of WoT:
   • Clearly explain the benefit of using WoT to those outside the WoT WG, Chapter 4 and 5 of the current Architecture document may correspond to this. (the architecture TF might be a suitable candidate to collect and discuss them)
3. Case studies from implementing IoT solution using WoT:
   • Introduce the experiences of using WoT in specific projects. (the marketing TF or CG might be suitable to collect and discuss them)

If what we are currently collecting falls under category 1, I think we should place more emphasis on the clarity of the gap analysis.