The common perception of business analysts is that they deal mostly with requirements and those activities associated with requirements work—management, elicitation, and gathering, among others. Recently, however, business analysts have been studying visual modeling as well as requirements work. But what are visual models and when are they necessary?
This post is to clear up some of the confusion surrounding visual models, as well as give more information on just how important they can be.
The latest version of the Business Analysis Body of Knowledge Guide (BABOK), a visual model is “a descriptive and visual way to convey information to a specific audience in order to support analysis, communication, and understanding. Models may also be used to confirm knowledge, identify information gaps that the business analyst may have, and identify duplicate information.”
Therefore, visual models can be diagrams, sketches, or screen drawings with textual descriptions showing how requirements translate into functionality, user experience, and business value. Visual models effectively contribute to better communication within a team, especially when dealing with complicated processes and concepts.
Visual models also break down the barriers between learning styles that are specific to certain domains by utilizing both text and images. These models also allow a product team to share a common vision about requirements and foster easier and more effective collaboration. Additionally, potential flaws can be identified faster in the inception phases of the project, and design alternatives can be easily explore, thus impacting the business decisions of the whole project.
Text is useful for the description of a request, but on its own it can be difficult to digest, especially in long, concentrated doses. Visual models especially should be easy to create and easy to consume. The models should not hinder the productivity of a project team, nor should it be difficult to understand from a stakeholder perspective.
There are five different categories for visual models; specific categories are more appropriate for specific project types.
Most of these models work best with specific types of projects; however, Use Case Diagrams, Flowcharts, and Wireframes can be used for almost any project undertaking.
Use Cases: Use cases and scenarios describe how a person or system interacts with the modeled solution.
When to use:
There is a common misconception that user cases are not an Agile practice, while user stories are. However, both user stories and user cases are Agile practice, because they are both approaches that are focused on delivering value to the customer.
User Interface (UI) Wireframe: A UI Wireframe is a visual rendering of how to lie out a specific screen to implement as a part of a software solution. Wireframes are a low fidelity depiction of the layout of both information and features on a screen.
When to use:
Flowcharts: A flowchart represents a workflow or process by showing the steps in various boxes and their order with connecting arrows. Flowcharts are used in analyzing, designing, documenting, or managing a process or program in various fields.
When to use:
Visual modeling helps all stakeholders in a project to visualize, construct, and document the structure and behavior of a project system without being lost in its complexity.
There are good or bad visual models, only models that are appropriate or not for a certain type of project. The essential part of visual models is that they should be easy to create and easy to consume.
Occasionally, one model may not be enough to accurately represent a project. The main goal is to simply capture information precisely and convey it in a rapid, easy to understand manner.