Business analyst, solution analyst, requirements analyst, or agile development roles like epic owner or product owner? What do these title holders actually do, and why are so many different titles used for very similar roles?

Solution analyst or requirements analyst – what do the titles tell us?

Work related to identifying and describing needs is a central part of successful IT development projects, but it is surprisingly difficult to find a single common concept or role name that is understood in the same way by everyone.

Some speak of requirements specification or specification, while for others the same or at least nearly the same thing is service design. In agile models, we talk about backlog refinement. This blog reflects on how the role names of practitioners also vary and provides a summary of which role should be used when.

Until a year ago, the term “business analyst” still sounded to me like a somewhat old-fashioned term from the 1990s. In the early 2000s at Big Four consulting firms, Business Analyst was a junior-level title—often the first title a consultant could receive straight after graduating. Sometimes the role is also described as solution analyst.

Agile Methods are all about specifying requirements

In agile operating models, such as SAFe, the titles business analyst or requirement analyst are generally not used at all. However, this does not mean that requirements specification is not done in agile development—quite the opposite. Identifying, refining, and prioritizing requirements are central to agile work, even though the work is distributed among multiple roles.

Agile models emphasize customer focus and specifically building product features that have the greatest need and business value. In the agile model, requirements are defined and handled by several different parties. Requirements are owned by the Epic Owner, who takes responsibility for the business needs of a specific area, a certain high-level development theme. The Epic Owner works closely with Product Owners, whose task is to prioritize the work of the agile team in a specific (technical) area.

In many organizations, however, the development model is not purely agile or traditional, but something in between. In such cases, role titles also begin to evolve. In this context, lead business analyst serves as a natural umbrella term that does not tie the work to a specific method, but rather describes responsibility and level of expertise regardless of the model.

Recently, requirements specification and related terminology have resurfaced in discussions. Especially now, as AI has streamlined coding, the bottleneck in development has shifted in identifying, structuring, and describing needs. This makes requirements specification work more relevant than it has been in a long time.

Clarity in the jungle of terms

However, the meanings of the terms, their differences, and their relationships to each other kept puzzling me, and I began to consider what these things would look like in a concept model. I am extremely fond of all kinds of diagrams and wanted to see what the terminology jungle would look like when drawn as a picture.

Final conclusions of the terms requirements analyst, solution analyst and business analyst

Thought 1:

The terms requirements analyst and business analyst at an academic level essentially mean slightly different things: a requirements analyst focuses on information system requirements and a business analyst on business analysis.

In practice, however, both of these roles are often performed by one and the same person. In such cases, it is probably a matter of preference which title is used for this person. A requirements analyst must investigate the needs of the business, i.e., the customer, so they perform business analysis as part of their work. On the other hand, business analysis can hardly be done anymore without taking a position on information systems. Organizations rarely have processes or functions that do not have any information system support.

Thought 2:

In the agile model, it is clear that Epic Owner and Product Owner are roles for experienced professionals, involving significant responsibility and decision-making.

Requirements analysts and business analysts in the traditional waterfall model often do not have quite the same decision-making authority as Epic and Product Owners in the agile model. For this reason, it may feel that these roles (requirements analyst and business Analyst) are tasks that a recent graduate could perform as their first jobs.

When we speak of a lead business analyst, we want to emphasize that the person in this role must be willing and dare to take responsibility for the requirements.

A person with the title service designer, on the other hand, does somewhat the same thing, but still slightly different from a requirements or business analyst. We have another blog of this topic!

How is it in your organization? What kinds of titles related to requirements specification do you have?