Meeting minutes
agenda and minutes
<Mizushima> Agenda for today
Mizushima: agenda at https://
Mizushima: prev minutes https://
<kaz> Feb-28: Fix basic templates for Use Cases, Functional Requirements and Technical Requirements
<kaz> Mar-6: start concrete work on Ues Cases, Functional Requirements and Technical Requirements
Mizushima: we also need to think about the publication schedule
Mizushima: minute review
Mizushima: can we approve the minutes?
… no objections, approved
Mizushima: also can we approve the discussion points?
… no objections, approved (discussion summary is in agenda)
Discuss Use Cases, Requirements using Smart Home example
Mizushima: would like to start with discussion of use case template
… also, we've been discussing ECHONET's new proposal on grouping devices for a few weeks, but no use case yet
… propose we use that as a test case
Mizushima: would like to understand what needs to be in the use case template and what does not
McCool: think the security consideration is a good example here
Kaz: is discussed below
McCool: ok, let's move on then
Mizushima's proposal on what to be added
Mizushima: a few things could be added: Potential adopters, Potential applications, Stakeholder's interest
… for stakeholders, why WoT?
Mizushima's proposal on what to be removed
Mizushima: as for what can be removed, dependency on WoT specs, X considerations (can be wide review), gap analysis
Mizushima: perhaps can also remove references to existing standards
Mizushima: it would also be good to identify which use cases are "typical" or "atomic"
Mizushima: for existing standards, should clarify the relationship to an existing standard
… should we refer to it? should the WoT be compatible? should we add new features to WoT and why?
How to deal with Users' needs?
McCool: think the point of the use case template is to *elicit* requirements from the use case submitter; then we consolidate ("extract") them.
… for the "considerations" in particular, really these sections could be called "Security Requirements", etc - we are asking whether this use case has any special needs
… what we could do however is ask some more specific questions, like "Does this use case handle private data?" or "Are any specific access controls or roles needed?" that would help us gather more concrete information. In general, each section of the template could provide more guidance for the kind of information needed.
Kaz: technically, can understand McCool's point
… but also understand Mizushima's point
… depends on our own policy on whether the original submitter should work on requirements or not
… McCool's approach is to ask submitters to include all information in use case, Mizushima's approach is to work with the submitters to work also on requirements sections
… but also as McCool mentioned, there could be additional questions to clarify things later.
McCool: will note that in general when people have submitted use cases, we have iterated with them to extract more information on requirements
… so whether or not we associate requirements directly with a use case, we need to link them
Kaz: agree, either way we need to link the requirements back to the use case
McCool: either way, the use case submitter needs to be aware that they need to provide requirements; that is the purpose of the exercise.
… as for existing standard, agree it would be good to ask why each linked standard is important
… and what we should do about it
Mizushima: agree/understand with McCool/Kaz - we have to extract implementer's needs
… in template, the submitters describe their needs
Mizushima: then in joint discussion, we extract requirements
McCool: note that this Echonet example is exceptionally detailed, often the use cases have been much less complete and we have had to do more to extract requirements
Mizushima: think use case template should be simple
… if it is too complicated, then submitter cannot describe their use case
Kaz: agree, we should have some more concrete guidelines
… for use case template itself, might be easier for them to understand if we ask for needs, etc.
McCool: one way to go would be to break it into two parts, "description" and "needs"
… but "need" and "requirements" are synonyms :)
Kaz: true, but "requirements" have specific meaning in standards
Mizushima: think after submitting use cases, we should hear their points
McCool: we always have met with people to try to refine their use cases, but I still think having a checklist of questions would make the process more precise
McCool: disagree with removing these items, but as a proposal we could split the template into two parts, description and requirements, and deal with them in two phases
Kaz: I think Mizushima-san's mentioned "guideline" and McCool's mentioned "checklist" could be similar at least as a guide for people to see how to submit a use case.
McCool: by "checklist" I mean a set of questions to elicit more detailed requirements for each use case
… but we probably also should focus on gaps, e.g. needs not met by current WoT standard
Mizushima: we have been discussing the use case template
McCool: if we remove items from the template, do we remove them from existing use cases?
… in general, we have avoided this, and have considered each use case the "property" of the submitter
… however, the requirements section is written by the task force, and was meant to be a summary
Mizushima: ok, we are out of time, let's continue next week.
<kaz> [adjourned]