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.
Most important thing for this work is to point out the meaning of application scenario and use cases.
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.

Thank you.

Best regards,


> -----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 02:28:28 UTC