[Risge-rg] Use cases template

[Constantinos (Costas) Kotsokalis]

Dear group,

As said some time ago, we must define the template based on which we  
will describe our model use cases. By model use cases, I refer to the  
least common denominator of the particular/individual use cases we  
will collect or have collected. It was a proposition at that time to  
use the OGSA Use Cases template, so I  am copying its description  
below for review and comments. If people think that it must be  
extended somehow in our case, please let the list know.

==========================================================

Each use case is structured for analysis towards separating the  
architectural requirements for
creating an OGSA architecture specification. Hence the structure of a  
use case is as follows.
Each use case starts with a ‘Summary’ description that outlines the  
content and scope of the use
case. This is followed by a ‘Customers’ section where the customers of  
the use case and their
needs are described. This section also contains things like where and  
how the use case occurs
"in nature" and for whom it occurs. It provides an abstract scenario  
description to explain
customers’ needs. Specifics on scale are important too. For example:  
How many users are
expected for this use case?  The next section is called ‘scenarios,”  
and explains the primary
scenarios of this use case. If there are more than one, all the major  
scenarios are listed in this
section. Figures are included as appropriate.

Following this is the section ‘Involved resources.’ This explains the  
resources, their scale and
geographical distribution that are managed and provided by the Grid  
system in this use case.
Following this is the section ‘Functional Requirements for OGSA.’ The  
information in here goes
into creating the master list for requirements of the OGSA  
architecture.  When in doubt whether a
requirement is functional or not, such non-functional requirements of  
OGSA can also be identified
here.  Following this is the section ‘OGSA capabilities and services  
utilization.’  While this
might look in practice to be very similar to the earlier section on  
Functional requirements, they are
different.  The functional requirements section is linked to Chapter 2  
(Requirements) of the
architecture document. On the other hand, the capabilities and  
services section is inherently
linked to Chapter 3 (Taxonomy) and Chapter 6 (Services) of the OGSA  
architecture document.
Terminology similarity is only because some requirements directly  
translate to services or other
such constructs in the architecture document.

The next sections are called ‘Security considerations’ and  
‘Performance considerations,’ and
they call out these two non-functional requirements that are important  
for most use cases.  They
give a better idea of the use case environment of execution.   
Following this is the ‘Use case
situation analysis’ section. This section includes a discussion of  
services relevant to the use
case which are already there.  Explanations as to what extent they are  
satisfactory or
unsatisfactory, and an articulation of what extensions are needed, are  
also included.   Finally a
‘References’ section is included for the reader seeking more details  
and references.

==========================================================

Of course, we can use the same template (or not) for the individual  
use cases. This is up for discussion as well; Please let's try to get  
the basics out of the way, and use Boston time to focus on the finer  
details.

Best,

  Costas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/risge-rg/attachments/20080122/1838b8f0/attachment-0001.html