Re: Use case & requirements document structure

vmalaise@few.vu.nl さんは書きました:
> 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?)

separate, IMO, since we have n:n relations between them. 



>  in the fashion described below is 
> fine with me, having the shortest and "most up to the point" document possible 
> is a good option! 

Great :)

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

Yes, that's the idea.

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

I would descripe them seperately

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

> I would propose to do that, yes.


Felix



> 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 22:13:12 UTC