What is Business Analysis?

Delivering an unparalleled business analysis connects software development projects with primary business objectives. By uncovering conflicting expectations, recommending solutions, supporting continuous improvement and focusing on strategic planning, business analysis professionals are integral to any digital transformation.

Essentially, the business analysis process is a part of the System Development Life Cycle. Based on requirements and client information, it results in a digital solution that is feasible, applicable and coherent.

Who Are Business Analysts?

Business and software development are two entirely distinct worlds, which, even worse, often speak different languages. A business analyst's job is similar to one of a translator, who helps find a common language between the software industry and the client.

Business Analysts work closely with stakeholders, end-users, project management, and the development team to identify business needs and requirements, translate them into technical specifications, and ensure that the software development project meets the key objectives.

These well-rounded experts possess a mix of technical and soft skills, including analytical skills, technical expertise, communication and leadership skills, and decision-making skills. Overall, they play a crucial role in the success of software development projects by ensuring that the software solution aligns with the business goals and objectives.

Semantics Aside! Let's Clear Up Your Potential Confusions

The constant battle between terms such as "business analyst", "technical business analyst", "IT business analyst", or simply "IT analyst" unnecessarily complicates the understanding of the software development world. Although in our software agency, we lean more towards the former and the latter, let's just say that all of these job titles describe the same role.

Moreover, defining the role concisely is not an easy task. Business Analysts and Product Owners collaborate closely enough in agile projects, adding to the overall confusion. Although the boundary is indeed flexible, and there are projects where the role of the Product Owner is taken over by a Business Analyst (or vice versa), the two are clearly distinct.

Good Business Analysis Process – What Does it Consist Of?

A well-prepared business analysis should be precise, define the project's scope well, fulfill the requirements, etc. But what does it all mean in practice?

The first important thing to realize is that a successful business analyst serves not only the client but also the project team: quality assurance professionals, testers, programmers, graphic designers, and architects. Each person observes the project and understands the requirements from a different perspective, so they all need a slightly different set of information.

The second point is that no methodology can guarantee that a good business analysis will be performed. Methodologies help structure information and manage requirements, but do not replace practical experience and critical thinking. In the business analysis profession, the practice of asking the right questions and translating the data into factual and consistent documentation is paramount.

But first things first…

Types of Requirements

Reading requirements can be challenging. Not because they are poorly written, but because they often use concepts closely related to the customer's business and processes.

A lot also depends on whether a completely new system is to be created or whether the requirements relate to modifying an existing solution.

Interpreting the requirements is a no-brainer for the client, but not for the analyst.

The business analyst usually focuses on functional requirements, and how the system should be created or changed in order to meet the new needs of the particular project or the organization.

But in order to frame that solution, the technical requirements considering security, system performance, UX or, in our case, the engagement team should also be lined up in documents.

How to Do a Proper Research?

It's easy to forget that the requirements and documentation provided by the client are not the only sources of information about their own business requirements.

Firstly, the customer's research – what, how, and to whom are they selling. Then it is worth looking at other companies that operate in a given industry, their business models, and what tools they use.

It is also worth finding out, at least briefly, whether there are legal acts specific to the client's activity, e.g. banking regulations in the case of banks. This point is significant in the case of projects dealing in the public sector, where apart from legal acts defining a given institution's operation, there are also legal acts concerning systems created for the public sphere.

For example, in the case of Poland, specifically the Regulation of the Council of Ministers of 12 April 2012 on the National Interoperability Framework and the Act of 4 April 2019 on digital accessibility of public entities' websites and mobile applications.

All this information makes it possible to determine the environment in which the system operates or will be modified.

How Business Analysts Deal With Clients

The research carried out earlier has great importance. If it's properly conducted, the business analyst is aware of the environment in which the system operates or is to operate. More importantly, the business analysis plan is coherent with the client's basic concepts.

By having a reference point in the form of previously acquired knowledge, it is easier to develop a common language with the client to describe the technical implementation part of the requirements.

What if you need to present a solution to the client and make him aware of the advantages and limitations of the proposed solution? Well, as Richard Feynman said:

if you can't explain something in simple terms, you don't understand it yourself.

Showing off technical terminology may be impressive, but it absolutely does not bring us any closer to finding common ground. Simple language and presentations based on mock-ups can make life a lot easier and, above all, avoid misunderstandings when approving the project.

Why Well-Written Business Analysis Documentation is So Important

The situation is more difficult with documentation. On the one hand, it must clearly and precisely describe the solution that will be implemented. On the other, it must contain information needed by testers, programmers, and the UX team.

Of course, there are different schools and methodologies for keeping analytical records, but specific rules remain the same.

The client will expect a description to relate to his business processes and requirements. The key here is a clear and orderly description supplemented with graphic elements (screen mock-ups, diagrams).

Programmers will need information on the system's behaviour to user activity, the scope of the required data, information about the result of the operation, and the method of managing authorisations to specific functionalities.

The UX team will need information regarding the list of views of their content, whereas testers will need clear criteria that will allow them to check the test cases successfully.

The Importance of Teamwork in Business Analysis

Whoever has promised their client a simple-on-paper but head-wrecking in reality solution, be the first to throw the computer mouse.

Therefore, analysis is teamwork because it is the programmers who know the limitations of technology, which forces them to look for other ways to reach the requirements. They can also indicate alternative paths of processes that must be defined in the documentation.

Testers can often spot gaps and formulate phrases that are not clear enough. Graphic designs provided by the UX team constitute a vital element complementing the description of the functionality. Everything together must add up to a coherent concept that will receive the customer's approval.

Conclusion

As businesses expand and the world becomes more interconnected, business analysis skills become more critical than ever. No other applied research discipline has the potential to help reduce project costs, increase production speed and efficiency, further business outcomes, and create cost-effective, value-driven solutions for employees, customers, and end-users of all kinds.