[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>>