11:58:41 RRSAgent has joined #wot-uc 11:58:46 logging to https://www.w3.org/2024/02/21-wot-uc-irc 11:58:46 meeting: WoT Use Cases 11:59:07 chair: Mizushima 11:59:20 present+ Kaz_Ashimura, Tomoaki_Mizushima, Michael_Koster 12:02:59 luca_barbato has joined #wot-uc 12:03:28 present+ Luca_Barbato 12:03:35 mjk_ has joined #wot-uc 12:03:48 present+ Ege_Korkan 12:04:14 scribenick: kaz 12:04:34 agenda: https://github.com/w3c/wot-usecases/blob/main/TODO/20240221.md 12:04:41 topic: Updated plan 12:04:56 Ege has joined #wot-uc 12:04:56 mizu: 2 weeks ago, proposed a plan 12:04:59 mahda-noura has joined #wot-uc 12:05:14 ... but would like to update it based on the discussion on Feb 7 12:05:28 [[ 12:05:29 Feb-21 (today): Clarify Functional Requirements and Technical Requirements using some specific example(s) 12:05:29 As a result, we should be able to get insights on possible templates for the following: 12:05:29 Use Cases 12:05:29 Functional Requirements 12:05:29 Technical Requirements 12:05:30 McCool has joined #wot-uc 12:05:31 Feb-28: Fix basic templates for Use Cases, Functional Requirements and Technical Requirements 12:05:33 Mar-6: start concrete work on Ues Cases, Functional Requirements and Technical Requirements 12:05:35 ]] 12:05:45 present+ Mahda_Noura 12:05:55 present+ Michael_McCool 12:06:05 mizu: is that ok? 12:06:21 q+ 12:06:30 ack k 12:06:40 kaz: I'm OK if that's feasible :) 12:06:50 (no objections; updated plan approved) 12:07:06 topic: Minutes review and GitHub Issue creation 12:07:18 -> https://www.w3.org/2024/02/07-wot-uc-minutes.html Feb-7 12:07:23 mizu: (goes through the minutes) 12:07:55 ... discussion on Issue 257 12:08:16 ... continue the discussion about "Functional vs Technical Requirements" 12:08:29 ... also additional 6 Issues derived from Issue 257 12:09:01 q+ 12:09:16 ack k 12:09:45 ... then discussed how to deal with Use Cases and Requirements 12:09:57 ... various opinions from the participants 12:10:06 ... summary is: 12:10:15 ... Need for sepration between Use Cases and Requirements so that we can describe the many to many mapping between Use Cases and Requirements 12:10:28 ... Need to clarify possible 2 levels of Requirements needed 12:10:35 ... Need to clarify them based on concrete example descriptions 12:10:38 q? 12:10:47 ... are the minutes OK? 12:10:52 (no objections) 12:11:00 minutes approved 12:11:19 mizu: then the above summary of the discussion approved? 12:11:23 q? 12:13:16 q+ 12:13:24 q+ 12:13:24 ack k 12:13:34 (no objections) 12:14:06 mizu: so the discussion points have been approved 12:14:52 topic: Clarification of Functional Requirements and Technical Requirements 12:15:26 mizu: Given the discussion on Feb-7, I think this topic, Functional Requirements and Technical Requirements, is very important 12:15:35 ... so would like to continue the discussion 12:15:48 ... would start with some basic definition 12:15:54 [[ 12:16:02 q+ 12:16:06 "Functional Requirements" are extracted from the Use Case descriptions, and to be included in the "WoT Use Cases and Requirements Note". 12:16:06 That implies that the Use Case descriptions need enough information for the Use Cases TF to extract "Functional Requirements". 12:16:07 ]] 12:16:13 q? 12:16:16 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. 12:16:16 That implies that the "Functional Requirements" need enough information for the specification TF to generate "Technical Requirements". 12:16:17 ]] 12:16:27 +1 on that it is not a definition 12:16:44 mm: this is not a definition itself, but how the document should do 12:16:48 q+ 12:17:14 ... however, rather than trying to make the definition clear, we should just capture the requirements 12:17:33 ... and see which ones are "Functional" and which ones are "Technical" 12:18:26 ... simply requirements first, then categories, for example 12:18:34 ack mc 12:19:20 ek: agree with McCool 12:19:27 ... this is not "definition" itself 12:19:40 ... also agree we don't really need definition 12:19:55 q+ 12:20:03 ... we should have examples rather than strict definition here 12:20:23 q+ 12:20:24 ... also we can have a look at my proposed Issue, etc. 12:20:27 ack ege 12:21:25 kaz: agree 12:21:57 ... and I think what Mizushima-san wanted to is rathr "what we need to do" or "roles" here 12:22:07 ... rather than exact definition 12:22:14 mm: agree 12:22:23 q- 12:22:28 ack k 12:22:36 ack m 12:22:57 kaz: so let's simply change the title from "Basic definition" to "What we need to do" hre 12:23:01 s/hre/here/ 12:23:20 present+ Kunihiko_Toumura 12:23:31 zakim, who is on the call? 12:23:31 Present: Kaz_Ashimura, Tomoaki_Mizushima, Michael_Koster, Luca_Barbato, Ege_Korkan, Mahda_Noura, Michael_McCool, Kunihiko_Toumura 12:23:31 s/... also we can have a look at my proposed Issue, etc./I would prefer to have PRs created before the call so that I can have a calm time reading them. 12:23:54 rrsagent, make log public 12:23:59 rrsagent, draft minutes 12:24:01 I have made the request to generate https://www.w3.org/2024/02/21-wot-uc-minutes.html kaz 12:24:08 q+ 12:25:05 ack k 12:25:21 (basic roles on what to do approved) 12:25:35 subtopic: Concrete example 12:25:48 mizu: would like to start with an example of a smart home 12:26:23 ... the results from this discussion should be useful for template discussion as well 12:26:43 s/subtopic:/topic:/ 12:26:49 subtopic: Use Cases 12:27:03 -> https://w3c.github.io/wot-usecases/#smart-home UCR document 12:27:30 mizu: 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. 12:27:42 ... how should we describe that kind of use case? 12:28:05 ... the current use case template has: 12:28:12 q+ 12:28:16 [[ 12:28:18 Submitter 12:28:20 Target Users 12:28:22 Motivation 12:28:24 Expected Devices 12:28:26 Expected Data 12:28:28 Dependencies 12:28:30 Description 12:28:32 Security Considerations 12:28:34 Privacy Considerations 12:28:36 Accessibility Considerations 12:28:38 Internationalization Considerations 12:28:42 Gaps 12:28:44 Existing Standards 12:28:46 ]] 12:28:50 mizu: are those enough to extract "Technical Requirements" later? 12:28:52 q+ 12:29:53 ... also how should we deal with considerations on security, privacy, accessibility and internationalization? 12:30:11 ktoumura has joined #wot-uc 12:31:42 subtopic: Functional Requirements 12:31:55 mizu: 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 12:32:18 subtopic: Technical Requirements 12:32:29 mizu: WoT Thing Description should handle the air conditioner and the air purifier as if they were a one single device. 12:32:39 ... For that purpose, a TD can describe a virtual device, an air conditioner with air purifier capability, and then export it to the Consumer. 12:32:53 ... The Consumer can handle the exported virtual air conditioner via that TD. 12:33:02 ... The WoT Discovery also needs to let a Consumer discover a virtual device based on that TD. 12:33:28 subtopic: Discussion 12:33:38 mizu: Use Case is the first work 12:33:43 q+ 12:33:56 ... so would start with Use Case here 12:34:13 ... then Functional Requirements 12:34:21 ... then Technical Requirements 12:34:40 ek: thanks for providing this concrete example 12:35:27 ... the question here is if the information within the Use Case template enough for requirements extraction 12:35:48 ... we generally would like to have knowledge about that here 12:35:55 ... then 12:36:16 ... Functional Requirements should be provided by the Use Case submitters themselves 12:36:23 ... also 12:36:38 ... if there is no Gap with the existing standards, we can simply go ahead 12:38:23 kaz: tx from me too 12:38:34 ... the example seems OK to me 12:39:01 ... only one comment is extracting not only "Technical Requirements" from Use Cases 12:39:13 ... but also "Functional Requirements" 12:39:24 ... so both Functional Requirements and Technical Requirements 12:39:44 ... then as Ege also was wondering, who/how to extract the requirements? 12:40:03 ... collaboration with the use case submitters for functional requirements 12:40:20 ... collaboration with the spec TFs for technical requirements 12:40:27 ... but those points are for the next step 12:40:33 ack k 12:40:34 q? 12:40:35 ack e 12:41:03 mm: all the above related to both the Functional Requirements and Technical Requirements 12:41:24 ... this use case can be worked with ECHONET who are still active 12:41:56 ... regarding the gaps, requirements from ECHONET APIs with WoT APIs 12:42:25 ... actual analysis to be done to clarify the Technical Requirements 12:42:26 q+ 12:42:31 qq+ 12:42:38 ack mc 12:42:51 ... so need to add further details 12:43:18 ... we should have some criteria to see if the requirements are satisfied 12:43:38 ek: in this case, we can see the gaps with their standards 12:43:56 ack e 12:43:56 Ege, you wanted to react to Ege 12:44:26 s/Ege, you wanted to react to Ege// 12:45:17 mm: requirements need to be confirmable 12:45:19 q? 12:46:38 q+ 12:46:50 ack m 12:47:11 q+ 12:47:25 ack m 12:47:28 ack k 12:47:55 kaz: let me summarize the discussion so far 12:48:05 ... we're OK with Mizushimas-san's proposed direction 12:48:09 q+ 12:48:33 ... displayed example on grouping of devices is fine 12:49:13 ... but all the three items, Use Case, Functional Requirement, Technical Requirement still need to be improved/clarified 12:49:59 mm: so far the description is about what, and need to describe how as well 12:50:09 ack e 12:50:14 ek: agree 12:50:25 ... these are basically about functional 12:50:37 ... I'm OK with the direction 12:50:49 ... starting with abstract and think about details next 12:51:13 ... would be better to describe as detail as possible when we generate Use Cases 12:51:22 q+ 12:53:04 q+ 12:54:39 ... Technical Requirements should be handled by the UC TF 12:54:54 kaz: can be done collaboratively with the spec TF guys 12:55:03 ... but we need some more discussion 12:55:29 mm: we should start with capturing what is needed first 12:56:16 ... would be nice to write done concrete requirements for discovery and security 12:56:17 q+ 12:56:20 ack m 12:56:22 q+ 12:57:23 kaz: yeah, we can continue the discussion based on Mizushima-san's example 12:57:28 q+ 12:57:30 ack k 12:57:31 q+ 12:58:45 ack e 12:59:05 ek: maybe we can have a Hackathon to clarify the procedure 12:59:48 ntd 13:00:36 kaz: sounds good :) 13:00:40 s/ntd// 13:00:43 [adjourned] 13:00:48 rrsagent, draft minutes 13:00:49 I have made the request to generate https://www.w3.org/2024/02/21-wot-uc-minutes.html kaz 13:02:16 rrsagent, make log public 13:02:20 rrsagent, draft minutes 13:02:21 I have made the request to generate https://www.w3.org/2024/02/21-wot-uc-minutes.html kaz 13:06:19 brb