D-AG0012 Use Cases

This email kicks off discussion of D-AG0012, which now states

-  identify or create the use cases that validate the requirements and the 
web services architecture and illustrate the benefits of web services.

Proposal:
- identify or create a set of usage scenarios that are drawn from a broad 
set of W3C members and relevant liaison organizations, and can be mapped to 
WS Architecture requirements.

Discussion

I suggest we use the term "usage scenario" rather than use case.  XMLP WG 
had a discussion of this distinction when it was doing the same thing for 
its requirements document.  Basically, use cases (e.g., UML) are something 
more structured and oriented to software design.  Usage scenarios are less 
structured, and perhaps more abstract to illustrate broad architectural 
concepts.

The goal for the WSAWG and the architecture document should be to address a 
broad set of applications reflecting the diversity of the W3C membership as 
well as the organizations that we have identified as important liaisons 
(OMG, OASIS, etc.)

There should be a mapping between usage scenarios and requirements for the 
web service architecture document.  I'm not sure we want a usage scenario 
to actually be the requirement.  I think there is a difference between a 
requirement and a usage scenario.

The benefit of web services should be obvious from the usage 
scenarios.  The architecture document introduction will probably talk about 
the benefits of web services.  I would rather keep the usage scenarios 
short and not add the text that would be needed to explicitly state the 
benefits of each scenario.

In what way does a usage scenario validate a requirement?  The form of a 
requirement will be "The web services architecture shall ..."

For example, "... shall define a way to describe web services".  A related 
usage scenario might be "a web service provider publishes a description of 
its web service, and a web service user reads the description to determine 
how to invoke the web service."  This requirement is derived from the usage 
scenario, so in a sense the requirement is valid because it relates to a 
usage scenario.  If a requirement cannot be traced back to a usage 
scenario, then we can consider it invalid (or perhaps we would need to 
figure out a usage scenario for it).  So, it would be a requirement of the 
requirement document to include a matrix showing the traceability between 
requirements and usage scenarios.  We would then need to have traceability 
between the architecture document and each requirement in the requirements 
document.

I am not familiar enough with the CSFA method to know how it views usage 
scenarios versus requirements.

Requirements
(to be determine)

Several efforts related to web services have worked on usage scenarios:

XMLP WG
http://www.w3.org/TR/xmlp-scenarios/

WSDWG
http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0097.html
http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0115.html
http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0123.html
http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/0090.html

OASIS WSIA
https://www.oasis-open.org/committees/wsia/scenarios/index.shtml
http://lists.oasis-open.org/archives/wsia/200203/msg00046.html

OASIS SSTC
http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-reqs-01.pdf

OASIS XACML
http://lists.oasis-open.org/archives/xacml/200112/msg00038.html
http://lists.oasis-open.org/archives/xacml/200112/msg00045.html
http://lists.oasis-open.org/archives/xacml/200203/msg00024.html
http://lists.oasis-open.org/archives/xacml/200202/msg00061.html

Others?

Critical Success Factors (CSF)
(to be determined)



Paul

Received on Thursday, 28 March 2002 17:55:14 UTC