Visual Models Used by Business Analysts
Today we’re going to go through 22 different models BAs use
in their work. You may not be aware of all 22 of them, so even if you’re
familiar with a few, keep your eyes open for new ones you can use.
While it will be unnecessary to use every model for every
project (the samples are drawn from experience across 10 years of BA work in 6
difference companies), the more models you know, the more likely you’ll be able
to apply the best model to keep the requirements process moving faster in the
situation you find yourself in.
#1 – Activity Diagram
What They Do: Activity Diagrams break the process down in
detail and are great for being sure you don’t miss any steps. They are good
complements to use cases since they provide a visual picture of the text
describing the basic, alternate, and exception flows.
What They Look Like: An Activity Diagram illustrates the
steps a system undertakes to deliver an outcome and the procedural logic
required to proceed through those steps. Activity Diagrams can be completed as
a workflow diagram or in a more formalized version in UML notation.
#2 – Business Domain Model
What They Do: 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.
What They Look Like: 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.
#3 – Competitive Comparison Matrix
What They Do: Competitive Comparison Matrices compare the
current state or a potential future state of a product or system to that of an
organization’s competitors. This kind of understanding can help significantly
with prioritization as it clears up what requirements are important to gain a
competitive advantage or simply catch up in the marketplace.
What They Look Like: Competitive Comparison Matrices can be
presented in many different forms. They often include a list of competitors on
one axis and a list of features on the other. Then each box in the matrix is
filled in to identify the competitor’s offering for each feature. In the
real-world sample provided in the Pack, we developed a matrix/roadmap
combination that fits easily on one PowerPoint slide.
#4 – Data Flow Diagram
What They Do: A Data Flow Diagram illustrates how
information flows through, into, and out of a system. They are especially
useful when evaluating data-intensive processes and looking at how data is
shared between systems or organizations.
What They Look Like: Data Flow Diagrams show the data
sources, data processes, and data stores. The BABOK® Guide identifies two
formal notations for representing data flow diagrams: Yourdon and Gane-Sarson.
It’s possible to create an informal data flow diagram as well, which typically
takes the form of a workflow diagram.
#5 – Data Model
What They Do: While the Business Domain Model illustrates a
high-level representation of the information managed by an organization, a Data
Model goes deep into the database structure. Mapping data and creating new
tables or attributes often has a direct impact on reporting and other system
functionality. Even while this is a more technical model, your business
stakeholders often have many relevant concerns.
What They Look Like: Most Data Models contain a matrix of
attributes that helps your development team know exactly what data fields to
create, along with their associated data types and allowable values. In other
situations, a Data Model includes a mapping from one information source to
another.
#6 – Evaluation Criteria and Recommendation Summary
What They Do: Evaluation Criteria and Recommendation
Summaries are useful when evaluating off-the-shelf software, comparing
potential vendors to engage, or even in preparing to interview job candidates.
They will help you gain clarity on what your options are and make decisions
from the information instead of untested opinions.
What They Look Like: Evaluation Criteria list specific ways
that a potential solution will be evaluated to determine if it’s desirable or
acceptable to stakeholders. A Recommendation Summary provides supporting detail
to back up a recommendation, ideally made based on previously agreed to
Evaluation Criteria. Both Evaluation Criteria and a Recommendation Summary are
often organized visually for ease of scanning, review, and comparison.
#7 – Feature Brainstorming Mind Map
What They Do: You know that early stage of the project when
everything is fuzzy but you absolutely need to get something down on paper? You
need a way to keep ideas organized while keeping it easy to add new ideas and
other relevant information. That’s a perfect scenario in which to create a
Feature Brainstorming Mind Map – this visual model captures ideas from your
stakeholders when it’s not yet time to invest in a detailed scope statement.
What They Look Like: A Feature Brainstorming Mind Map
contains a central node for the project or product under discussion and a
branch for each high-level area of exploration. Ideas, concerns, and feature
requests can be captured and linked back to each branch.
#8 – Feature Matrix
What They Do: Have a complex set of features to track
against? Looking for a simple requirements tracking tool to manage your BA
work? A Feature Matrix can be used to analyze, rank, and assess the
architectural impact of multiple features, or track other attributes that are
important to your project.
What They Look Like: A Feature Matrix lists each high-level
feature in a row of a spreadsheet. Then, columns are added to capture critical
pieces of information, such as a feature description, priority, state, and
risk. Each box is filled in with appropriate information for each feature.
#9 – Feature Prioritization and Stakeholder Matrix
What They Do: Oftentimes different stakeholders are needed
for different parts of the project. They may also have competing priorities
that need to be reconciled. AFeature Prioritization and Stakeholder Matrix is a
specific type of Feature Matrix that addresses both concerns.
What They Look Like: For this type of Matrix, each feature
is listed as a row in the spreadsheet with columns for each corresponding
stakeholder and individual priority assessment. An additional column can be
used to roll up priorities and with a simple calculation you’ll have useful
information for establishing an organization-wide priority assessment.
#10 – Feature Roadmap
What They Do: A Feature Roadmap can be used to show how your
project investments have and will yield demonstrable value to the business.
They are useful for high-level summaries given to top executives and boards of
directors.
What They Look Like: A Feature Roadmap contains 4 boxes –
one for your past state, one for your current state, one for your target future
state, and one listing the benefits of attaining the future state. Each box
contains 2-3 short bullet points. Graphics can be added to emphasize key
elements.
#11 – Navigation Map
What They Do: A Navigation Map helps you keep the big
picture perspective on how the user interface flows. I often review a
Navigation Map before starting a wireframe for a new screen. With stakeholders,
a Navigation Map is a useful tool to set the stage for user interface or use
case reviews.
What They Look Like: Essentially, each screen in the system
is represented by a box. Lines with arrows connect the boxes together and show
how the user can navigate through the screens.
#12 – Organizational Chart
What They Do: An Organizational Chart represents the
organizational hierarchy in place for an organization or a part of an
organization. Organizational charts can be used as part of stakeholder analysis
or to model new work groups to be created as part of responding to
organizational change.
What They Look Like: Organizational Charts typically contain
a box for each employee. Lines are used to connect managers to direct reports
and show the functional hierarchy in place within the organization.
Organizational Charts can be created at multiple levels of granularity and may
show departments, teams, functions, or individuals filling specific roles.
#13 – Performance Report
What They Do: A Performance Report shows the results from a
project, project phase or business activity. Looking at past data can help
stakeholders make faster and more informed decisions about next steps, ensuring
that the organization is learning from its own activities and results.
What They Look Like: Most typically, a Performance Report is
captured as a matrix. Each line represents an important element of the project,
phase, or activity. Columns are used to identify appropriate metrics. Boxes are
filled in with measures for each element.
#14 – Process Flow Diagram
What They Do: 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.
What They Look Like: Like Activity Diagrams, Process Flow
Diagrams exist in multiple forms. Most BAs create simple workflow diagrams that
show the end-to-end business process. A
smaller subset of BAs use BPMN (Business Process Modeling Notation) to create
more formalized diagrams. (We’ve included examples of both in the Visual Model
Sample Pack.)
#15 – Process Improvement Progress Report
What They Do: When we improve a business process, we expect
to see results. But how do you communicate the changes and results to
executives? Commonly, a list of bullet points is created to identify changes
and improvements. Taking a more visual approach, a Process Improvement Progress
Report visually shows improvements made to a business or technical process as
the result of a project.
What They Look Like: A Process Improvement Progress Reports
contains models of the past, present, and target future states of the process
and uses visual cues, such as color codes, to show the changes.
#16 – Scope Model
What They Do: The fundamental question to answer in many
projects is what is in vs. out of scope. A Scope Model is a visual
representation of the features, processes, or functionality in scope for a
specific project, solution, or system.
What They Look Like: Scope models can take many forms and
how you decide to put one together is typically driven by what project factors
are driving scope. Technical integration requirements are typically represented
by a System Context Diagram (more on that below). Business needs are typically represented by a
high-level business process. Feature-driven projects, such as a product for an
end user, are often accompanied by a visual representation of functionality.
#17 – Stakeholder Map
What They Do: A Stakeholder Map is a visual diagram that
depicts the relationship of stakeholders to the solution and to one another.
Stakeholder Maps visualize the temporary structures put in place for a project
to show who is responsible for what and how different artifacts get reviewed,
approved, and ready for implementation.
What They Look Like: A Stakeholder Map is a lot like an
Organizational Chart, except that it lays out the temporary team structure put
in place to run a project instead of a permanent structure to run an
organization. It can be very useful in clarifying stakeholder roles and
responsibilities and identifying gaps in your business analysis plan.
#18 – SWOT Analysis
What They Do: When stakeholders are stuck figuring out how
to solve an issue, whether that’s a minor issue in the project or a strategic issue
facing the organization, a SWOT (Strengths, Weaknesses, Opportunities, and
Threats) Analysis can clear the air and pave the way toward improved decisions.
What They Look Like: A SWOT Analysis contains 4-boxes, one
for each of the four elements (Strengths, Weaknesses, Opportunities, and
Threats). Within each box, bullet points are used to list appropriate
information.
#19 – System Architecture Diagram
What They Do: A System Architecture Diagram identifies the
system components and how they interact as part of the solution. This can help
you figure out how to best organize the detailed requirements. It can also help
you communicate the constraints of the solution to business stakeholders or
help them see why particular requirements need to be addressed.
What They Look Like: A System Architecture Diagram contains
an element for each key piece of technology. Lines are used to connect
interconnecting or integrated components. Visual hierarchies can be used to
link technical components to user-facing features.
#20 – System Context Diagram
What They Do: In today’s world of integrated components,
it’s difficult to work on one system without impacting others. A System Context
Diagram is a useful tool for confirming scope with business and technical
stakeholders and ensuring you address all necessary integration requirements in
your analysis.
What They Look Like: A System Context Diagram contains a
central box for the primary system and additional boxes or circles for each
potentially impacted system. Lines are drawn to identify integration points and
specify what type of information is passed from one system to another.
#21 – Use Case Diagram
What They Do: A Use Case Diagram is useful on a project with
many use cases to get the big picture of who is using the system and what
functionality they can execute. The diagram can be used to establish context
before an individual use case review meeting or to confirm the functional scope
of a system.
What They Look Like: A Use Case Diagram is a UML (Unified
Modeling Language) diagram that shows the actors, use cases, and the
relationships between them. Actors are represented by stick figures, use cases
by ovals, and relationships by connecting lines.
#22 – User Interface Wireframe
What They Do: 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.
What They Look Like:
UI Wireframes, also often called Prototypes or Mock-Ups, can vary in
fidelity, or the degree to which the presentation of the UI 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.
