RE: Structure of use cases

Alberto,

I won't want at this stage to get too formal about the use case process.
There is as much an exchange of experiences and views amongst group members
going on as a formal requirements before design phase.  Having used one such
process in the past, I found it good but had to bend it a bit because there
wasn't a fixed software item to build nor a single notion of the customer.
We'll refine the process as we have an increased sense of what we need from
it.

Adding a use case name to the text seems a good idea for later processing.
Subject lines don't get included in cut-and-paste.

I didn't under the need for a "scale" axis.  As a W3C working group, isn't
it "the web" as far as requirements extraction goes.  The charter says:
  """
  The principal task of the RDF Data Access Working Group is to gather
  requirements and to   define an HTTP and/or SOAP-based protocol for
  selecting instances of subgraphs from an RDF graph.
  """
but that should not exclude being sensible about use of the access language
over JDBC even if not in scope.  So I don't see it as a mandatory section in
a use case.  Below, I have pushed all the optional stuff under "other" as
when we come to analysis the use cases this material can only be
informative.

----
== Use Case Name
	--> identifier/name of the solution

== Intent: Task & Roles
      --> Who is doing what, and why

== Description 
      --> of the solution

== Key Benefits / Value
      --> of a solution by this WG over other approaches, or custom coding.

== Other
      Optional: this section is used to ensure material is not lost.
      Typically not part of the process of extracting requirements.
      --> notes and further comments.
      --> related solutions
      --> examples
      --> scale/applicability
----


-------- Original Message --------
> From: Alberto Reggiori <>
> Date: 11 March 2004 18:34
> 
> 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 Friday, 12 March 2004 09:04:15 UTC