From:
[email protected]
Date: 2020-01-25
Subject: Four Essential Diagrams for Business Analysts
As a business analyst, I find that diagrams are very helpful when
thinking and talking about complex topics. A diagram can help oth-
ers absorb complex information faster, and comprehend it better,
than a wall of text. Just the act of creating a diagram helps me
structure my thinking and identify problems and opportunities.
First, I want to clarify what I mean by "business analyst". It's a
term used to mean many things. In this case, I'm talking about a
person who works with business stakeholders to understand what they
want to accomplish and then defines how that impacts systems, pro-
cesses, and the people that use them. I work with software devel-
opment teams to define, design, and deliver software such as web
applications and mobile apps. In complex environments, I find that
use case diagrams, sequence diagrams, display descriptions, and da-
ta flow diagrams are essential.
When defining a new feature or application, my initial questions
are about who the users are and what they need to accomplish. A
use case diagram helps me visualize users and their actions. I
start out with a list of users and things they need to do and then
use that to create a diagram. Don't forget about your admin users!
Creating a diagram can then help identify opportunities to consoli-
date like use cases and split up use cases that are too dense. I
find that use case diagrams, simple as they may seem, often prompt
productive conversations about who does what.
Now that I know who does what, a sequence diagram will help me
think through the *how* and the *when* for each use case. A se-
quence diagram shows actors and interactions over time for a given
use case. It can help uncover unanswered questions and conflicting
or unstated business rules. I can also check my work by focusing
on the perspective of each actor, in turn, to check that it makes
sense. I find that sequence diagrams inspire the most useful con-
versations because they force us to reckon with significant details
that are otherwise easily glossed over. It provides an opportunity
to simplify the solution where possible and justify complexity
where it is necessary.
So far, I've defined who is using the application, what they are
doing with it, and when they interact with it. At this point, I
should start thinking in more detail about those interactions. I
start roughing out interfaces, not to define how they will look,
but to identify what data is displayed and what data is captured.
A display description shows what elements will appear on an inter-
face such as data, form fields, and controls. I don't call it a
wireframe because I'm not concerned with the spatial relationship
or hierarchy among elements. This means that a display description
can be created using almost any tool such as a text editor, presen-
tation tool, and even something as limited as Microsoft Word.
Creating a display description can help reveal assumptions, busi-
ness rules, and dependencies. For example, if a user is required
to provide a value by choosing from a list, that list needs to come
from somewhere. It may be static, or it may be dynamically de-
fined. In any case, it needs to be defined before it can be built.
I don't need to create a class diagram, but I need to get specific
about the data that people are putting into and getting out of the
system. Creating a display description is an effective way to do
this.
As I identify the data being shown or captured in an interface, I
start to ask where this data comes from and where it goes. A data
flow diagram, or DFD, leaves the people and interfaces behind and
focuses on the data; where it comes from (sources), where it goes
(sinks), where it is stored, and what processes affect it along the
way. On the spectrum of specificity, a DFD lies between a sequence
diagram and a class diagram. If the solution includes only a few
sources, sinks, and processes, creating a DFD may be overkill. I
don't always create a DFD but, when multiple systems have to coor-
dinate to make a feature work, I find it helpful to create one.
I could continue to reduce uncertainty by creating class diagrams,
and I am often tempted to do so. A class diagram focuses on the
static structure of data and does not address where it comes from
or where it goes. With respect to both a sequence diagram and a
data flow diagram, a class diagram is more detailed with respect to
the data structure, but omits sources, sinks, processes, actors,
and the dimension of time.
I try to avoid creating class diagrams, myself. First, I'm usually
not close enough to the implementation to create a useful class di-
agram. Second, even if I have enough information to get started on
a class diagram, it can be more work for someone to absorb my at-
tempt at a definition than had they created it themselves. In
short, I let the developers do their job. I get better results
that way.
I consider the use case diagram, sequence diagram, display descrip-
tion, and data flow diagram to be essential for business analysts
who are defining non-trivial systems or clusters of related fea-
tures. They help me think through the problem and the solution.
They enable productive conversations with stakeholders in both
business and technical domains. Finally, they anchor any documen-
tation created for future reference and facilitate knowledge trans-
fer.
