RE: Use case & requirements document structure


> From: Felix Sasaki [mailto:fsasaki@w3.org]
> Sent: Friday, November 21, 2008 12:40 PM
> To: 이원석
> Cc: public-media-annotation@w3.org; Véronique Malaisé
> Subject: 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.
> 

Yes. I agree.
but we have to list up the their own use cases based on the application scenarios.
And then we can describe normalized use cases separately. :-)

> 
> > 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:
> http://www.w3.org/2008/11/18-mediaann-minutes.html

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

I will try to do that.
But I could do this until late this week or early next week,
Because I should finish some things for my company in this week.

Wonsuk.

> Felix
> 
> > Thank you.
> >
> > Best regards,
> >
> > Wonsuk.
> >
> >
> >> -----Original Message-----
> >> From: Felix Sasaki [mailto:fsasaki@w3.org]
> >> Sent: Thursday, November 20, 2008 4:45 PM
> >> To: Véronique Malaisé; 이원석
> >> Cc: public-media-annotation@w3.org
> >> 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
> >>
> http://www.w3.org/2008/WebVideo/Annotations/wiki/Meeting_Agenda_Ghentf2f_2

> >> 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
> >> 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 Monday, 24 November 2008 07:37:37 UTC