Business Analysis – How To Do It the Right Way For Beginners

Bored of lengthy, over-the-top 4000-word long guides on the Internet? Welcome to “From Hero to Zero” – our beginner-friendly series that will explain complex concepts in less than 10 minutes of reading time. 

Whenever you feel like getting lost in the world of software estimation, feel free to read the next article in our series.

What is Business Analysis?

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. Simply put, delivering an unparalleled business analysis connects software development projects with their primary business objectives.

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 “IT Analyst”, “Business Analyst” and “System Analyst” complicates the understanding of the software development world. Each role is slightly different, but what you need to understand for now is relatively simple. A professional who leans more towards business would be named a “Business Analyst”, while those who have more to do with systems (technical infrastructure) are known as “System Analysts”. “IT Analyst” is more general and may refer to both.

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.

Finding the right person for a good software estimation is usually the first challenge to overcome. At hero/dot, we got you covered!

Good Business Analysis Process – What Does it Consist Of?

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

The first important thing to realise 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. Interpreting the requirements is a no-brainer for the client, but not for the analyst.

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

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

But to frame that solution the technical requirements considering security, system performance, UX or the engagement team could 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.

Moreover, much is to be learned from existing solutions and competitors by analysing patterns, trends, and user preferences. Therefore, it’s worth looking at other companies that operate in a given industry, their business models, and what tools they use. That practice is especially useful for new businesses and startups to lay a foundation for new winning products.

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. However, we will leave this complex topic for some other time.

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.