If you're starting with the Use Case Driven Business Modeling practice, begin by familiarizing your team with basic
concepts such as Business Use Case, Business Use-Case Realization, and Business Architecture. Read the Whitepaper: Effective Business Modeling with UML: Describing Business Use Cases and Realizations for an in-depth discussion of how business use cases become business realizations.
Incrementally adopt the techniques described in this practice. For example, begin by gaining expertise and habits in
writing good business use cases. This is also a skill that's transferable to other areas such as system use cases and
writing tasks for processes. Once the team can identify and write use cases, begin to define business use-case
realizations to describe the internal workings of the business.
Common Pitfalls
It's common for people who are beginning to leverage use cases (and for experienced users as well) to functionally
decompose their use cases. This reduces the understandability and effectiveness of use cases. Make sure the team is
familiar with Functional Decomposition. Understand how to avoid falling into this trap by
practicing Strategies to Avoid Functional Decomposition.
Be aware that creating business use cases and realizations is not the same as defining a business architecture. This
practice is one you might perform to support developing the business architecture, and a Business Use-case Model is very useful in helping to describe the business
architecture and make architectural decisions. But this practice doesn't describe how to produce a business
architecture or how to make important decisions about the business architecture.
Generalizing the actors in a business use-case model is a good way to clean up diagrams. But this can be overused
because practitioners confuse the ability of two different actors to do the same thing with the idea that one actor is
the same type of element as another actor. A common mistake is to generalize two unrelated actors just because they
perform a common task or have a common goal.
See Using Actor Generalization to understand how to generalize actors
appropriately so the use-case model is meaningful and understandable.
|