Meeting minutes
Basic plan about how to proceed
Mizushima: I propose how to proceed
Mizushima: Today we settle
the discussion on the process
… Next week we clarify basic templates: one for use
cases and another for requirments
… In 2 weeks we start to think about several
concrete use cases and requirements based on the proposed
template
… Do we have consensus on this plan?
<kaz> [approved]
Minutes review and GitHub Issue creation (with "Process" label)
Workflow
Mizushima: Last week we approved the workflow and I prepared 4 issues on github
<kaz> Jan-31 minutes
<Mizushima> What to do today
Four Issues created based on the discussion during the previous call
<kaz> Issue 263 - How to extract information, e.g., about requirements, from the UC description?
<kaz> Issue 264 - When/which level of UC description to be generated?
<kaz> Issue 265 - Who/how to submit UCs?
<kaz> Issue 267 - How to deal with gap analysis? Need clear definition for "gap analysis"
Minutes approval
Mizushima: if there aren't further questions on opinions, I'd like to approve the minutes
<minutes approved>
Issue 257
<kaz> Issue 257 - [Discuss] Focus on Functional Requirements
Discovery and Security
McCool: We had canceled
security and discovery so I have time to attend this meeting
… next week I'd like to restart Discovery and
Security meetings
… I'd rather speed up the UC discussion
Kaz: Mizushima-san's plan is to discuss the process this week, clarify the basic templtes for UC/REQ nxt week, and then tackle concrete issues after that. So yes, there is a bit of delay
Issue 257 - revisited
<kaz> Issue 257 - [Discuss] Focus on Functional Requirements
Mizushima: I've summarized the
issue of functional vs technical requirements and I'd like to split
the discussion into several sub issues in addition to the original issue 257
… - We should continue the discussion about
"Functional vs Technical Requirements" using the GitHub Issue
257.
… - For that purpose, we need to clarify (a) what
we mean by "functional" and "technical" and (b) what we expect for
"user stories".
… - We should create a separate Issue for
Toumura-san's comment about the structure/category of the use case
description.
… - It seems there are some more different points
included here, and I'd like to suggest we handle those points
separately using three more different Issues
1. What level (technical, functional, business, etc.) to be described for use cases?
2. What would be the possible items for use case description?
3. How to deal with the feedback from the TFs working on each specification,
e.g., possible bottom-up use case proposal based on necessary features?
Kaz: OK with adding those three issues
Luca: I agree that the current issue 257 is not descriptive and we should edit it and link the 3 subissues from there
Mizushima: I'd create the issues after this meeting if there is consensus
Kaz: There are 5 new issues, including Tomura-san's proposal for categorization (so 6 new issues in total)
Mizushima: objections on this?
<no objections>
Need to clarify the basic structure of the Use Cases and Requirements document
Mizushima: How to organize UC
and Requirements?
… Sometimes a UC may lead to multiple requirements,
so I'd split the UC template from the Requirements
template
<Ege> +1 to the fact that we have a many to many mapping
Ege: I agree it should
be separated, but we should make sure that the requirements that
bring a specification change should be a separate document
requirements that aren't as precise can be part
of their UC document
McCool: We do already have separate templates
Ege: I guess we should
see in practice, since I'm not sure we agree on the definition of
requirements
Luca: I agree with Ege we
need to see in practice what we currently have, in general we have
many to many map between UC and Requirements, so we should have
interlinked documents for both
… we should also make so that for each UC accepted
we have cross-links with the Requirements document it covers and
issues tracking both so for the next UC accepted we have to update
the links to the pre-existing Requirements it covers
<kaz> WoT Use Cases and Requirements
Kaz: As Michael McCool
mention the current "WoT Use Cases and Requirements" document has two separate sections, one for Use Cases and another for Requirements
… On the other hand, as Ege and Luca mentioned, there is a possibility we have two separate documents, one for Use Cases and another for Requirements
… We might have to think of two levels of requirements: ones for the UC, that are functional, and ones for the specification, that are technical.
… "Functional Requirements" extracted from the Use Cases should be included in the "WoT Use Cases and Requirments" document, while "Technical Requirements" could be handled by each specification, e.g., WoT Thing Description and WoT Discovery, as the basis of feature definition.
… I think that is the core of the question around "Functional vs Technical".
<McCool> +1 to kaz's two-level requirements, related to func/tech
Kaz: we need to clarify those two level first
Ege: A more detailed example is really needed to make clear this separation
Toumura: I think depending on the functionality, we might start from the functionality and then link it to multiple UC (so bottom up vs top down)
Kaz: I think part of it is already covered by Mizushima-san's proposal: How to deal with the feedback from the TFs working on each specification, e.g., possible bottom-up use case proposal based on necessary features?
Kaz: We should probably open an additional issue to clarify what to do in the case of bringing in a Requirements before UCs and provide more examples
Mizushima: I think stakeholders might bring UC (bottom-up) while we might bring first Requirements (top-down)
Ege: our current UC tend to be too high level to bring a specification input as they are
<McCool> time check - 5m left in meeting
Ege: We should avoid
ending up as in the previous charter situation in which the
submitted UC require lots of effort to extract requirements
… we cannot do consulting service for
free
… I do not want to drive the specification with
overly generic UC
Luca: We can reject UC that are overly generic and without Requirements so we can live with
<McCool> ntd - see you in main call
Kaz: I agree Luca and Ege that we should reject UC if the description is too generic and not enough. next week or in two weeks we should clarify the criteria for that
[adjourned]