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 others 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, processes, and the people that use them. I work with software development 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 data 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 consolidate 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 sequence 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 conversations 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 interface 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, presentation tool, and even something as limited as Microsoft Word.
Creating a display description can help reveal assumptions, business 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 defined. 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 coordinate 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 diagram. Second, even if I have enough information to get started on a class diagram, it can be more work for someone to absorb my attempt 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 description, and data flow diagram to be essential for business analysts who are defining non-trivial systems or clusters of related features. 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 documentation created for future reference and facilitate knowledge transfer.