Re: Structure of use cases

On Mar 11, 2004, at 5:48 PM, Seaborne, Andy wrote:

>> Could you (or somebody...) flesh this example out a bit? Tell me
>> more about the user... are they trying to find John Smith's
>> email message to send them email? Or are they trying to bust
>> John Smith for some crime? Or invite him to a party?
>
> No problem - can do.

As a start, I feel like we need here some more general 
architectural/analysis use-case view of the "problem", more "domain 
modeling" alike, more analysis/enterprise patterns like [1][2] and less 
RDF technical/design specific patterns/choices for the moment. This 
would help each stakeholder to easily pickup the idea/problem we 
want/need to solve and collect user-requirements which might be come 
from a specific biz case, scenario or application. Better if such 
requirements are coming from some real-world Web application or service 
out-there, or some already deployed technology. Having then specific 
examples/scenarios using specific query-languages and design choices 
would then help to complete the picture. At the same time it is 
important we strategically choose those use-cases/scenarios where RDF 
is actually best suited for e.g. merging/aggregation, co-relation, 
federation/decentralization - which would actually show the real 
benefits of our technology vs. others.

OR do you feel we need to address more lower level design-pattern style 
use-cases from the start?

> Might be useful to discuss use cases at a general level as well hence 
> this
> thread. Are we moving towards a use case having the structure (quick 
> draft):

yes - I would like to see a much more architectural level 
patterns/use-cases at the beginning - I will try to post some 
example(s) in the next days with some ideas

>   Description/Context:
>
>   Audience: (e.g. application, user, toolkit developers, ....)
>
>   Value/Why:
>
>   Implications:
>     Technical discussion
>
>   Other:
>     General notes - to ensure they don't get lost.

I would add or modify the list above with:

Label/Name:
	--> identifier/name of the solution

Abstract/Intent:
	--> simple description/outline of the use-case/scenario

Applicability/Scale:
	--> e.g. Internet, Intranet, RDBMS databases etc.

Key Benefits and Consequences:
	--> why is better (or worse) e.g. the client does not have to... or 
has to...

Related solutions:
	--> some reference to other similar approaches/technologies and why 
this is better or worse

Example:
	--> sample scenario using perhaps some simple/example dataset and 
query syntax

> The structure can't be too long and I think each section must be 
> completed
> for all use cases (that is, no sections that work for only half of the 
> UCs -
> hard to evaulate systematically later).

each section/use-case should be completed with some 
examples/implementation meat and perhaps sample datasets in RDF, XML or 
CSV - perhaps taken from the Web directly - i.e. proof we can really 
"query the Web" in some sort of sense

> Any one what to add/refine/alter etc this list?  What experience is 
> there of
> using these?

I think RDF technical/design specific cases are important, but not at 
this early stage - we should try to focus on some more general 
architectural design of our problem-domain

but this is my personal feeling/view of it - you can disagree :)

cheers

Alberto


[1] http://martinfowler.com/eaaCatalog/
[2] 
http://www.amazon.com/exec/obidos/ASIN/0321127420/102-7799351-2147319

Received on Thursday, 11 March 2004 13:33:44 UTC