By Julien Nov 1, 2022

Business Analysts: More Than Meets the Eye

The emergence of new technologies and digital transformation has forced many professions to evolve in order to adapt to new business processes. The position of business analyst (BA) also followed suit. Nowadays, BAs even help develop new custom software.

What’s more, business analysts now work in collaboration with both the product owner and the developers, a task that requires specific skills, including communication, listening, transparency and flexibility (thanks in particular to the Agile approach, which is explored by Karine in this article).

Since the role has evolved (and will probably continue to do so), it’s common to come across people who don’t have an accurate understanding of what a business analyst actually does. With that in mind, I wanted to provide you with a bit more insight on the role of business analyst by drawing parallels with another well-known profession: detective. Just as detectives are called to gather evidence, business analysts are tasked with unearthing crucial information, i.e., the product owner’s needs. And like any detective worth their salt, Uzinakod uses very specific investigative techniques to achieve this goal.

Step 1: Interrogate the witnesses – Gathering requirements

The most effective way to identify and understand the client’s needs is to ask them about their business processes directly. The business analyst therefore organizes “analysis meetings” with the solution’s end user to pinpoint the requirements and challenges that lie ahead.

Interviewees shouldn’t be expected to know the solution’s specifics and configurations. It’s up to the business analyst to highlight these unstated needs in order to ensure that the solution meets the client’s functional and business requirements.

The analyst can also take advantage of these meetings to propose innovative solutions that will allow users to complete their tasks in a more intuitive and efficient way.

Step 2: Share the facts – Prioritizing

Following these analysis meetings, all parties should (and must!) have a clear understanding of each feature’s order of priority.

Just as investigators submit evidence to people who weren’t present at the scene, analysts share their findings with clients and developers to expand everyone’s knowledge concerning the features. They also use these findings to advise users and propose a list of priorities.

As for developers, they determine which feature should be developed first by highlighting the various technical dependencies.

Investigation - Business Analyst

Step 3: Describe the suspects – Writing user stories

We’re now at the stage of writing user stories. These are used to define the feature in the simplest and clearest way possible. We therefore use the method “As a […], I want […], so that […]” to define the feature and its purpose from the point of view of a specific end user.

Let’s use an everyday example to illustrate this process: “As a soccer player, I want cleats so that I have more stability on a wet field.” The soccer player is the user, the feature is the new cleats, and the goal is to gain more stability on a wet field.

In addition to defining the concept, it’s necessary to further detail the elements waiting to be developed. Often, mock-ups — or any other visual support as explained by our colleague Audrey in this article — are also created to provide a better picture of the feature to clients and the development team.

Finally, the business analyst takes care of writing acceptance criteria, which aim to define the limits of the feature’s scope.

If a feature is more complex and technical, the business analyst will call upon a technical expert to clarify the user story and/or assist in its creation. Contrary to the developer, the business analyst is responsible for validating the feasibility of a technical solution.

Step 4: Review the facts and the suspects – Validating test scenarios

Once these various user stories are written, meetings between the analyst, the quality manager and the developer may need to be organized before work can begin. At Uzinakod, we call them “3 amigos” meetings.

These aren’t the type of meetings where we debate which fajitas/nachos combo is most delicious (they’re all great) but rather test scenarios for the story in question. It’s an opportunity to review the story and identify possible issues down the line, including those yet to be considered.

Collaboration between different team members is essential, as it allows for the definition of a clear solution understood by everyone involved.

Furthermore, it’s during these discussions that we validate the understanding of the user’s needs and requirements. The business analyst should always be available to answer questions from developers or any other stakeholder involved in the development of the feature.

Step 5: Identify the suspects – Supervision of the user acceptance tests (UATs)

Lastly, the business analyst creates a User Acceptance Test (UAT) document, which includes the different tests related to the developed feature. End users have access to a “Test” platform where they’re given the opportunity to try the feature out using various tests suggested by the analyst.

It’s then up to the end users to carry out these tests thoroughly and in accordance with their expected daily use to make sure that they’ll be capable of performing all required tasks. If any problems should arise, users can report them in the UAT document by offering a thorough description. The business analyst must then sort these requests with the quality manager and, if necessary, question the user for more details.

Following this, possible modifications, additions or corrections are made to the feature in order to best meet the needs of the end user.


As you can see, business analysts rarely work alone! In fact, the best way to meet user expectations is by talking and interacting with the various people involved in the project throughout the development phase.

Whether it’s the developers, project manager, product owner, quality expert or other analysts, business analysts can always count on the help of project collaborators and stakeholders. Since teamwork is of the essence, it’s a privilege for me to work for a company like Uzinakod!

Do you have a digital project in mind? Our team of investigators is always up to the challenge. Contact us now!

Recommended Articles
Published on July 25, 2022

A Mock-Up Is Worth 10,000 Words

When speaking of mock-ups in the software industry, we often refer to pixel-perfect versions created by graphic designers. Interestingly enough, mock-ups are often more visually attractive than the end product. Yet for a Business Analyst, a functional mock-up is a communication tool that gives clien

Read more
Published on July 30, 2021

Project Management at Uzinakod: Waterfall Model or Agile Approach?

Project management in IT development is an important issue in many companies. In software development, the Waterfall model has been used since the 1970s. From the early 1980s-1990s, the term Agile was already being used as a transformation concept in companies. Iterative methods started being applie

Read more
Search the site
Share on