[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Business Requirements
I have updated the temp web site http://objectrepository.homepage.com/ with 1) a list of business requirements, and 2) placed the usecase.zip file with the html pages showing what TMWG had started. See appropriate links. Business Requirements Note: These are high level statements that a business person expects. It is quite often that the us technical people get confused with functional and non-functional requirements. Remember that the business seldomly understands what we are talking about (scaleability, etc.) but just want things to work NOW. Some of these items are similar to the eCo Framework use of a registry, which I believe is one of the most important architectures to date. I intend to lobby heavily in its favor. Use Cases Note: There are many users of the repository, people and application systems. The use cases depicts one and many different types of people that would use the system. This needs work. Regards, Scott -----Original Message----- From: Nieman, Scott [mailto:Scott.Nieman@norstanconsulting.com] Sent: Thursday, December 02, 1999 3:39 PM To: ebxml-regrep@lists.oasis-open.org Subject: RE: Business Requirements The output from Rose is converted into HTML and gif files. It has a Java applet for navigation. -----Original Message----- From: Dave Van Noord [mailto:vannoord@trans4m.com] Sent: Thursday, December 02, 1999 3:34 PM Cc: ebxml-regrep@lists.oasis-open.org Subject: Re: Business Requirements We may want to start out with prose to begin with. Unfortunately, I don't think we will find a common tool for us to all use (unless someone can pull some strings with Rational). I have tried to read XMI, it is probably not the best communication mechanism for humans. Terry Allen wrote: > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC