Business-use cases are essential for modeling because they define processes as series of sequential steps with alternate flows. These use cases help stakeholders better understand the business and what’s working, versus what’s not.
Modeling business processes can help with many things, including but not limited to:
- Eliminating irrelevant details
- Presenting processes in a common format for all stakeholders
- Understanding complexity
- Assessing efficiency
- Capturing how value is delivered
- Determining time and cost
Different types of business-use case diagrams can help businesses understand processes in a simpler, more visual way.
UML vs. BPMN vs. Cross-Functional (Swim Lane) Diagrams
Cross-Functional (Swim Lane) Diagrams are usually the first visual format used to model business processes; in addition to this, there are newer notations such as Unified Modeling Language (UML) and Business Process Model Notation (BPMN).
Each notation uses its own unique symbols and terminology, but all models consist of the same basic elements:
- Activities: Triggered by an event, an activity within a process describes work a person or group or system performs.
- Events: An action (manual or automated), condition (rule), or temporal instance (passage or period of time), that triggers an action or process.
- Gateways (Decisions): A point in the process where a flow splits into two or more flows, or where two or more flows join together.
- Flow: The direction of the sequence, or order of events and actions.
- Swim lanes (Pools): Visual distinctions of responsibility, or visual elements identifying who is doing particular sets of activities within a process.
Visually modeling business processes is an effective way to examine how work is done within an organization. The visualization shows how the organization creates, delivers and captures value. By capturing the current and future states and using analysis methods, we can implement a change-management process to realize that transition as smoothly and painlessly as possible. Since business analysts are concerned with managing change more often these days, business-process modeling is a critical skill to have.
Practical principles to follow in modeling use cases:
- Principle 1: Get the Scope Right
Find the right boundaries for your business requirements.
- Principle 2: Challenge Your Use Case Goals
Structure your use case model appropriately.
- Principle 3: Use Requirement Attributes
This helps determine the best use case model.
- Principle 4: Decompose by Business Worker
Elaborate your business requirements further.
- Principle 5: Use Case Descriptions
Describe your business use cases appropriately (State what and not how).
- Principle 6: Produce a Domain Model
Connect your business use cases, avoid redundancies, and validate your requirements
- Principle 7: Use Entity Lifecycles
One of the basic tenets of managing requirements is to get the scope right. You need to ask yourself where the boundaries are; who is in and who is out? Many times, just a small change in scope has a significant impact on the project itself.
As cited above, use cases state what, and not how. They represent requirements by pointing out what the product does to achieve the goal for an actor.
The Domain Model
The domain model is a subset of the Business Analysis model that contains the business use case realizations, describing how the business workers and business entities achieve the use case’s functionality. The domain model ensures that the same term is used to refer to the same business entity. It is also the right place to capture requirements of the following types:
- Definitions of business entities and their attributes
- Relationships between business entities and their multiplicities (e.g., a mobile user uses one or many mobile phones)
In addition to following common sense and the preferences of your audience when creating the domain model, you can use the following guidelines:
- Use diagrams to support the descriptions, especially to show how business entities relate to each other.
- Prefer redundancy to generalizations; otherwise, you may demand too much from your business users.
- Prefer attributes for simple types to relationships; otherwise, you will clutter your diagrams.
- Omit the types of attributes when they are obvious to avoid creating distraction.
- Omit identifiers (such as Customer ID) if they are not relevant to the business.
- Use role names only when they help to clarify the context. Otherwise, imply the business entity name as the role name to avoid cluttering your diagrams.
- Create an easy navigation experience between related items. The domain model will be used frequently to find information.
Lifecycles are best placed into the domain model as appendices that are cross-linked through the business entity definition. Following this approach, you can leverage the benefits of using entity lifecycles without making your requirements look too “techie” when you place them in front of the business user.
To check the completeness of your domain model, ask yourself:
- Have I captured all relationships?
- Are all business entities referred to in at least one use case?
- Are all business entities referred to in use cases in the domain model?
- Why a Business Analyst’s Role Is So Hard to Define
- The Tech Skills Every Business Analyst Needs to Know
- Interview Questions for IT Business Analysts