systems analyst vs. business analyst: same or different?

EPAM Anywhere’s Senior Business Analyst, Ruslan Akhmedov, discusses the difference between a business analyst vs a systems analyst in this deep dive into their project roles and responsibilities.

When asked about the difference between a business analyst and a systems analyst, I say that a business analyst is the one gathering business requirements from stakeholders with the help of different techniques. Systems analysts, sometimes called business systems analysts, break down high-level business requirements into more specific functional requirements and provide a detailed specification to the development team.

In reality, though, these two roles are more complex. Let’s take a closer look at the differences and similarities between them, starting with the problem at the core.

Software development has been around for a while now, but it has changed significantly over the past 10+ years with the emergence of the cloud. Now, at the heart of everything, there is software that needs to be developed, tested, and constantly updated after its release.

Any new software project usually starts with a description of what the stakeholders want. This is usually a mixture of the marketing vision, a description of some key features, and the desired financial outcomes.

It can come in the form of a pitch deck for a startup, a vision document ranging from 2 to 100 pages long, or just a brief statement of what the client wants, along the lines of "It's like Uber, but for dog walkers" or "I want to create Tinder for stamp collectors."

Usually, the people who come up with those great ideas think that all they need to do is to hire a bunch of coders who will make it fly within a couple of months. The reality is a bit more complicated.

To run a successful digital business, like Uber or Netflix, requires state-of-the-art (most probably microservice-based) software architecture for the backend, applications for each popular mobile platform, and a responsive website.

To make it all work, a team of specialists from different fields should be assembled, including designers, frontend and backend developers of different seniority levels, testers, and DevOps engineers. Each should be given a very specific task that they will estimate, implement, test, and deploy.

Before everybody can start working and burning through the budget, they need to be told what to do. This should be done in a very specific form that business stakeholders can easily validate and approve, and that the development team can understand at the same time, breaking it down into smaller tasks for every team member. This is where business analysts and then systems analysts come into the picture.

A business analyst (BA) usually joins the project in the discovery phase, after all the pre-sales activities are done and the contract is signed.

During the discovery phase, the BA’s goal is to understand the big idea behind the project, and the client’s business goals, desires, and expectations. To do so, the BA organizes a series of requirements elicitation workshops with stakeholders, discussions with subject matter experts, and focus groups with people matching the profiles of ‘personas’ — verbal portraits of the new software product’s potential users.

To be successful, BAs should have a good grasp of popular business requirements elicitation techniques, and mastery of approaches and tools such as business canvas, value proposition, and empathy maps to understand end users’ needs better. Business domain knowledge and experience is another crucial part of a BA’s CV, and is probably the major selling point for most employers.

BAs should also be good at interviewing people and conducting brainstorming sessions. In addition, organizing meetings, keeping notes of all discussions, and sending meeting follow-ups are a big part of a BA’s day-to-day activities — tasks that should not be disregarded as unimportant.

By the end of the discovery phase, the BA documents the business requirements and, in some cases, prepares the vision and scope document that describes the business vision and key objectives, identifies key stakeholders, and outlines the project (or product) scope and boundaries.

When the discovery phase is over, the BA joins the development team. The BA’s objective at this stage is to communicate the discovered information to the development team, fill the backlog with user stories (short descriptions of user tasks to be solved by the software product), prioritize them by business value with the product owner or the product manager, and provide further support for the development team if they have any questions.

Once a portion of the working functionality is done, the BA should conduct a series of user acceptance tests (UATs) to verify that end users and stakeholders are happy with the result of the development efforts and that all of the users’ needs are met. At this stage, the BA should also capture any additional requirements and improvements for further enhancement of the software product.

While a business analysts’ mission is to clearly communicate to the development team what should be done, systems analysts (SAs) are the ones to take those visions, statements, stories, and requirements and come up with a working solution for each of the end users’ needs.

As a rule, a systems analyst joins a project after the discovery phase, once the business and high-level user requirements are established for the first iteration of the product.

The SA’s objective is to break down business requirements into more specific functional requirements that can then be forwarded to architects and developers. In some cases, SAs propose software solutions, prepare data requirements, and document other technical details.

Unlike business analysts, systems analysts don’t communicate with the end users and the client directly. They must have a strong IT background, and knowledge of SQL, Object-Oriented Programming, and APIs, at the very least. It’s also critical for an SA to be skilled in data models and Entity Relationship and UML class/sequence diagrams that help validate and properly document data requirements.

In cases where a new solution needs to deal with some legacy code or data, or when integration with third-party business systems is required, a systems analyst will be the one to analyze data, business rules, and other aspects of those systems, and create additional requirements for the development team.

Yes, I know — the Agile manifesto clearly states that we should have working software instead of detailed specifications, and we should respond to change instead of following a plan.

Does this mean there is no more need for BAs, SAs and the artifacts they produce? Well, I would say yes and no.

No matter what project management approach you choose, the final product still needs to satisfy end user needs and help your client achieve business goals. Developers, even if they take part in business value discussions and have a good understanding of the business domain, still need some form of requirements to iterate upon. As systems become more and more complex, interaction between those systems should be analyzed and documented in order to facilitate future integrations.

Today’s business analysts and systems analysts probably wouldn’t fit the original job descriptions for those roles from 40 years ago, and the roles keep changing.

Business analysts with good communication skills and extensive domain knowledge will likely be shifting toward product manager or product owner roles. Instead of creating detailed documentation with complex diagrams that nobody understands, BAs should learn how to effectively organize requirements facilitation workshops, help clients formulate their business model and value proposition, and interview end users.

Modern BAs should also serve as spokespeople and communications managers for their development team, to make sure the whole team is productively collaborating with each other and with the stakeholders. BAs should pay close attention to end user feedback, be ready to accept criticism, and make use of modern user feedback collection tools.

Systems analysts will most probably be shifting toward system architect, solution architect or enterprise architect roles, depending on how deep they want to dive into technical implementation. Modern SAs should also have a good understanding of DevOps and be the agents of change in their teams, advocating cultural and organizational change, and facilitating cross-team collaboration on the solution level.

The discussion above makes it clear that business analysts and system analysts are quite different, not only in terms of their background and competencies, but also in terms of the aspects of software products that they deal with and their activities during different project phases.

It’s true that sometimes one person can perform both roles (in fact, this is my situation now). This does not mean that a BA is a newer version of an SA, or that an SA is a more qualified BA. Both roles are relevant and important for any kind of software product development today.

As software products become more complex, the demand for people who facilitate collaboration of stakeholders and developers will only grow. We will be seeing the BA and SA roles transform further, but the core competencies of business and system analysis will remain significant for the foreseeable future.