Business analysis efforts should start with a conceptual data model based on use case content
Successful business analysis requires understanding of business. One of the essential tools for understanding a business is a conceptual data model. Even though conceptual models are relatively easy to understand and create, business analysts do not use them enough. From the information in a use case diagrams, business analysts can create a conceptual data model that can serve as the foundation for understanding data and processes.
The Definition
A conceptual data model is a structured business view of the data required to support business processes, record business events, and track related performance measures. It establishes business knowledge and names the key business entities and relationships between them. It enforces consistent business terminology and identifies the concepts that exist independent of any technology implementations.
The Challenge
One of the challenges that business analysts and architects face in creating conceptual models is that business stakeholders do not want to spend time “diagramming”. While they acknowledge the value of process models, creating other diagrams may be perceived as a nice-to-have activity, or something that technology people do. If an analyst requests a meeting with key stakeholders “to create a conceptual data model” without sufficient background or a trust factor, they may not get sufficient support and participation.
The Use Case Approach
A more subtle approach may work in this case. The analyst can start by engaging stakeholders in defining business use cases. The concept of a business use case is well understood by most business analysts. A project initiation requires an agreement of what use cases are in scope. Defining and confirming business use cases with stakeholders is a legitimate request with a clear value to the project and the organization.
A smart data analyst will extract a lot of useful information from writing use cases, including identifying the main components required to start building a conceptual data model. And once the draft is created, it will be much easier to expand the model and the requirements.
The Method
A business use case defines what a business persona does to achieve a specific business goal. A use case is associated with a persona (an actor) and is expressed as a “verb + noun” combination, indicating an action and the object or goal of the action. A simple use case diagram follows below. At the conceptual level, it is not necessary to indicate system boundaries. The focus must be on what each persona needs to do, regardless of what technology is in place to support it.
Figure 1. Business use cases
First, examine the diagram to discover business entities, starting with actors.
There is no need to create a separate entity per actor – first, think in categories. In this model, observe four actors: Customer, Sales, Service Representative and Meal Manager. For simplicity, start by categorizing them as internal and external entities – Customers and Employees. Is it sufficient to have one entity to represent Employees? Start from this simpler solution, and then judge whether the model requires more granularity.
Now, consider the objects (nouns) in the use cases. What are they? An Order, a Proposal, an Account, a Menu, and Ingredients. Each of these objects is a candidate for an Entity in the conceptual model. Now, place them on a page.
Some of the entities clearly have a relationship captured in the use case diagram – for instance, Customer and Order. Remember that the use case diagram may not contain all required information – or may be incomplete in the first iteration.
Building The Model
The first version of the model can be simply a collection of placeholders.
Figure 2. Start with entities
This model is quite incomplete. However, seeing these key entities on a page will trigger clarifying questions about how the entities are connected to each other. These connections will become relationships in the conceptual data model. As the business analyst discovers relationships, additional questions will need to be asked to confirm the cardinality of each relationship.
For example:
- Customers place orders. This is a relationship between a “Customer” and an “Order” entity. A customer may place more than one order – this will inform the cardinality of one side of the relationship. Can an order be associated with multiple customers, or only one? Can someone be called a customer before they place the first order? The answer will be captured as the cardinality on the other side of the relationship.
Figure 3. Relationship between Customer and Order captured
- Observe in the use case diagram that an Order may be changed by a Customer or a Service Representative. Ask: what can change? A delivery address? Is that an attribute of an Order or a Customer? Can a Customer have more than one address? Then should it be a separate entity?
- What else can change? A delivery date? Sounds like an attribute. A customer may ask to include another dish? Does this mean that an Order can consist of multiple dishes? And that each dish likely has a name and some other attributes? Time to add another entity, Dish, to the model.
- How does the Ingredient fit into this picture? Is it the same as a Dish? No? A Dish will include multiple Ingredients? Capture this too.
- What is a Menu? A list of all Dishes available to order? Clearly a Menu consists of multiple Dishes. Is each Dish only listed in the Menu once? Yes, but there are different Menus – for lunch and for dinner.
Below is the next revision of the model with this information incorporated:
Figure 4. More relationships captured; new entities added
There is more to clarify, but as the model is developed, the gaps are easier to identify.
- Define is the relationship between Customer and Account: can a customer have more than one?
- How are Proposals managed? Does each Proposal relate to one Employee who will then receive a commission if a proposal is successfully converted to a new account? Or, is another relationship more appropriate?
- Additional information that stakeholders shared during the discussion, or artifacts that the business analyst has collected, will also indicate key attributes of each entity. These are the descriptions or characteristics of the entities. A conceptual model does not have to have an exhaustive list of all attributes – this can be done in a logical model. Only capture the main attributes that help explain the concepts properly.
At this point the model may look like:
Figure 5. Relationships clarified; attributes added
How far does the analyst need to go with the conceptual data model? Not so far that the diagram requires a plotter to be printed. The goal is to understand the business and the key concepts better. The intricate details, primary keys, and resolution of many-to-many relationships can be captured in logical models, by a data architect.
A conceptual model at the analysis stage can provide other benefits:
- Establishing consistent terminology based on business metadata
- Identifying requirements gaps to be refined and resolved
- Detecting missed one-to-many relationships, such as one customer to many addresses in this example
- Flagging potential problem areas, such as the lack of clarity between a customer and an account – are these different concepts, or only one?
Conclusion
A business analyst able to create conceptual data models has a strategic advantage. Additional analysis and modelling tools help to confirm the business model and its current state. Validating and clarifying information can lead to detecting gaps, missed requirements, and problems that must be resolved before additional data management or systems design activities can start.
From stakeholder perspective, once they are exposed to the new types of diagrams, they will become more familiar, interested, and accepting, especially if a modelling exercise helps to uncover a requirements gap. With this stakeholder support, and applying the principles of the BA mindset, the business analyst will be much better positioned to create a shared understanding of business requirements.
