The idea of clarifying the distinction between ' Functional requirements section and the  platform services are is 
accepted. They are essentially different and are both needed in the use case document. But this difference is not well 
explained.   Text was added to the document to clarify the differenct sections of each use case ( describing the 
template so to speak ) in the introduction. This is given below as well

' 
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 customer' 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 you have more than one, list up all major 
scenarios in this section. Figures are included as appropriate.
Following this is the section Involved resources'. This explains the resources managed and provided by the Grid system 
in this use case. Geographical distribution and scale of resources can also be mentioned here.  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 Function requirements, they are different.  
This section proposes capabilities and services of the OGSA based grid and how they will be used, and is inherently 
linked to the OGSA architecture document (taxonomy of services for example).  Functional Requirements on the other hand 
is independent of the 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 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. In this section a discussion of services 
relevant to the use case which are already there is done.  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 referencing. 
While these use cases have certainly not been defined with a view to expressing formal requirements (and do not contain 
the level of detail that would be required for formal requirements), they have provided useful input to the definition 
process. We expect to expand the number of use cases in future revisions of this document. 
'