IT Business Analyst tools for Business/System analysis and specification — Part I.

When you do some search on the internet for the words: “Business analysis tools” or “IT business analyst tools” you will get a lot of results. It can be confusing or misleading for analysts, who started their journey on this beautiful career path.

You know, each project has different tasks. Different tasks require different tools and approaches. With my article, I try to help you to understand the most common tools for analyzing and better understanding a business process or an IT system.

In my last years as an IT professional, I have often used the below-mentioned business analyst professional “tools” for business analysis.
(Of course, IT advisory or IT business analyst methodology contains dozens of others, but these were useful for me.)

We could write a whole book each one individually, but my goal is different. This article is not a reference. I will show you the best visual tools for solving problems. Use this article as a brief introduction and a good starting point for practicing system analysis and design.

1. Business Process flow diagram (BPMN)
2. Entity-Relationship (ER) model
3. Use case diagram (UML)
4. Data flow diagram (DFD)
5. Decision tree graph

Let’s deep dive in!

Basic Process flow — Webshop product order process

1. Business Process flow diagram (BPMN)

According to a report, 60% of employees find it difficult to get the required information they need for their work. The lack of process documentation leads to inconsistent results.

So, how to ensure that your employees have the information they need to work well? There is a good solution, called a business process diagram.

“A business process diagram is a standardized visual representation of a process that a company carries out to achieve the desired output. As I mentioned, it uses standardized symbols the describe each process step.”

You can use it for any process. It can help you understand how a process works allowing you to identify inefficiencies.

For implementing an IT solution, the IT delivery team must understand the business process(es) which affected by the development. As an IT Business Analyst, you should map and understand the current processes (as-is) and you have been capable to draw future processes based on the requirements (to-be).

Creating business process diagrams can

• Increases efficiency and productivity
• Reduces business costs.
• Identify automation opportunities.
• Increases transparency.
• Reduces redundancies.
• Keeping knowledge in the organization.

The 5 essential parts of a business process diagram

1. Goal or outcome.
2. Steps of the process. (Keywords: Event, activity, gateway, flow)
3. Involved departments/people.
4. Conditions or rules for moving to the next step.
5. Required tools. Hardware devices, tools, software, etc

7 steps to create a business process diagram

1. Write down the current information about the process.
2. Write down the expectation, and the desired outcome.
3. Identify gaps and gather the necessary information.
4. Define events, activities, gateways, and flow.
5. Ask for feedback from your colleagues, and fix the misinterpretations and deficiencies.
6. Assign role to the process steps.
7. Set rules and conditions.

For more information about business process diagrams or subprocesses, check out the official page -> Quick guide menu.

One step further to complexity — https://www.flokzu.com

2. Entity-Relationship (ER) model

An ERD can illustrate the logical structure of a database.

It visualizes the relationship between entities in a database and sometimes their attributes.

Entity-Relationship diagram/model can help document an existing database structure, gather design requirements or spot possible logic or deployment problems.

Of course, you can use it to design a new database.

You can draw a traditional ER model or relational schema type.

An Entity-Relationship model can help the analysts (and other team members) to

• Simple visualization, easy to understand.
• Easy to convert it into a relation model.
• Popular for high-level system database design.
• Assist the IT team members in gathering the information for the detailed phase.
• Helps explain how data will be organized in the database.

The 4 essential parts of an Entity-Relationship model

1. An entity is like people, things, objects, or concepts. For example customer, invoice, factory, product, etc.
2. A relationship defines the…exactly, the relationship…between two entities.
3. Attributes. An appearance of an entity. It can have single or multivalue.
4. Cardinality shows how many instances of an entity relate to one instance of another entity (One-one, many-to-one, many-to-many)
   (Mandatory, optional).

Types of Entity-relationship diagrams or data models

1. Conceptual. Provides a high-level view with the least amount of detail. Mostly used by Business Analysts for large projects.
2. Logical. Add more detail to the conceptual model.
3. Physical. Including cardinality, showing primary and foreign keys of entities, and listing all attributes as columns. This is the blueprint of the database with all technical details.

Tips for creating an effective ER model

1. Identify entities
   - Each entity appears once on a diagram
   - Naming, naming, naming…
2. Identify relationship types
   - Mandatory or optional? Is there any redundancy? Is there any relationship-to-relationship connection in your model?
3. Identify cardinalities.
4. Add attributes to entities

ER diagram — Displaying Doctor<->Patient relationships

3. Use case diagram (UML)

According to Wikipedia, a use case diagram specifies the expected behavior of a user’s possible interaction with the system. It defines the what, but not the how. It helps IT business analysts to design a system from the end user’s perspective.

However, use case diagrams are often undervalued in developing good software, they are simple tools to provide a high-level overview of the system.

The standard use case diagram is defined by Unified Modeling Language (UML).

The essential parts of a use case diagram

1. Actor. An actor is someone who interacts with the system. Typically playing a role in business. The actor is not a user, it is like a role.
2. Use case. The use case is a system function. (Automated or manual process). Each actor has at least one linked use case, but not all use cases are linked to actors.
3. Communication link. The connection between actors and use cases.
4. Boundary of system. One or more systems include use cases. It shows which use cases are part of a specific system.
5. Relationship.

Tips for creating an effective use case diagram

1. Use cases share different kinds of relationships. Visualizing it is the decision of the Business Analyst. Sometimes it helps better understand the dependencies but can lead to complicated visualization.
   Relationship types: Extends, include, generalization.
2. Identify actors. Who starts or shuts down the system? Who gets information from the system? Who provides information to the system? Who maintains it? What other system will use this system? Does anything happen automatically in it?
3. Identify use cases. What are the expected functions? What information will be stored? How do the actors will create, read, modify, and delete this information? Is the system should include notifications, external connections, and reports?
4. Organize. Always organize the use cases from the viewpoint of the actors.
5. Focus on the “What” not the “How”.

Use case diagram — Simple food delivery functions

4. Data flow diagram (DFD)

To put it in a nutshell, data flow diagrams represent logical information flows in an organized way.

These diagram types make it easier to show how information moves through the system and how is changed during the process.

There are two types of data flows. Logical data flow describes the flow of data through a system, the physical data flow diagram describes the implementation of the logical data flow.

Logical data flow is presented by the IT business analyst, but the responsibility for physical data flow depends on the project members. It can be created by the architect, the lead developer, the IT business analyst, or IT system analyst based on the logical specification.

A data flow diagram can help determine the physical system construction requirements and establish new system requirements.

The high level data flow diagram often referred as System Context diagram.

Benefits of data flow diagram

• Present business information on the level of the information.
• Helps IT Team understand the business, identify the reason of the new function or find gaps in the system
  (For more details: blackhole, miracle, grey hole)
• Independent from technology.
• A physical data flow diagram can be easily transformed into a logical DFD.

The essential parts of a data flow diagram

1. Process. That is where the magic happens. Processes like these box machines in your elementary math workbook. A process receives input data, processes it, and produces output with a different format or content. The process name is a verb followed by a singular noun.
   (For example: Order product)
2. Data flow. Data flow represents a single or multiple sets of data. It shows which data moving from one part of the system to another one.
3. Datastore. Places where the information is held. Most of the time, these are databases, DB tables, or file storage.
4. External entities. Provides data to the system or gets data from it. They show how our system communicates with the rest of the world.

Tips for creating an effective data flow diagram

1. Identify the main inputs and outputs. What are the inputs of the system? Who will put it into the system? What are the outputs? What is the output destination?
2. Build a conceptual diagram. Draw the identified inputs, at least one process, and the output in a single line. Connect them.
3. Expand it to lower levels. Break your processes down into subprocesses with “sub” inputs and outputs.

Level 0 data flow diagram — Data context diagram

Level 1 data flow diagram — Process context diagram

5. Decision tree graph

A decision tree graph is widely by professionals who are involved in strategy or project planning and analysis. But you can use the method for creating classification diagrams for system analysis, as well.

The main advantage of the decision tree is it is easy to follow and understand.

The essentials of a decision tree

1. Root node. The starting point. Contains questions to be answered. Every root node has two or more leaf nodes.
2. Leaf node. Child of the root node or another leaf node. Contains questions to be answered. Every leaf node has two or more leaf nodes.
3. Branch. A branch is a line between the nodes. Branch labeled with the possible answer of a parent node and leads to a leaf node (child) or an endpoint node.
4. Endpoint node. It indicates the final outcome(s).

Tips for creating a decision tree graph

1. Start with the main decision. Ask the main question.
2. Draw up the possible outcomes.
3. Connect them with branches.

Decision tree diagram

Summary

I hope you found this article useful. If you want to know more about how to be more efficient and professional as an analyst, please read my next article with more useful IT Business Analysis tools.

If you want to deep dive into IT Business Analysis, I heavily recommend you to visit the IIBA site and read the book, called “A Guide to the Business Analysis Body of Knowledge”. This will be a perfect first step in the theoretical level.