RE: Business Requirements

["Nieman, Scott" <Scott.Nieman@norstanconsulting.com>]

The documents referenced are far from being use cases or scenarios, but
input into what will be use cases.  UML describes use cases as who and what
will access the "system" (in this case the registry and repository), and the
scenarios are unique "paths" through a use case or technically "instances of
a use case".  This is EXACTLY the "context" point you make, Terry, as we
need to drill into these requirements to define who, what, when, why, how,
and where the user (person or application) looks or stores information into
the repository.

This is the clip from David email (getDTD) that I like, since it uses
classic 'getters' and 'setters' syntax.  

<MessageRouting> 
  <to>repository</to> 
  <from>me</from> 
  ... 
</MessageRoutine> 
<repositoryRequest> 
  <getDTD> 
      <id>xxx/xxx/xx/someName.dtd</id> 
      <version>234346</version> 
  </getDTD> 
</repositoryRequest> 


I prefer not to get into this level of detail until we get the requirements
knocked out, since we could debate for days on whether the
<repositoryRequest> tag is really an element, or whether it should be an
attribute of <MessageRouting>; e.g., <MessageRouting
type="repositoryRequest">.

How can I get the UML pages to everyone?  I could zip up, and email to the
list, and have everyone extract and view with a java and frames capable
browser.  Is that OK?  It extremely early its stages, but I think the time
is now to see the "pictures".  There are no classes except for the actors so
XMI encoded information is extremely limited.

Regards,

Scott

-----Original Message-----
From: Terry Allen [mailto:tallen@sonic.net]
Sent: Thursday, December 02, 1999 11:10 AM
Cc: ebxml-regrep@lists.oasis-open.org
Subject: Re: Business Requirements


Dave wrote:

| One of the things that we may want to look at soon is a "use-case"-like
| definition of how the repository might be accessed.  It would not
| require that we have the message-routing definition or what the
| repository will store resolved before we do that.                 

and Scott wrote:

| I would like to kick off a discussion on "business requirements" which is
| our first deliverable.  We need to first compile a list of requirements
that
| a business person would want, and from there build a list of functional
and
| nonfunctional requirements of a repository.  The functional and
| nonfunctional requirements MUST be traceable to a business requirement in
| some form (otherwise why specify it?).  
|
| In TMWG, we have started to develop some UML models to represent this, and
| at this time we have some use cases started.  It is my goal to incorporate

I firmly believe in starting with use cases (which I am used to calling 
"scenarios"; doesn't matter) to ground the business requirements in, so 
I couldn't agree more.

The scenarios for the OASIS Regrep spec are focused on finding and 
retrieving DTDs and schemas for 1) immediate use in parsing, 2) use 
in writing conformant documents, and 3) development of other DTDs and 
schemas.  I'm sure they cover (with some modification for UML, perhaps) 
some of our scenarios, but clearly we (ebxml) have at least different and
perhaps more general scenarios, too.  What is it that users want to do
(or need to do whether they know it or not), and how do ebxml's scenarios 
differ?  Are our users developers or participants in a transaction,
or both?

| everything we do in this project team into the UML model.  Similar to the
| SWIFT demonstration, I would like to generate off the model itself the XML
| DTD or Schema to represent the interfaces to the repository.  Ideally, the
| interfaces are abstract enough that the physical implementation ( MOF,
| 11179, OIM, etc. ) can be interchangeable.  Dave Van Noord kicked off the
| idea of client application adapters and provided a sample "getDTD"
request.

Where can I find that?  

FYI only, for the OASIS work we considered specifying an abstract request 
for a DTD (and other things, as listed in RFC 2483), and then specifying
concrete instantiations of it (e.g., in HTTP), but we decided to just
go for the jugular in order to make faster progress.  I'm happy for us
to specify the abstract in this group, and am interested in how you
represented it.

| While I believe this is definitely one of the interfaces, I strongly
believe
| that this will fall right out of the model if we do it correctly.
| 
| Another point is the background documents that should be used to build
these
| lists.  We need to have a means to share these documents.  In the
meantime,
| the official TMWG documents are at:
| http://www.harbinger.com/resource/klaus/tmwg/documentlist.html

Thanks for setting this up!

| Particular interest to our group:
| N093 - Report to UN/CEFACT on repository costs
| N030R1 - Repository RFI to commercial repository vendors

I don't find explicit scenarios in either.  N028 looks promising, but I 
can't download it; N027 is at a higher level, I should judge.

| X12's SITG put together a document that details the anticipated workflow
| that went into the N093 document.  I put up a temporary web site at
| http://objectrepository.homepage.com/ that shows a high level workflow.
| Most of this has been input into the UML model.  We are using Rational
Rose
| 98i that can generate HTML representations of the model.  The freebie web
| site above does not support frames, so it is not available to us until we
| move to the OASIS site.  Its in constant state of refinement, so we'll
need
| an easy way to update the site ( permissions that is ).

Personally, I don't find the HTML representations of Rational Rose models
very useful because they've been picked apart too much; I'd just as soon 
look at an XMI representation (although I know I may be alone in that 
preference!) or the picture itself. 
 
| Sample business requirements:
| The business would like to have dynamic mapping tools that automatically
| retrieve the most current file specification from a repository.  ( note
this
| would be broken into MANY functional requirements ).
| The business would like to be able to map internal application semantics
to
| horizontal and vertical industry semantics.

Yes, and in general I know why, but specifically, when and in what
context does the business want to do this?  (It matters when you
get to considering such things as how fast the process must work to 
be useful.)

regards, Terry