4. Business Analyst

The primary role of a Business Analyst (BA) in a software project is to assist the BSME to understand and document the business requirements in a way that the rest of the project team can use.

In a large organization, a Business Analyst can sit within IT or a business department, depending on how IT is integrated with the rest of the organization. They will be a key contributor in requirements and design workshops, acting as a bridge between non-technical customers and technical designers and developers.

Their first main responsibility is to gather the requirements from the BSME, as well as other sources such as ordinary and power users, IT users, and system administrators. This is formally called requirement elicitation, which can be summarized in four steps:

One of the more advanced techniques used by Business Analysts is modeling. This could be process modeling, which simplifies a typical business process in order to make it easier to understand, or data modeling, which rationalizes complex datasets so that it can be represented and illustrated in a summarized format.

There are various structured methods of modeling. Since the purpose of modeling is to represent, illustrate, clarify, and communicate complex concepts, there are standards in place so that the industry as a whole uses a common language.

Unified Modeling Language (UML) is the most comprehensive standard for modeling. It's widely used in software, as well as other industries, and has been approved by the International Organization for Standardization (ISO).

On the other hand, entity-relationship (ER) modeling is most often used to model data. In essence, it is a logical database schema that defines the pieces of data required and how they are connected to each other.

From experience, the humble flow chart is most often the go-to format for models. It's versatile, and easy to consume and produce, especially if you're a flexible Project Manager who is filling in as a Business Analyst out of necessity!

As the Project Manager, you should facilitate a discussion between your project team to ensure the choice of modeling language fits the most people. It's a common pitfall that the Business Analyst unilaterally chooses how they model, often because they have a personal preference and expertise. However, it's counterproductive if the rest of the project team does not understand the models produced!

This is why the humble flowchart is often a safe choice, especially in a large-scale software project involving many team members and stakeholders, because it's easily and commonly understood by most people without the need to study modeling. In a positive way, it's the lowest common denominator that connects people and supports their collective understanding.