September 11, 2015

Visual Modeling for Software Requirements

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.

What are Visual Models?

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.

The Importance of both Text and Images

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.

Visual Model Categories

There are five different categories for visual models; specific categories are more appropriate for specific project types.

  1. Business Objectives: these visual models represent the “why” aspect of a change. Techniques to use include—Decision Modeling, Scope Modeling, Business Model Canvas, and Root Cause Analysis (also known as the Fishbone Diagram)
  2. People Models: these visual models represent organizations or groups and their roles that are tied to certain solutions. Techniques to use include—Organizational Modeling and the Roles and Permissions Matrix
  3. Activity Flow: these models represent a sequence of actions or events, or a certain path that may be followed. Techniques to use include—Process Modeling and Use Cases Diagrams
  4. Systems Models: these models focus on certain features or functions of an enterprise or solution. Techniques to use include—Business Capability Analysis, Functional Decomposition, and Prototyping
  5. Data Models: these models represent the characteristics of and the exchange of information within an enterprise or solution. Techniques to use include—a Data Dictionary, Data Flow, Diagrams, Data Modeling, State Modeling, and Interface Analysis

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.

[caption id="attachment_8114" align="alignnone" width="279"]Visual Modeling Telephone catalog use case diagram[/caption]

When to use:

  • To highlight specific process steps with a high level of detail
  • To represent a project that has specific, well-defined functional requirements
  • To represent project actors that are easily identified and defined


  • Does not work well with large systems
  • Diagrams are backed by use case descriptions, which comprehend main and alternative flows and can be complex and hard to follow
  • Not well suited to capture non-functional requirements
  • User Interface (UI) elements are not usually reflected in the description

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.

[caption id="attachment_8115" align="alignnone" width="342"]Visual Modeling Website wireframe[/caption]

When to use:

  • To define features that are very rich in UI elements (buttons, slides, controls, etc.)
  • To provide a valuable source of feedback on the usability of an in-progress website
  • To identify how well a content management website will accommodate content growth


  • Can lead to design as only a colored-in wireframe (dependent on designer)
  • Too much time being spent trying to obtain a high-fidelity wireframe

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:

  • To clearly document and communicate to stakeholders the processes in a project
  • To exclusively focus on the actions of the users, rather than the actions of the systems
  • To showcase activities within a process that can be easily delineated
  • To receive feedback and identify bottlenecks within the process


  • May become too cluttered and difficult to understand if the processes are too complex
  • Cannot easily represent continually changing processes
  • Cannot easily represent a multitude of consecutive decisions required in the process


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.