Re: Use case & requirements document structure

이원석 さんは書きました:
> Hi Felix, Veronique, all.
> I fully agree with this proposal.
> I think proposed style could clearly enhance the whole description of our draft.
> But we should elaborate the description of application scenarios and their own each use cases(now called task) as well.

I think it is important not to say "their own each use cases(now called 
task)", but rather "their *related* use cases(now called task)". The 
reason: some or even many use cases are relevant for several application 
scenario. Below I gave an example of the "having read access cross 
metadata" use case, which is relevant for actually all "culturul 
heritage", "web application" and "recommendation" application scenario.

> Most important thing for this work is to point out the meaning of application scenario and use cases.

I think application scenarios, use cases and requirements are of equal 
importance, and we will and have not work in a sequential order like
1) thinking of application scenarios
2) creating use cases from 1)
3) creating requirements from 2)
rather, we are working in paralell, and need to check all three parts 
constantly for consistencey with the others.

We had a related discussion at the last call:

Werner: we need a better dfinition of what is expected from the use 
cases in terms of requirements
Felix: two approaches are possible.. define use cases very clearly.. and 
define requirements and level of complexity.. other choice is starting 
from existing ontologies.. and define what complexity is needed in them
... we need to decide if we want the sequential approach: use case -> 
requirements -> api
... or work in parallel
Werner: the idea is not to create the ontology to cover all the needs 
from the use cases
... but check out the requirements and models that are relevant for more
... these will have more impact

> Because these will be used to make the requirements and links between use cases and requirement. Also we can find out which requirement is more important than others based on these information.

Agree. And I think the current use cases and requirements draft has a 
lot of good material, but not clearly separated.

Veronique, Wonsuk: is the information in this thread enough for you to 
try to make this separation? Since it means a complete re-organisation 
of the document, it is maybe better to do that now instead of 
implementing the current comments on the draft, or getting back to the 
authors of the use cases / requirements.


> Thank you.
> Best regards,
> Wonsuk.
>> -----Original Message-----
>> From: Felix Sasaki []
>> Sent: Thursday, November 20, 2008 4:45 PM
>> To: Véronique Malaisé; 이원석
>> Cc:
>> Subject: Use case & requirements document structure
>> 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
>> 008
>> 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
>> 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 Friday, 21 November 2008 03:40:28 UTC