Developing modern apps for financial markets – Part 2: Business Analysis

Many people ask me about Business Analysis – what is it really about? What do Business Analysts do – not only at GFT, but in the IT industry in general? Even recruiters can sometimes confuse the role of a BA with a Financial Analyst! I’d like to explain all of this in simple terms, using the example of Commodity Overview App (check out Part 1 of our series). Business analysis was a very important area of its development, and I am quite proud to have contributed to it – let me tell you how it all worked.

The Role of Business Analyst

Let’s start with the basics: what is Business Analysis in the context of an IT services provider? In essence, it revolves around collecting, analysing and managing business requirements, and compiling them appropriately for developer teams. In practice, it means that a Business Analyst is person who talks to internal or external clients and gathers all knowledge and know-how necessary for the successful delivery of software. This allows them to elicit requirements using specific techniques, for example those mentioned in in the quintessential BABOK (Guide to Business Analysis Body of Knowledge), such as brainstorming, workshops or interviews.

Afterwards, a BA lists their findings and adjusts the method of creating documentation for an individual project – using not only text but also diagrams, tables or mock-ups. Crucially, these elements must be understandable for all stakeholders. They may be positively or negatively impacted by a project, and therefore may want to have influence over it. That is the theory.

Now you may want to check out our video below, as it describes the entire development process behind Commodity Market Overview in brief terms. 

It’s time for a more detailed look at the BA’s activities during the development of our app – after which you will hopefully obtain a clear understanding of the role of Business Analysis.

Understanding of Business and Goals

Let’s imagine that you, dear reader, became a Business Analyst. Firstly and most importantly, you must understand the business. Does it sound like a cliché? Perhaps, but it is also very true, especially in our area. I was engaged in many projects where people failed to really grasp the background of a certain task – and this, in the long term, caused many misunderstandings. As mentioned, a BA is responsible for gathering and writing down all requirements for a given solution, one that will be under development for the next few weeks – or even months! Proper understanding and establishing relevant context is the foundation for this work and, like all foundations, it must be solid. Such an authentic business perspective involves understanding high-level requirements. In our example, we had to find a business case which would reflect the following goals:

• Provide high quality sales material that demonstrates the wide skill set of GFT Poland as a Delivery Centre,
• Demonstrate the end-to-end process of delivery, starting with analysis and UX engagements, through development and to testing – all based on a realistic business case study,
• Show the project’s lifecycle,
• Deliver an interactive, user-friendly application,
• Demonstrate a real business case, which is possible to develop at a low cost.

Business Case Justification

We set out to research the Financial Market and try to find an area that would cover all of these points. There were many ideas such as Forex Market Visualisation or Personal Finance Management for retail customers, but finally we decided to prepare a solution for analysing the Commodity Market. There were several reasons for this decision:

• Commodities are an important part of everyday life, for example: any car owner can be significantly affected by rising prices of crude oil,
• It is a useful business case for individuals: private and institutional investors,
• It can be visualized in an attractive manner,
• There is a wealth of verified and readily available data on the subject (updated monthly),
• It is understandable for potential clients,
• It is relatively easy to develop.

Stakeholders Cooperation – Scope Forming and Requirements Gathering

Now, let us get back to your next challenges as a BA. Now that you have a good case to work with, what comes next? The general concept should be translated into a set of features which will be then discussed with the Client and your Team. You can organise a brainstorming session to discuss all functionalities with UX, DEV and QA members of the team and work on the initial idea of the system’s interface. In our example, it meant a lot of meetings, discussion, workshops, sketches on whiteboards – which finally led us to a huge array of interesting ideas and solutions. At this point, as a BA, you should prepare high-level requirements. In the case of our Commodity Market Overview app, these were:

• Display different commodities/groups of commodities indices at a glance or in detail,
• Use different data filters,
• Form your own list and compare – support for a custom list where different commodities and indices can be added or removed,
• Display forecasts for selected commodities,
• Display and compare index composition charts.

Functional and Non-Functional Agile Requirements Breakdown

Once the high-level requirements are done we then prepare Epics and User Stories– they will be helpful for UX developers to prepare visuals, and for software developers during implementation works.

An Epic can be defined as an individual significant part of the project that has one common goal. This can be a function, a customer’s request or business requirements. It does not have to contain all the details that the team must work on. These details are defined a User Story.

A User Story is the way of defining requirements according to scrum methodology and has the following structure:

As a < type of user >, I want < some goal > so that < some reason >.

Using simple terms, it shows what the user of the system really needs. To make it more specific, you should also prepare Acceptance Criteria for every User Story – these are sets of conditions that make the solution acceptable for the user. Take a look at our example:

As a user, I want to 
have a range filter
so that
I can choose a different date range and analyse commodity prices in different time periods.

Acceptance Criteria:

The user can choose the range on the tab: 

• 1 Month, 
• 1 Quarter, 
• 1 Year,
• 3 Years, 
• 5 Years, 
• Max – User can see the maximum available range for the index/commodity,
• Custom – User can set date range between two dates. As a default value, the user sees a year in the past.

It must be said that in many cases, the Business Analyst acts as a Proxy Product Owner. This means supporting the client in this role by preparing requirements, managing backlog, setting priorities and representing the client for the development team.

BA–UX Cooperation

After preparing Epics and User Stories, you as a BA, together with UX members of the team hold a brainstorming session, which allows UX specialists to prepare initial sketches, and then high quality visuals. (We’ll explore this in detail in Małgorzata Barska’s part of the series!). All BA and UX artefacts created as a result of this enable the start of the development part of the project. Let’s take a look at how our User Story was finally implemented in the application:

BA Project Lifecycle Support Role

This is the moment when a BA should verify and validate the requirements. What is the difference between these actions?

• Validation: Are we building the right system?
• Verification: Are we building the system right?

From our point of view, it means:

• Does it fulfil our requirements?
• Does it work exactly as described in the User Story and acceptance criteria?

The answer to these questions allows you to understand whether, apart from meeting the assumptions, the solution also meets the actual business need.

In our case, we naturally changed a few things during the development phase, however the majority of features turned out exactly as we envisioned. This, I believe, is a good demonstration of what can be achieved thanks to proper collaboration between specialists from different areas – BA, UX, QA and Developers – throughout the entire lifecycle of a project.

See you next week in Part 3, where Małgorzata Barska will talk about our UX expertise and its role in developing the app!

Part 1 – A Case Study by Damian Sosnowski
Part 2 – Business Analysis by Marcin Myszkowski
Part 3 – The UX Process by Małgorzata Barska
Part 4 – Architecture and Development by Damian Sosnowski

The Team

Business Consulting

Joanna Aleksandrowicz Principal Business Analyst, Head of Business Consulting Job Family
Marcin Myszkowski Senior Business Analyst

User Experience and Design

Małgorzata Barska Principal Designer, Head of UX Practice

Architecture and Development

Damian Sosnowski Principal Architect, Head of Digital Job Family
Damian Bachórz JavaScript Developer
Michał Dzik JavaScript Developer

Marketing

Maciej Sopek Senior Content Marketing Specialist