3 Visual Models a New BA Should Know How to Use


In a recent article on the Top 10 Skills a New Business Analyst Should Shore Up On, #6 was identified as creating visual models.

Most BAs tend to have a natural preference for either textual or visual models. Requirements specifications ideally include both types of information, as different stakeholders learn in different ways.

Visual models don’t have to be complicated. Unless your organization uses formal UML or BPMN standards, focus on learning to create simple visual models.

In this article, we’ll explore 3 simple visual models that a new business analyst should be skilled in creating because they add a lot of value to projects and generally improve your requirements documentation. Then we’ll look at how you can begin using more visual models in your projects right away.

Visual Model #1 – Process Flow Diagram
Process Flow Diagrams are an intuitive way for stakeholders to understand the organization’s fundamental processes, get clarity on how work gets done, and appreciate how value is delivered. They also put other requirements activities in context. For example, a business process diagram can help facilitate more effective use case reviews by providing context for how the system functionality will support the business process.

Visual Model #1 – Process Flow Diagram

Process Flow Diagrams exist in multiple forms. Most BAs create simple workflow diagrams that show the end-to-end business process. These diagrams contain boxes for each activity step, diamonds for any decisions or variations in the process, and a series of arrows to clarify the sequence of steps in the process. Swim lanes may be used to show who or what is responsible for each step in the process.

A smaller subset of BAs use BPMN (Business Process Modeling Notation) to create more formalized diagrams. Conceptually, BPMN diagrams are similar to workflow diagrams. However, the BPMN notation contains a much larger number of formal elements and so the BPMN diagrams tend to be more visually complex. The complexity can be useful if your process requires it. Otherwise the notation can make it more difficult for stakeholders to comprehend and approve your process models.

If you are new to this skill set, focus first on learning how to create workflow diagrams and visually model processes. Then, as your situation warrants, explore a more complex notation like BPMN.

Visual Model #2 – Business Domain Model
Business Domain Models clarify the information created and managed by an organization without diving deep into the database structures. Creating and walking through a model like this can often clear up misunderstandings and get everyone speaking the same language.

Essentially, a business domain model visually presents information that might be included in a glossary or data dictionary. This way, you can show not only what terms mean but how the relate together.

In a Business Domain Model, each key concept gets a box. Important attributes for each concept are listed within each box. Lines connecting the boxes show the relationships between concepts.

For example, a Business Domain Model might contain a box for the concept of “Customer” and attributes for Customer Name, Customer Address, and Customer Contact. The Customer concept might have a 1-to-many relationship to the concept of “Order” which has attributes for Order Date and Total Amount.

Visual Model #2 – Business Domain Model

Business Domain Models can be created using the same notation as an Entity Relationship Diagram (or ERD)and they tend to look a lot like logical or physical data models. However, they tend to be less complex than data models and focus only on the information concepts critical to understanding how the business works.

If this is a new skill set, focus on keeping your domain models simple and business-driven. Later on you can get deeper into the complex relationships that exist within physical databases.

Visual Model #3 – User Interface Wireframes
A User Interface (UI) Wireframe is a visual rendering of how a specific screen to be implemented as part of a software solution will be laid out. They are useful in generating “yes, but” conversations and eliciting information stakeholders don’t think of until they see what an application might look like.

UI Wireframes, also often called Prototypes or Mock-Ups, can vary in fidelity, or the degree to which the presentation of the user interface is intended to be realized in the final application.

  • A low-fidelity UI prototype may show the general layout of the screen but not the specific UI elements.

  • A medium-fidelity UI prototype will show the UI elements on the screen but may not represent the actual look.

  • A high-fidelity UI prototype, often called a rendering, will represent exactly how the UI should look and feel once implemented.

Visual Model #3 – User Interface Wireframes

Typically, a business analyst is responsible for either low-fidelity or medium-fidelity prototypes, while a graphic designer, user experience expert, or technology lead might be responsible for high-fidelity prototypes, if they are even required for your project.

If this is a new skill set, focus on creating lower-fidelity user interface prototypes and using them to drive conversations about intended software functionality and key business processes.

Using Visual Models
Visual models help you communicate, clarify, and analyze the requirements. As a new business analyst, it’s critical to have some core visual modeling skills as you’ll be better prepared to handle complex analysis tasks and figure out solutions to difficult problems.

While there isn’t always a need to learn sophisticated visual modeling techniques or complex visual modeling tools, you do need to pay attention to when a picture will be more effective than words.

The next time a difficult conversation comes up on your project, consider what visual model might help your team work through the problem. Put a draft together, either in a visual modeling tool or using an old-school tool like a whiteboard, and use it as a conversation piece while facilitating a meeting. I suspect you’ll find the conversation begins to go much more productively.

In the absence of access to visual modeling tools, the Smart Art and Shapes features available in the Microsoft Office Suite can help you get started and there are a variety of online visual modeling tools that offer free or reduced cost trials.

Whatever you do, just start modeling! With a little bit of practice and creativity, you’ll become well-versed in a variety of visual modeling techniques.

Author: Laura Brandenburg, CBAP is the author of How to Start a Business Analyst Career, the host of Bridging the Gap, and offers a BA career planning course (it’s free) to help you start your business analyst career.

Like this article:
  52 members liked this article


Putcha posted on Wednesday, April 16, 2014 6:14 AM

I think we have interacted earlier in LinkedIn groups. I agree on the need for visualization but oversimplified diagrams cause more problems than solve.

In any professional BA or RE work, the artifacts must have some rigor and precision. Otherwise they end up as doodles----nothing wrong but nothing specific is conveyed by them.

The flowcharts are too lax and trivial. They only show control flow which from activity to activity which is often obvious. Sadly they do not show what are the inputs that are processed by an activity in the box not what the output or result is. What use is a process representation if one does not know what gets processed and what is put out?

Making business user understand processes or data models is useful but the rigor and precision of what is conveyed by a professional should NOT be brought down to that of a layman. The business user may feel comfortable but he or the others who use such diagrams get nothing useful for the effort.

About the wireframes I am not too critical since they are inherently visual but actual UI design demands a lot more than doodling skills.

Professionals must convey something precise (the precision may vary) for developers to get on with the work without too much of discussion and clarification. Unfortunately both UML and BPMN are too elaborate and inconsistent in many diagrams I have been using.
There is no minimum essential set of symbols and conventions in either. One has to read nearly 800 pages of UML 2,5 or 500+ of BPMN.... no other engineering drawing makes such demands (and they are NOT worse off).

Laura Brandenburg posted on Wednesday, April 16, 2014 2:06 PM
Thanks for leaving your comment @putchavn. I would disagree and instead state that "simplified models solve more problems than they create". In the act of simplifying a view of a problem domain, often the business analyst is forced to clearly communicate and abstract a collection of information, which becomes the basis for solid decision-making by business stakeholders.

That being said, if you expect your models to be implementable, they will need more rigor. In my experience, implementable visual models are saved for technical analysts and systems analysts and those more directly involved in the technology design or implementation process. It's appropriate to begin creating these more detailed models once the business has clearly communicated what they want, which is often best accomplished by the higher-level more abstract models discussed in this article.

Ryan Milligan posted on Wednesday, April 16, 2014 2:32 PM
Hi Laura,

Nice article, straight and to the point. I've been a part of multiple projects where these artifacts haven't been put together because, quite frankly, they can be a pain in the you-know-what given time and resource restraints. However, if effort is put into defining the process (Visual Model #1) and the data (Visual Model #2), a lot of guesswork is eliminated in defining the function (Visual Model #3). I strongly disagree with the poster who claims that the control flow is "obvious". Especially for projects that don't have an existing system to reverse engineer from (i.e. building new from scratch), it can take many iterations to truly understand the conditions, nuances, and exceptions of the business process to be reflected in the solution. Again, some people don't like the tediousness that may come with deliverables such as these, but as is common in the BA world, pay a little now or pay a lot later.
Tim Bryce posted on Wednesday, April 16, 2014 3:02 PM
Laura -

Thanks for your efforts, but I found your approach to requirements definition rather primitive. I do not say this to provoke you but I fail to see how any of what you have described is useful from a requirements perspective, certainly not information requirements, for your models fail to describe the business rationale (who requires it, why it is needed, when, and what actions/decisions will be supported). Instead, your models should demonstrably implement information requirements. Unfortunately, they do not.

We have advocated "stepwise refinement" of information requirements for many years, whereby information requirements drive the design of a system top-down ("Information Driven Design"). For information, see:

Also see:

Tim Bryce
Palm Harbor, FL
Since 1971: "Software for the finest computer - the Mind"
Laura Brandenburg posted on Wednesday, April 16, 2014 3:59 PM
@ryanmilligan, Thanks for your comment and kind words. I too have found models like these add a lot of clarity to the project.

@timbryce, This article was not meant to provide an approach to requirements definition, but a starting point for a new business analyst looking to build some foundational skills in visual modelling.

Arpita posted on Tuesday, May 20, 2014 4:59 AM
Hi Laura, Nice article.
Could you suggest some low and medium fidelity UI prototyping tools that can used.
Laura Brandenburg posted on Thursday, May 22, 2014 5:03 PM
@Arpita, Here's a list of diagramming and prototyping tools I recommend:


Hope this helps!

Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC