Top 3 Modeling Notations for Business Analysts

A picture is worth a thousand words! There's no better way to describe your business process or a domain than using visual notation, and in this article, I'll share my top three modeling notations and explain how and when I use them.

#1 - BPMN (Business Process Model and Notation)

BPMN (or Business Process Model and Notation) has been around for more than a decade and has gained tremendous popularity not only with BAs but also with software architects, process analysts, and management consultants.

It is a powerful and simple-to-follow notation that allows you to describe almost any process at any level of detail. Whether we're analyzing the current (or AS-IS) process or trying to define the future (or TO-BE) process - BPMN is a great choice, and here's why.

In process modeling, there are notions of L1, L2, and L3 types of diagrams.

With BPMN, you can start from L1 which is a high-level definition of the process, really a thousand feet view, so you can set the boundaries and define major components of the process.

Then move on to L2, where you can add more details and add swimlanes to indicate who performs these actions in the process.

And then finally, you reach L3, where you not only specify who does what, but you also define how. This is where you get into more details; you can add conditions, intermediate events, data flows, and many more elements.

And as a modeling language, BPMN gives you all the tools that you’ll need to describe the details of your business process.

#2 - Conceptual Domain Models

Conceptual domain models are a mix of entity-relationship and ontology diagrams. They illustrate the main concepts and entities within your process or business domain and how those concepts relate to each other.

For example, when I'm defining the structure of a product catalog, I want to include concepts like product, category, brand, season, and seasonal catalog, as well as suppliers and warehouses, depending on the specifics of my process. As I’m defining these concepts and how they relate to one another, I’ll discover more questions and insights about the business domain that I’ll need to clarify.

Please don't mix conceptual domain models with database models. Although there are certain similarities, they are not the same. You should always start with a conceptual model, where you define business entities and how they relate to one another, and that model may influence how you build your database to store this data. If you have ever heard terms like physical and logical data models, then the conceptual diagram will represent the logical model of your business domain.

As for the modeling notation, my preferred choice is the UML class diagram. It's a great choice to describe high-level concepts and relationships within the business domain. And again, you don't necessarily describe the database model or actual classes of programming language there. Instead, you just use the notation elements, like classes and associations to describe your business domain. I learned about this approach from Howard Podeswa's classic book called "UML for the IT Business Analyst", where there are great examples of using UML for conceptual modeling, processing definition, and other typical BA tasks. Make sure to check it out.

#3 - Sequence Diagrams

Sequence Diagrams are a very powerful tool in the hands of business analysts, and here's why.

With the continuous trend toward building headless and decoupled architectures, we see more cases where there is a need to describe interactions between multiple black boxes or systems within a process. For example, if you're working on a product management solution, you might need to pull media assets from an external digital asset management system and assign them to your products. For this, you need to define the sequence of calls and the data that is being exchanged.

Another example - when a registered user gets to the My Account area, there's often a dashboard where the user can see a bunch of data related to their past orders, preferred shipping address, current order status, and other information. In most cases, this data comes from external third-party datasets or APIs. As an analyst, I want to have a clear definition of how these systems interact with each other and what the sequence of steps in this interaction is.

And of course, the UML Sequence Diagram is a great choice to define and describe such interactions. Again, you may use it at various levels of detail. As a BA, you don't necessarily need to define what actual API methods are called in the interaction, but you may concentrate on the data that's being exchanged and the sequence of calls. That will later influence how developers will implement the actual interaction.

Learn More

Interested in learning more? Download the Discovery Checklist – your all-in-one, practical blueprint for successful requirements elicitation, packed with actionable steps to guide you through every stage of the discovery process.