Sparx Systems Forum

Enterprise Architect => General Board => Topic started by: cjh on August 03, 2006, 03:28:22 am

Title: Use Cases
Post by: cjh on August 03, 2006, 03:28:22 am
Does anyone have any experience of introducing users to the concept of use cases?

Here we tend to define requirements using EA with our users and put together a business process model based on that.

Generally people seem OK with that, but there is a lot more information about the final system that is then put in the use cases.

By the time we have taken people through the Business Process model, though, it  seems as though much of the information that business users would be interested in has already been covered.

Are we putting too much information in the Business process model? What model structure do other people use to support the initial analysis with business users?
Title: Re: Use Cases
Post by: thomaskilian on August 04, 2006, 03:42:45 am
cjh,
there are already a lot of threads about UCs here on the board. So you should try searching for them. A common recommendation would be: read the standard books (search here "Use Case Book").

Regarding the Business Process Model: I usually take this to get a very rough overview of the customers business and goals. I do not put much effort in this (usually), but it should indicate what and where the customer is earning money (haven't worked for non-profit orgs yet). It's really funny, but people simply forget or did never know what is the purpose of their work. They just go to work, do something and hopefully receive a salary for doing so.
Title: Re: Use Cases
Post by: csousa on August 04, 2006, 02:08:22 pm
Quote
Are we putting too much information in the Business process model? What model structure do other people use to support the initial analysis with business users?


Maybe too detailed or maybe not...it is hard to say.


A general rule I apply when business modeling is to ensure that the model is agnostic of systems...meaning I do not attempt to show what aspect of the business process is completed by the system (e.g., no swimlanes for systems or system components).

This usually allows the business model to be a better description of what has to happen at a high level of abstraction and avoids insignificant tasks that are a symptom of how something is implemented today.


My use cases then go deeper and refine this by modeling specific user-system interaction..here I am interested in learning what tasks the system will be responsible for.

Cheers,