In this series (5–6 posts), we’ll talk about diagrams — and UML diagrams in particular. The goal is to keep it simple, engaging, and fluff-free.
We’ll start with a general overview: the popular modeling “languages,” where UML fits in, and why we even bother with this stuff. Then, we’ll dive into the UML diagrams that analysts tend to use, with a focus on how they apply specifically to us. For graduates of our business analysis course, much of this will be familiar. Still, I’ll try to sprinkle in new and interesting insights so there’s something valuable for everyone.
So, most analysts draw diagrams (“build models”). There are different modeling notations. A notation is a language — created at some point by someone, with rules like: “use a rectangle/diamond/elephant to represent this,” “elephants can only be connected with dashed arrows, which mean such-and-such,” or “don’t draw this kind of arrow, or you'll break the sacred laws.” Many analysts ignore formal notations and draw ad hoc — freestyling on the spot, adapting to the task at hand. That’s totally valid. But I’ll try to make a case for why it’s worth investing in at least the most common notations:
Notation increases the chances you’ll be understood — by your team, your stakeholders, other analysts. Sure, for that to work, you need a rare combo: recipients who know the notation and you drawing it properly. But those cases do happen.
Notation often saves you from reinventing the wheel. If smart people have already created, tested, and refined tools that do the job — why not use them? You can always adapt as needed. So, before freestyling, I suggest this: “First, I’ll check whether a suitable existing tool or format exists. If I find it unreadable or too limited, then I’ll customize.”
Notation builds your visual literacy. If you study even a few of the notations below, you’ll a) draw more frequently and confidently (knowing how and when different diagrams help), and b) model requirements more accurately — without overloading your audience, making fewer mistakes, and leaving fewer gaps. For example, you won’t end up doing things like this:
Understanding notation can earn you serious credibility. In a world of “lean” techniques, clients from more structured industries will respect your grasp of professional tools. Not to mention, many job listings reference these notations — and interviewers often love to test for this kind of knowledge.
The notations you’re most likely to encounter, along with my general advice (aside from situations where your specific job dictates otherwise):
UML (Unified Modeling Language) — the most widely used graphical modeling language for IT systems. Multiple diagram types for different use cases. Useful to know because of its popularity and broad applicability — which is why this series exists.
BPMN (Business Process Model and Notation) — a common choice for modeling business processes. Unlike UML, which focuses on IT systems, BPMN is about workflows within organizations. Worth learning if you’re working closely with business processes. It’s narrower in scope than UML — effectively offering just one type of diagram (technically four, but only one really matters). Yes, UML has diagrams you can use for process modeling, and you can use BPMN in place of some UML diagrams. But using the right tool for the job always looks more professional. And at a basic “let’s draw and discuss” level, it’s not that complicated.
IDEF (Integration DEFinition) — like UML, it’s a set of diagrams for various scenarios. But it's niche, outdated, and not something you need.
There are also more specialized diagram types or “not-quite-notations” for specific needs: Flowcharts, Crow’s Foot (for ERDs), DFDs (Data Flow Diagrams), etc. Among these, I’d single out DFDs, since there’s no real equivalent in popular notations — read a few articles and see if it resonates.
Now let’s get closer to the point: the most popular modeling language in the IT world — UML (Unified Modeling Language).Here’s what’s useful to know:
UML has been evolving (though that might be a generous word) since 1994–1995. The current version at the time of writing is 2.5.1.
It’s positioned as a graphical modeling language for object-oriented software systems. So a) the focus is on IT and software systems in particular, b) it’s meant for systems built using an object-oriented approach (if you’re not familiar with that, don’t worry — most modern development is object-oriented, and it won’t really affect your ability to use UML diagrams effectively).
Both UML and BPMN (mentioned together since they’re maintained by the same organization — Object Management Group) are described in large, complex, dry-as-dust specifications. The only time you really need to crack open those specs is if a) diagram correctness is critical in your workflow (e.g., your team feeds diagrams into tools that generate code or database structures), or b) you’re planning to teach this stuff professionally. Otherwise, use more human-friendly guides and tutorials (like this series, ahem), even if they may gloss over minor technicalities.
UML wasn’t made for analysts. It’s a tool for the whole dev team, with much of it geared toward developers. That means a) many diagrams are irrelevant to analysts (we don’t touch those aspects of development), and b) some diagrams may be hard to understand without dev knowledge. This means when you go looking for guidance, most online sources talk to you like you’re a full-stack developer with 15 years’ experience. That’s why this series looks at UML through an analyst’s lens (you can find plenty of dev-focused guides online if you need them).
To understand the full UML “toolbox,” let’s briefly list its diagrams. UML diagrams fall into two categories:
Structural — show static structures
Behavioral — show dynamic behavior over time
A few words about each one, so you know what they are and whether you need them (with some subjective judgment and generalization):
Class Diagram — Originally meant to depict software code and database structure. In reality, it can be used to represent the structure of pretty much anything. It’s genuinely useful for analysts, as it allows you to build multiple valuable models. Definitely useful. A versatile workhorse diagram.
Object Diagram — Shows the structure of objects as instances of classes at a specific point in time. To really get it, you need a solid grasp of object-oriented programming. Or maybe not — because odds are, you won’t need this diagram anyway. You can skip it.
Package Diagram — Groups elements into packages and shows how those packages relate. For example, you might group related use cases into thematic clusters and give a high-level overview. That might sound exciting in theory — but in practice, it’s not. Not useful for analysts. Pass.
Component Diagram — Highlights major software components and how they’re connected. Outside of hardcore system analysis (which borders on development), this isn’t something you’ll use. Generally irrelevant. Leave it to developers.
Composite Structure Diagram — Displays the internal structure of classes. That’s all. No value for analysts. Skip.
Deployment Diagram — Shows the physical placement of components across servers, devices, or other software environments. Analysts might use it occasionally to help others visualize the setup — though strictly speaking, that’s not really our job. Still, if you like being helpful… Marginally useful, but only in special cases.
Profile Diagram — Visualizes profiles and stereotypes across your model set. Sounds like alien tech already, right? Easiest thing is to forget it exists. Nope. Don’t bother.
Use Case Diagram — Visualizes your set of use cases and adds connections between them and their actors. If you’re applying the use case technique, then this diagram is a must. Core tool. Use it.
Activity Diagram — The main behavioral diagram. It shows process essentials: steps, participants, branches. It’s very handy — and not just for software-related workflows. In fact, it’s a strong alternative to BPMN or flowcharts. Super useful. One of the key diagrams.
State Machine Diagram — Illustrates how an object’s state changes over its lifecycle. Quite cool and genuinely useful in a range of scenarios. Not always needed, but when you need it, it shines.
Now, onto a group of diagrams under the “Interaction Diagrams” subcategory — these focus on how objects interact. Sequence Diagram — Shows more or less the same process logic as an Activity Diagram but with a strong focus on interactions between participants. Sometimes gives a useful new perspective. Generally useful. Keep it in your toolkit.
Communication Diagram — Displays how objects communicate overall, without the step-by-step detail you get from a sequence diagram. Low value. You can skip it.
Timing Diagram — Focuses on the timing of interactions between objects. Very niche. Don’t worry about it.
Interaction Overview Diagram — A hybrid of Activity and Sequence diagrams: process steps + participant messaging. Neat on paper, but… Sounds more exciting than it is. You won’t need it.
Now, a word on the building blocks of UML. Since UML is a language, it has an “alphabet” shared across all diagram types (with some symbols specific to certain diagrams).
Elements — The core building blocks of any diagram. For example, the UML diagram we looked at earlier that depicted the UML Diagrams' structure (already broke your brain, haven't I?) — that was a Class Diagram, and each item on it was a Class. You’ll soon learn why some of those classes were in italics.
Relationships — Connect elements to show how they relate. Also, we’ll later dig into why so many connections on the diagram above end in a hollow triangle — and why some merge and others don’t.
Stereotypes — Not mandatory knowledge, but knowing about them makes you sound very sharp. Stereotypes are a way to extend UML — letting you add your own custom elements and relationships. It’s not recommended, since UML’s whole point is shared understanding. When you start injecting your own semantics, you drift away from standard meaning. But if you must, this is how. A stereotype is a label in double angle brackets next to an element or relationship, giving it a custom meaning.
What’s next?
In the following articles, we’ll look at the UML diagrams actually useful to analysts (spoiler: they’re the yellow-highlighted ones in the diagram and text above). For each of those, I’ll break down:
When it’s convenient/useful to use the diagram
Key elements (both common ones and advanced stuff for power users)
Typical relationships (again, both frequent and rare)