Re: Use case & requirements document structure

Hi Felix, Wonsuk, all,

This way of reorganising the use case and requirements sections (these two would 
be merged or kept separate in your opinion?) in the fashion described below is 
fine with me, having the shortest and "most up to the point" document possible 
is a good option! So, if I understand correctly, the application scenarios would 
be related to the now called tasks, which become use cases, from which a set of 
requirements are drawn. What would be the relationship between the scenarios and 
use cases? I mean do we list the whole set of use cases after each scenario, 
knowing that some use cases would then be duplicated at different parts, or do 
we describe the scenarios and the use cases separately, or the scenarios as 
examples illustating the use cases?
I also vote for leaving the ambiguous question of context out of the use cases 
description, but should I also leave it out of the introduction+top-down-
modelling-approach merdged part?

Best regards,
Veronique

Quoting Felix Sasaki <fsasaki@w3.org>:

> 
> Hi Veronique, Wonsuk, all,
> 
> I have started working on a proposal for the structure of the use case & 
> requirements document. Looking at the material I am wondering if we can 
> re-organize it:
> - What is currently called "use cases" are mostly application scenarios.
> - What is called "tasks" are what I would call use case.
> - To be able to execute a task, you need to fulfil certain requirements.
> 
> An example: There is the "cultural heritage" application scenario. In 
> that scenario, there is the use case of "accessing collections of 
> metadata". For this use case we may have the requirement that the 
> ontology allows for multiple description levels.
> 
> Another example: assuming a "developing web applications " application 
> scenario, there is the use case to have read access in an API for meta 
> data across different formats. For this use case, there is the 
> requirement to have an API to allow for read access across formats.
> 
> I think for what is currently in the "recommendations across different 
> media types" application scenario, we have a similar use case: read 
> access meta data across different formats, to be able to create the 
> recommendation.
> 
> If we follow this path, we probably do not need the "video application 
> scenario", since it is too general, and it's enough to keep the tasks 
> which are in that section, and call them "use case".
> 
> For the mobile application scenario, we have the use case of accessing 
> location based information and the requirement to achieve 
> interoperability between different ways to convey this information.
> 
> Background for this proposal is that the questions which I gathered from 
> Rubin's "ontology feature" page and the mailing list
> http://www.w3.org/2008/WebVideo/Annotations/wiki/Meeting_Agenda_Ghentf2f_2008
> All seem to map into requirements, and these easily relate to what is 
> currently called "tasks", but are probably rather "use cases".
> 
> If we agree on this proposal I can create a template for use case 
> (currently "task"), requirements and application scenario description. 
> Note that in this approach there is not necessarily a 1:1 relation 
> between use cases and requirements.
> 
> I know that this proposal does not take Veroniques re-organization 
> proposal at
> http://lists.w3.org/Archives/Public/public-media-annotation/2008Nov/0053.html
> into account. And probably it is difficult to agree on this soon and via 
> mail, but let's try. For what it's worth, I have similar problems as 
> Veronique to understand the notion of context, and I have more and more 
> the impression it does not hurt to leave it out of the picture. Also, I 
> think the large amount of material in the current draft are due to the 
> fact that lots of descriptions are specific to aplication scenarios. For 
> our work, we probably don't need these, but shorter descriptions of use 
> cases (currently tasks) and requirements.
> 
> Felix
> 
> 
>

Received on Thursday, 20 November 2008 12:19:27 UTC