Modelling. Part 2

Models as an effective tool for business analysis


There is a large number of different models and different notations. But how can we understand, which notation and model are suitable for a particular project?

First of all, it is necessary to understand what purpose we are pursuing while intending to build a model, how can it help us and what results we want to obtain after its creation. 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 company 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. In order to do this, we need to go through the following checklists of the conditions for usage these or those diagrams and choose from them those that are suitable for our project.

1. 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 the 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.

 2. Context Diagram.

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

Use this diagram when it’s required:

  • To identify the external entities, with those 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.

3. 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 datastores, 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.

4. 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 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 business system.

  • To describe the workflow between users and the system.

  • To simplify and improve any process by clarifying complicated use cases.