On 16/01/07, Hitoshi Ozawa <[EMAIL PROTECTED]> wrote: > > > > > > > Steve, > I know that we were getting a little off topic here but curiosity just > got hold of me. > > You are definitely right that UML diagrams are not for business people. > But then, we don't expect business people to do requirement analysis. : )
No but we do expect them to understand the requirements and agree that this is what they wanted, this means that the form of the business process requirements (N.B. I mean business process not execution process) should be business consumable. > > The point is, on a large project, I don't expect business people to do > requirements > analysis. I don't think SOA is about enabling business people to > "develop" a large > scale system just on their own. 100% with you on that one, "Business People building systems themselves" is the philosopher's stone of computing. > I think it's more of developing a system > to enable > business people to get a better control of interactions between business > services. 100% agree, but this does mean that the system itself must be built in a manner where they understand its intentions. > > I don't see the reason to restrict it to rule-based or to procedural. Neither do I. My point about UML was that for business process (not execution) its very difficult for anyone to understand, let alone a business person who hasn't been immersed in UML for years. > > Regards, > H.Ozawa > > Steve Jones wrote: > > The question isn't so much what can't be represented in UML (pretty much > > everything can) but whether it can be represented in UML in a way that > > the > > business understands. While I've had success of getting business > > users to > > understand use cases and simple activity diagrams they are just to > > "techy" > > to be used for outlining complex workflows or business process > > interactions. > > > > So the problem isn't just whether UML can represent it, its also whether > > that representation is understandable. >
