Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Structuring the Business Context
Each UML model can have one or more Business Context documents depending on its size. So the first step in creating a business context document is to identify a suitable focus for it. This is either the whole model or a cohesive cluster of business entities (for example, Product, Order and Customer) that collaborate to deliver value to your business. Generally, you should name the business context document after the key thing in the cluster or after the part of the business the document explores.
Each business context document has the following minimal structure that you can add to as you see fit:
- Context
A general discussion of the business context that this document describes
- Compliance to standards
Existing standards that anyone working in this area needs to know about
- <thing>
Narrative, referencing one or more model fragments
UML diagrams constructed to illustrate the narrative
Informal diagrams
- <thing>
Narrative, referencing one or more model fragments
UML diagrams constructed to illustrate the narrative
Informal diagrams
I tend to structure Business Context documents around the "things" in the business (for example, Customers, Products, and so on) rather than processes because things tend to be relatively stable, whereas processes come and go. For example, companies often introduce new product processes, but the basic concept of product doesn’t change that much.
You can use informal diagrams wherever they enhance the text, but they should never be a substitute for a UML diagram.
The structure given here is not fixed, and you can add things to it or remove things from it as you see fit. However, the core semantics of the Business Context document—that it explains the model in light of the business context and forces that have shaped it—must always be preserved.