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.

Visual Modeling

Telephone catalog use case diagram

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

Limitations:

  • 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.

Visual Modeling

Website wireframe

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

Limitations:

  • 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

Limitations:

  • 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

Conclusion

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.

Oana Corpade

Oana Corpade

Oana Corpade is an IT Business Analyst for 3Pillar Global in Cluj-Napoca, Romania, and has been in this position for the past two and a half years. She has skills in business analysis, testing, quality assurance, requirements analysis, agile methodologies, test cases, user acceptance testing, and integration testing. She is also a Certified Scrum Product Owner. She holds a Master’s degree in Information Technology Project Management from the Academia de Studii Economice din Bucuresti.

Leave a Reply

Related Posts

3 Topics We Should Be Talking About at BrainstormTech Our 3Pillar clients, regardless of industry, share one common trait - they need help strategizing, designing, and delivering revenue-generating digita...
4 Reasons Everyone is Wrong About Blockchain: Your Guide to ... You know a technology has officially jumped the shark when iced tea companies decide they want in on the action. In case you missed that one, Long Isl...
3 Cloud Optimization Projects That Will Pay for Themselves i... AWS introduced 1,430 new features and tools in 2017, including 497 in the 4th quarter alone. This means that it can be a challenge for even the mos...
The Connection Between Innovation & Story On this episode of The Innovation Engine, we'll be looking at the connection between story and innovation. Among the topics we'll cover are why story ...
Go Native (App) or Go Home, and Other Key Takeaways from App... I just returned from my first WWDC. I feel like I learned more in a week at Apple’s annual developer’s conference than I have in years of actually dev...