Business and Systems Analysis

Analyzing the various problems an organization may face can take multiple forms, depending on the context in which it is performed. Based on the actual subject of the analysis, the most common terms used are business analysis and systems analysis. While the former focuses on elaborating business needs—which may result in solutions consisting of both IT and non-IT components—the latter is IT-oriented and primarily produces specifications for developing new systems or modifying existing ones.

Business analysis outputs do not necessarily need to reach the IT department at all—this is the key factor that differentiates business analysis from systems analysis.

Differences

A business analyst usually starts with a high-level business problem, such as: "With the increased volume of orders, payment processing is becoming very slow, which causes order delays," and analyzes how the organization needs to change to solve it. In other words, the BA recommends possible solutions to help the business meet its goals. In the example above, the BA evaluates whether the process itself is inefficient or if it is the payment system that slows everything down. After that, the BA outlines possible solution alternatives and evaluates them with stakeholders. BAs are not usually asked to design integrations between systems, nor do they create database models or user interface specifications. More often, they evaluate and improve processes and translate business needs into solution requirements. They act as a liaison between business stakeholders, such as management or end-users, and the implementation team.

A systems analyst, on the other hand, does not focus as much on the business drivers behind the requested system. The SA needs to be aware of and understand them, but their responsibility is to determine the capabilities of a particular system rather than to analyze the missing capabilities of the entire organization. For example, a BA might find that from a system performance perspective, the speed of payment processing is fine. Instead, the delays are caused by flaws in the engine that pairs payments with orders—too many payments are not paired automatically and are left for manual processing. The BA understands the problem and, together with the payment officers, designs two new pairing rules that will reduce manual processing by half. These two rules represent the input for the systems analyst. Since the rules are to be implemented in the payment system, the systems analyst takes these rules, analyzes the IT impacts, and prepares a specification in a format that enables developers to implement the change. So, even though the SA understands the business problem that created the need for these rules, she simply accepts them as they are and proceeds with the implementation without further deep evaluation.

Business analysis determines how an organization needs to change to meet its business needs.

Systems analysis determines how a specific system or the overall IT architecture needs to change to meet business goals through IT solutions.

Although there are apparent differences between these two types of analysis, they overlap so much that it is difficult to clearly define where business analysis ends and systems analysis begins. Sometimes, business analysts also perform basic systems modeling to verify a proposed solution. Conversely, systems analysts may be required not only to design the system but also to verify whether it truly provides value to the organization and supports business goals. Since both types of analysis require very similar skills, they are often carried out by a single person. For all these reasons, the line separating business analysis and systems analysis is not sharp. However, this does not really matter. Your goal is to deliver a solution, not to deliberate over whether you are performing business or systems analysis. Your primary objective is to bring value to the stakeholders.

It gets even more complicated when looking at how organizations name analysis roles. Although "business analysis" is a widely adopted term, the specific role performing it is named differently across various organizations. A "business analyst" is simply anyone who performs business analysis, regardless of their official job title. Therefore, business analysis tasks are often carried out by business architects, enterprise analysts, process analysts, product managers, or requirements engineers. Because of the overlap, smaller companies especially often do not create two separate roles; in these organizations, it is very common to see a "technical business analyst" role, where one person is expected to possess skills from both worlds.

The more technical analysis roles do not have a unified title either. Throughout the industry, you may encounter names such as: systems analyst, IT analyst, IT business analyst, business systems analyst, technical business analyst, or applications analyst/specialist. All these roles are generally expected to be more technical than a standard business analyst, but as stated above, the specific job title is not what matters. What is important are the skills that enable analysts to solve business problems.

SYSTEM VS. APPLICATION

It may also be confusing whether a systems analyst is the same as an applications analyst or specialist. In general, a system is something different from an application:

System	Application
A class of software that provides services to other software.	Software that is primarily designed to be used by people.

Although systems can have a user interface, applications are primarily intended for human use. Systems tend to be more complex, serving multiple purposes and providing services to applications as well as other systems. It is therefore natural to distinguish between frontend applications, which users interact with, and backend systems that process data and execute transactions. However, for the sake of simplicity, let's assume that these terms are interchangeable.

Typical Responsibilities and Activities

Even though there is no sharp line separating business and systems analysis and many activities are shared between them, at the opposite ends of the spectrum, the activities differ:

Examples of business analyst activities:

• Facilitating meetings with stakeholders to understand business goals.
• Describing and analyzing business goals.
• Evaluating business processes and proposing changes.
• Defining in which systems business requirements will be realized, along with the expected impacts on those systems.
• Specifying system features from a user perspective.
• Analyzing business rules and algorithms.

A business analyst has deeper knowledge of the business domain and the organization's business architecture. They help achieve business goals primarily, but not exclusively, through IT systems.

Examples of systems analyst activities:

• Facilitating meetings to understand system requirements.
• Analyzing and evaluating requested changes to IT systems.
• Discussing system changes with architects to ensure alignment with the overall IT architecture.
• Developing specifications to enable solution implementation.
• Overseeing implementation, coordinating tests, and evaluating the released solution.

A systems analyst has deeper knowledge of technology, the company’s IT architecture, and the architecture of specific systems. They are also often responsible for technical design, such as defining system components, designing databases, or specifying system interfaces. They perform these tasks independently or in cooperation with systems architects.

Analysis and Agile

Agile software development is an approach that favors a progressive strategy in the modeling and implementation of solutions. It aims to reduce the risk of delivering something that does not provide value by minimizing upfront analysis and design. This approach produces only the minimum number of artifacts necessary for implementation and delivers them "just in time," moving the specification phase as close to development as possible. A key characteristic of Agile is a strong focus on collaboration between the development team and stakeholders, often utilizing lightweight and user-friendly analysis and modeling techniques. We suggest reading more about Agile, for example, on Wikipedia and becoming familiar with the Agile Manifesto.

In the traditional software development process, analysis is a specific phase of the project lifecycle, typically performed at the beginning of the project. After the project kick-off, someone interviews stakeholders to understand what they want to solve, selects a solution, designs it, and hands it over to developers, who then implement it according to the specification:

There are two main issues associated with this traditional "waterfall" approach. First, in most cases, several requirements change before the specification is even completed, leading to more or less rework. Second, it is nearly impossible to describe the entire solution upfront; as a result, stakeholders often come up with new requirements and modifications as soon as they see the first version of the solution. While prototyping can help, if the prototype does not become part of the final product, it can be seen as a waste of effort. For these reasons, agile analysis is not a single phase or task. In Agile, analysis is incremental, meaning the entire solution does not need to be analyzed at once but is instead specified in small chunks that are implemented shortly thereafter. It is also highly iterative. High-level analysis is not separated from low-level system design; instead, these activities rely on one another. While high-level requirements serve as input for the system design, design decisions and constraints may, in turn, influence the requirements. By combining lightweight techniques—such as whiteboard sketches or informal diagrams—with an emphasis on collaboration and personal communication rather than producing volumes of documentation, agile analysis offers a modern, effective, and highly recommended approach.

Agile also changes the traditional way of structuring implementation teams. Traditional teams consist of highly specialized roles, such as analysts, developers, testers, or project managers. Agile, on the other hand—even if it remains a somewhat utopian idea, especially in large corporations—prefers to compose teams of cross-skilled individuals, often referred to as "T-shaped" people. Such individuals are able to analyze business needs, read or even write code, perform testing, and present and verify the solution with stakeholders. While such a team of "superheroes" is undoubtedly the most effective possible, such people are also costly and rare. This topic is outside the scope of Effective Analysis and Documentation, yet we would like to elaborate on this issue further in the next section.

Dedicated Analyst

Having a team of "T-shaped" individuals who possess the skills not only to develop a solution but also to manage requirements has led some Agilists to the idea of eliminating the specialized analyst role altogether. In other words, all team members become analysts to some extent. While this may work on certain projects, it would be dangerous to adopt this practice universally. At first glance, it makes perfect sense: the broader the skills of the team members, the less information handover is required, and members can support one another more effectively. It is indisputable that having such individuals in a team is a great benefit. A team composed of people who possess business knowledge, can define business needs, transform them into technical specifications, and also write code is a dream. Individuals who can "suit up" to facilitate meetings with top management, understand their goals, and then describe a solution in an implementable format are immensely valuable. This results in less documentation handover, making the entire development process less error-prone and more efficient.

So far, so good. But in reality, it is not that simple. Acquiring all the necessary T-shaped skills requires significant effort, and only truly dedicated individuals reach this level of seniority. It takes time to become a skilled professional analyst, and very few "rock star" analysts can also work proficiently with code. People simply cannot be top-notch in all areas; with "generalizing specialists," there is always a risk they will become a "jack of all trades, master of none."

It is certainly a plus when a systems analyst also understands the business domain and its needs. Only then can they validate whether their solutions align with business goals and provide value to stakeholders. The same applies to business analysts. Becoming an excellent business analyst requires extensive experience and training in both hard and soft skills. A business analyst with polished facilitation, presentation, and negotiation skills—who knows every company product, process, and decision-maker—may never fully grasp complex SQL queries or the technical intricacies of core systems. Furthermore, in large enterprises, the sheer volume of information makes it impossible for one person to master a complex business domain while simultaneously understanding the IT architecture, let alone the detailed design of every system.

On the other hand, it is essential for business analysts to stay up to date with current technologies, understand fundamental architectural concepts, and have a general knowledge of software engineering. This helps them foresee technical issues in the early stages of a project, make better decisions, and earn more respect within the development team. While we would always prefer to work with highly skilled T-shaped people, it remains—and likely always will be—pure science fiction to expect a developer in a large corporation to commit code, swap their Linux t-shirt for a well-fitted shirt, and then go analyze a massive regulatory requirement. They simply do not have the necessary skills for it, and frankly, they don't need them. Most developers enjoy coding, are excellent at it, and have little interest in negotiating with business stakeholders.

Prefer systems analysts who possess both business knowledge and a strong technological background.

Prefer business analysts who are subject matter experts in their domain and can propose solutions that not only bring value to stakeholders but are also efficient and verified from an IT perspective.

To sum up: embrace Agile and prioritize T-shaped individuals. However, given the vast amount of knowledge and skills required, combined with increasingly complex business domains, it is unlikely that dedicated analysts will disappear. In fact, the opposite is more likely to be true.

Conclusion

There are two distinct types of analytical activities on the path from defining a business problem to implementing the final solution, each requiring different skills, techniques, and tools. While it is essential to understand these differences, do not waste time deliberating over which one you are currently performing or what your job title should be. Until you actually write source code, it is all analysis—it simply depends on the perspective. What you really need to know is which activities you are supposed to perform, what qualities you need to possess, and what outputs you are expected to deliver. For these reasons, we will use the general term "analysis" to refer to both business analysis and systems analysis & design.