Roadmap: How to Adopt the Use Case Driven Business Modeling Practice
Adopt the Use Case Driven Business Modeling practice incrementally, avoiding common pitfalls such as functional decomposition. Keep the white-box and black-box views of the business separate while defining the business.
Main Description

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.

More Information