RE: [use cases] writing styles

I have modified my proposed template as your point and also added follow UC.

https://www.w3.org/WoT/IG/wiki/Use_cases_template


Best Regards,

--- Jonathan Jeon

From: Heuer, Joerg [mailto:Joerg.Heuer@siemens.com]
Sent: Friday, March 06, 2015 7:54 AM
To: Dave Raggett; Public Web of Things IG
Subject: AW: [use cases] writing styles

To sync the writing styles we might try to put forward some key questions to answer by the use cases. This might also provide some initial structuring and helps by reflecting what aspects we would like to consider for WoT technologies.

The following questions came to my mind:

I) What is the user motivation for the use case
II) How does this translate to a technical Description
III) What application domains are related (e.g. referring to the taxonomy)
IV) What interaction pattern with or btw things can be observed
V) Which Aspects are not considered

Do you have further questions or alternatives?

The questions above fits also quite well with what is contained in Dave’s example and corresponds to some categories which are proposed in the template by Jonathan.
To understand how this would look like I picked the use case described by Dave. Find his example formatted along the mentioned questions below:

---- 8< cut here ----

-------
What is the user motivation for the use case
-------
Joan has a heavy load of washing to do. She decides to run it over night to take advantage of the lower power prices. She loads the clothes into the washing machine and selects the economy operation mode.  She has previously set her preferences with her home automation agent that is accessible on the Web from her phone, tablet, TV or laptop.

-------
How does this translate to a technical Description
--------
The physical user controls on the washing machine are deliberately simple, and designed to work in conjunction with the web based home automation agent. This agent has access to Joan’s electricity supplier and as is able to track the price charged by her supplier on her electricity plan as it changes according to demand across the city. The agent runs in the cloud, but is able to communicate through the firewall with devices in Joan’s home via her home hub. This was set up automatically when she first plugged the machine in. The washing machine has a very limited embedded controller. It suffices to run the desired washing and drying cycle, and has sensors that monitor its operation and enable components that are wearing out to be detected before they fail. Joan has agreed to share this data with the manufacturer as part of the warranty agreement.  In return, she gets proactive scheduling of service visits at her convenience.

-------
What application domains are related (e.g. referring to the taxonomy)
-------
main: smart home / home automation / deferred operation
related: smart cities / smart grid / signaling with smart power devices

-------
What interaction pattern with or btw things can be observed
-------
Thing registers: thing registers with service in the cloud
Configure data subscription: specific data field (e.g. for maintenance) is forwarded (e.g. to manufacturer)
Thing integration in web based agent

-------
Which aspects are not considered
-------
Life cycle of devices, services and applications
Discovery of devices
Installation process
Dealing with faults
Replacing devices
Taking devices out of operation

---- 8< cut here ----



BR,
Joerg


Von: Dave Raggett [mailto:dsr@w3.org]
Gesendet: Donnerstag, 5. März 2015 16:26
An: Public Web of Things IG
Betreff: [use cases] writing styles

The Web of Things Interest Group aims to identify what new web technology standards will be needed to enable open markets for apps and services for the Web of Things. To help us realise that aim, the plan is to survey application domains and practices.  A key part of this is coming up with use cases that illustrate the purpose and functionality of a given application or service.  We can then analyse these use cases to identity common patterns as a basis for identifying requirements that apply across application domains.

Given that we have a wide range of application areas, we need to make it easy to come up with the use cases in the first place.  We can later refine the ones we feel justify a greater level of detail and structure. There are lots of different ways to write use cases, so it makes sense to see if we can all agree on a consistent approach as this will make it much easier to compare and contrast use cases.

Use cases were first introduced by Ivar Jacobson in the late 1960’s while he was working on telephony systems at Ericsson. They have since become a popular tool as part of the requirements generation process.  There is a tendency to introduce a very formal structure, but this makes it much harder to come up with the use cases in the first place.  I therefore recommend that we initially focus on simple narratives from a user’s perspective that avoids technical details. These should be supplemented by brief explanatory notes.  My aim would be for us to publish a Interest Group Report that contains many such use cases grouped according to the application domains they belong to. We would follow this up with a separate document that takes a more structured approach to analysing the use cases and identifying the functional requirements that they imply along with the assumptions that have been made.

So to explain what I mean, here is an example of a use case for home automation:

---- 8< cut here ----


  *   Joan has a heavy load of washing to do. She decides to run it over night to take advantage of the lower power prices. She loads the clothes into the washing machine and selects the economy operation mode.  She has previously set her preferences with her home automation agent that is accessible on the Web from her phone, tablet, TV or laptop.

The physical user controls on the washing machine are deliberately simple, and designed to work in conjunction with the web based home automation agent. This agent has access to Joan’s electricity supplier and as is able to track the price charged by her supplier on her electricity plan as it changes according to demand across the city. The agent runs in the cloud, but is able to communicate through the firewall with devices in Joan’s home via her home hub. This was set up automatically when she first plugged the machine in. The washing machine has a very limited embedded controller. It suffices to run the desired washing and drying cycle, and has sensors that monitor its operation and enable components that are wearing out to be detected before they fail. Joan has agreed to share this data with the manufacturer as part of the warranty agreement.  In return, she gets proactive scheduling of service visits at her convenience.

---- 8< cut here ----

The more detailed analysis would provide technical accounts of all aspects of the use case and the roles of the actors involved. For example, the washing machine could use a variety of communication technologies. The home hub needs to support these directly or via additional device gateways.  A pairing operation is needed to bind the washing machine’s virtualisation as a web object to the physical device. This is analogous to binding a web identity for a user account on a website to that user’s real world identity.

We need to cover the lifecycle for devices, applications and services, rather than just their regular use. This is important for considerations like discovery and installation, as well as dealing with faults and taking devices out of service.

I will send a separate email covering ideas for an initial taxonomy for use cases.

p.s. you are encouraged to submit use cases by email to this list with the prefix [use cases] for the subject field of the email.

—
   Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>

Received on Friday, 6 March 2015 01:18:15 UTC