Meeting minutes
Updated plan
Mizushima: 2 weeks ago, proposed a plan
… but would like to update it based on the discussion on Feb 7
Feb-21 (today): Clarify Functional Requirements and Technical Requirements using some specific example(s) As a result, we should be able to get insights on possible templates for the following: * Use Cases * Functional Requirements * Technical Requirements Feb-28: Fix basic templates for Use Cases, Functional Requirements and Technical Requirements Mar-6: start concrete work on Ues Cases, Functional Requirements and Technical Requirements
Mizushima: is that ok?
Kaz: I'm OK if that's feasible :)
(no objections; updated plan approved)
Minutes review and GitHub Issue creation
Mizushima: (goes through the minutes)
… discussion on Issue 257
… continue the discussion about "Functional vs Technical Requirements"
… also additional 6 Issues derived from Issue 257
… then discussed how to deal with Use Cases and Requirements
… various opinions from the participants
… summary is:
… Need for sepration between Use Cases and Requirements so that we can describe the many to many mapping between Use Cases and Requirements
… Need to clarify possible 2 levels of Requirements needed
… Need to clarify them based on concrete example descriptions
… are the minutes OK?
(no objections)
minutes approved
Mizushima: then the above summary of the discussion approved?
(no objections)
Mizushima: so the discussion points have been approved
Clarification of Functional Requirements and Technical Requirements
Mizushima: Given the discussion on Feb-7, I think this topic, Functional Requirements and Technical Requirements, is very important
… so would like to continue the discussion
… would start with some basic definition
"Functional Requirements" are extracted from the Use Case descriptions, and to be included in the "WoT Use Cases and Requirements Note". That implies that the Use Case descriptions need enough information for the Use Cases TF to extract "Functional Requirements". On the other hand, "Technical Requirements" are generated based on the "Functional Requirements", and could be described within each specifaction by each specification TF, e.g, WoT Thing Description by the TD TF. That implies that the "Functional Requirements" need enough information for the specification TF to generate "Technical Requirements".
<Ege> +1 on that it is not a definition
McCool: this is not a definition itself, but how the document should do
… however, rather than trying to make the definition clear, we should just capture the requirements
… and see which ones are "Functional" and which ones are "Technical"
… simply requirements first, then categories, for example
Ege: agree with McCool
… this is not "definition" itself
… also agree we don't really need definition
… we should have examples rather than strict definition here
I would prefer to have PRs created before the call so that I can have a calm time reading them.
Kaz: agree
… and I think what Mizushima-san wanted to is rathr "what we need to do" or "roles" here
… rather than exact definition
McCool: agree
Kaz: so let's simply change the title from "Basic definition" to "What we need to do" here
(basic roles on what to do approved)
Concrete example
Mizushima: would like to start with an example of a smart home
… the results from this discussion should be useful for template discussion as well
Use Cases
Mizushima: Within a smart home, the user would like to control the air conditioner and the air purifier at once as if the air conditioner had built-in air purifier capability though they're actually two separate physical devices.
… how should we describe that kind of use case?
… the current use case template has:
* Submitter * Target Users * Motivation * Expected Devices * Expected Data * Dependencies * Description * Security Considerations * Privacy Considerations * Accessibility Considerations * Internationalization Considerations * Gaps * Existing Standards
Mizushima: are those enough to extract "Technical Requirements" later?
… also how should we deal with considerations on security, privacy, accessibility and internationalization?
Functional Requirements
Mizushima: Grouping of multiple physical devices, e.g., an air conditioner and an air purifier, as a virtual device, e.g., an air conditioner including air purifier capability
Technical Requirements
Mizushima: WoT Thing Description should handle the air conditioner and the air purifier as if they were a one single device.
… For that purpose, a TD can describe a virtual device, an air conditioner with air purifier capability, and then export it to the Consumer.
… The Consumer can handle the exported virtual air conditioner via that TD.
… The WoT Discovery also needs to let a Consumer discover a virtual device based on that TD.
Discussion
Mizushima: Use Case is the first work
… so would start with Use Case here
… then Functional Requirements
… then Technical Requirements
Ege: thanks for providing this concrete example
… the question here is if the information within the Use Case template enough for requirements extraction
… we generally would like to have knowledge about that here
… then
… Functional Requirements should be provided by the Use Case submitters themselves
… also
… if there is no Gap with the existing standards, we can simply go ahead
Kaz: tx from me too
… the example seems OK to me
… only one comment is extracting not only "Technical Requirements" from Use Cases
… but also "Functional Requirements"
… so both Functional Requirements and Technical Requirements
… then as Ege also was wondering, who/how to extract the requirements?
… collaboration with the use case submitters for functional requirements
… collaboration with the spec TFs for technical requirements
… but those points are for the next step
McCool: all the above related to both the Functional Requirements and Technical Requirements
… this use case can be worked with ECHONET who are still active
… regarding the gaps, requirements from ECHONET APIs with WoT APIs
… actual analysis to be done to clarify the Technical Requirements
… so need to add further details
… we should have some criteria to see if the requirements are satisfied
Ege: in this case, we can see the gaps with their standards
McCool: requirements need to be confirmable
Kaz: let me summarize the discussion so far
… we're OK with Mizushimas-san's proposed direction
… displayed example on grouping of devices is fine
… but all the three items, Use Case, Functional Requirement, Technical Requirement still need to be improved/clarified
McCool: so far the description is about what, and need to describe how as well
Ege: agree
… these are basically about functional
… I'm OK with the direction
… starting with abstract and think about details next
… would be better to describe as detail as possible when we generate Use Cases
… Technical Requirements should be handled by the UC TF
Kaz: can be done collaboratively with the spec TF guys
… but we need some more discussion
McCool: we should start with capturing what is needed first
… would be nice to write done concrete requirements for discovery and security
Kaz: yeah, we can continue the discussion based on Mizushima-san's example
Ege: maybe we can have a Hackathon to clarify the procedure
Kaz: sounds good :)
[adjourned]