[HOME_NETWORK_TF] Use cases "format"

Hi all,
during yesterday call we discussed a bit about how the how a use case  
description should look like, since we have got really different "styles"  
of usecases and is good if we converge on one way of writing them down.

First of all we agreed to split the document in 2 parts:
- a first part with high level usecases (discovery, expose services etc);  
I'll take care of this part and try to write it down in the next days  
based on some of the usecases and discussions we had so far.
- a second part with more user centric and detailed usecases with the aim  
of underlining which one are the "services" or which interaction scenarios  
we foresee as most important to support.

For this second part we discussed different approaches and I've been  
looking myself to existing documents to have an idea of how it could look  
like.
Actually, if you check the W3C archive (http://www.w3.org/TR/) for  
Usecases documents, you will find out that there are huge differences in  
format between different documents. So there seems to be no uniform  
template. This means, we should chose the format we believe is appropriate  
for our case.

Going through these documents, I identified some that are close to the  
idea I have in mind as template, I'm posting them here for reference.
Let me know what do you think and feel free to propose something  
different; Let's try to converge on one template quickly, so that people  
can conform to it when writing usecases.


1.  
http://www.w3.org/TR/2007/NOTE-grddl-scenarios-20070406/#scheduling_use_case
2. http://www.w3.org/TR/2009/WD-media-frags-reqs-20091217/#use-cases
3. http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#interactions
4. http://www.w3.org/TR/2002/NOTE-mmi-use-cases-20021204/
5. http://www.w3.org/TR/2007/NOTE-powder-use-cases-20071031/#usecases
6. http://www.w3.org/TR/2007/WD-xhtml-rdfa-scenarios-20070330/#use-case-1
7. http://www.w3.org/TR/2008/WD-rif-ucr-20081218/#Use_Cases




If we have to pick one of these, I would probably go for #3 where you have
- a story (user centric, easy to understand)
- analysis (with additional comments and considerations, if any)
- requirements (which requirements are related to that usecase; can be  
written at a later stage)


Igarashi mentioned a step-by-step description; if we want to go for that,  
maybe something like #5 above could be suitable. I still prefer the #3  
approach though.


Thoughts?

/g






-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Wednesday, 25 May 2011 10:28:57 UTC