Business Analysis Modeling Techniques Explained

Let’s start with the purpose of modeling in business analysis. Models help to describe a complex system distinctly, to show the relationship between the requirements, to focus on their important aspects, to visualize and to present them equally to all the parties that are involved in the development process.

A properly built model allows you to clearly explain the system or process it describes, and helps you identify ‘blank spots’ in the requirements and processes and develop an overall system structure.

But how do you know which one to choose for your project and how to build it? Let’s proceed to our tips.


 

What types of models exist?

 

You should start with the definition of the subjects that you want to display with the help of business analysis modeling - modeled entities. They can be the following:

⬥ Custom classes and roles;

⬥ Events;

⬥ Entities and connections;

⬥ Processes;

⬥ Rules.

 

And then, according to the type of the modeled entity, you use this or that model. However, there are a large number of them. For example:

⬥ Data flow diagrams (DFDs);

⬥ Dialog maps;

⬥ Process flow diagrams (such as swimlane diagrams);

⬥ Tables of events and reactions;

⬥ State-transition diagrams (STDs) and state tables;

⬥ Decision tables and decision trees;

⬥ Feature trees;

⬥ Activity diagrams;

⬥ Use case diagrams;

⬥ Entity-relationship diagrams (ERDs).

And many, many others.


 

How to choose the right type of model?

 

First of all, it is necessary to understand what purpose you are pursuing while intending to use modeling in business analysis, how it can help you and what results you want to obtain after its creation. The choice of the model depends on the type of information that you want to display, analyze or identify.

Secondly, it is necessary to know which models help to obtain this or that information. We will talk about the most popular models and about the cases when they are needed below.

The choice of the model in mobile application development occurs at the earliest stage of design, when we have received the most necessary information about the project and can already determine which model will help us in more detailed analysis of requirements and in the identification of missing information. To do this, we need to go through the following checklists of conditions for using certain diagrams and select from them those that are appropriate for our project.

 

Use Case Diagram

This diagram describes the system or the process.

In case of the system description it describes the actions of the users that are aimed at the developed system and their interactions with the system.

In case of the process description it describes the participants and their actions and interactions during the process.

Use this diagram when it’s required:

⬥ to show all the actions that users can make and want to make with the help of the system or the process;

⬥ to identify the whole functionality of the system or process;

⬥ to cover users’ expectations;

⬥ to avoid the gaps in user requirements and the shortage of functionality;

⬥ to identify any internal or external factors that may influence the system and should be taken into account;

⬥ not all user requirements are obvious and simply to identify;

⬥ the system or the described process is big and involves many actors and actions;

⬥ the whole functionality of the system isn’t clear for all the participants of the development.

 

Context Diagram

This diagram describes information flows between the system and external entities, with which it should be connected in any way.

Use this diagram in business analysis modeling when it’s required:

⬥ to identify the external entities, with which the system is connected;

⬥ to show the data flow at the high level;

⬥ to model the system in general;

⬥ to generalize the function of the entire system in relationships to external entities;

⬥ there is a data exchange between the system and other external entities.

 

 

Data Flow Diagram

This diagram maps out the flow of information for any process or system.

Use this diagram when it’s required:

⬥ to limit the scope of the system: to identify where the system finishes and the environment begins;

⬥ to focus on the flow of information, where data comes from, where it goes and how it gets stored;

⬥ to identify external entities and their relations with the system in more details than a context diagram;

⬥ to identify all the required data storages, in which the data will be saved;

⬥ to see the process as the sequence of actions of the system which are connected with the transmission and the reception of data;

⬥ to decompose the system on the subsystems and see the data flow between them.

 

 

Activity Diagram

Activity diagram is a flowchart that represents the flow from one activity to another activity. The activity can be described as an operation of the system.

Use this diagram in business analysis modeling when it’s required:

⬥ to illustrate what happens in a workflow;

⬥ to capture the dynamic behavior of the system;

⬥ to show the sequence from one activity to another;

⬥ to see what activities can be done in parallel;

⬥ to see if there are alternative paths through the workflow and in what moments the user decides what path he will follow;

⬥ to describe business processes of a business system;

⬥ to describe the workflow between users and the system;

⬥ to simplify and improve any process by clarifying complicated use cases.


 

How to build a model?

 

Modeling in business analysis, as well as programming, has its own languages, which must be studied before starting the construction of models. Each modeling language has its own notation. That is a notation system, which makes it universal and understandable for all the participants of the project. Each notation includes a lot of symbols, which are used to represent the concepts and their relationships (which makes up the alphabet of notation), as well as the rules of their usage, which must be followed. Otherwise, the idea of ​​unification of the data representation for all the participants of the process will be lost.

The most popular notations are the following:

⬥ Basic Flowchart, Cross Functional Flowchart;

⬥ UML (Unified Modeling Language);

⬥ BPMN (Business Process Management Notation);

⬥ Gane-Sarson Notation / Yourdon Notation (Data Flow and Context Diagram);

⬥ DSL;

⬥ SysML;

⬥ GUI modeling.

 

 

When can we omit the modeling?

 

However, there is no one-size-fits-all solution, and there are cases where business analysis modeling techniques aren’t needed.

The modeling process can be omitted in the following cases:

⬥ The solution is simple to implement;

⬥ The decision is fully understood by all the participants and the stakeholders;

⬥ The solution is intended for a small group of people;

⬥ The scope of the solution is permanent;

⬥ The requirements are mostly non-functional, which are difficult to visualize by models;

⬥ A representation in the form of a model is more complex and less understandable than a conventional text.

 

 

Final thoughts

 

A fast choice of the model you need comes with experience: the more you meet different kinds of diagrams and apply them in your projects, the faster the experience will come and you will quickly and accurately know which model will help you most of all. And before the time this experience comes, you can order business analysis modeling and app design from an experienced mobile application development company or be guided by various books about business analysis and modeling, which will help you in the choice of the right model. 

contacts image

Got a project in mind? We’d love to hear what matters to you

Contact us