Requirements vs. Non-Requirements: Where the Analyst Ends

Let’s talk about requirements — what they are, why it’s worth understanding them, and why we should separate them from the rest of the project’s information. At first glance, this might sound like philosophical hair-splitting, but I’ll try to show that it actually has practical value — especially in cases where the role of an IT analyst is misunderstood (which happens more often than you’d think). And to explain that properly, we’ll need to start from a broader perspective.

The global understanding of what an IT business analyst is supposed to do on a project is vague. A quick scroll through job postings from different regions is enough to see it. And then there are related titles that sound like synonyms but aren’t quite: systems analyst, product owner, requirements analyst — and so on.

The IIBA (International Institute of Business Analysis), which attempts to standardize the profession, lumps all of these under the “business analyst” umbrella and defines the role in the most abstract terms possible: analyzing organizational needs and developing solutions. According to that view, a BA could be someone writing user stories all day — or a business architect working on strategic-level decisions.

I personally don’t find the “business + systems analyst” hybrid (popular in Russia and some other regions) to be the most effective model — I’ll touch on that later. So I tend to lean toward the IIBA’s broader approach, especially since it’s more widely adopted globally. Under that model, a business analyst is someone who, as mentioned above, helps define solutions to business needs. If those solutions fall within the IT domain (one of the perspectives described in BABOK), then we’re talking about an IT business analyst — someone whose job is to support the development of an IT solution in response to an organization’s needs.

That definition is still broad and open to interpretation, even with IT as the defined scope. But traditionally, the role of an IT BA is centered around requirements analysis — figuring out and shaping the requirements for a chosen solution. When I say “traditionally,” I mean this is the most common expectation — but you should still read job descriptions carefully. Even if the role is explicitly labeled “IT BA,” the actual focus may fall anywhere on the spectrum from high-level organizational analysis to hands-on writing of system requirements. And yes — that spectrum is wide.

Most often, the emphasis is indeed on requirements. But to get to those, you’ll often have to dig deep into the organization and its stakeholders. That’s why understanding what is and what isn’t a requirement (not always obvious, especially for junior analysts) can help in several ways:

1) You’ll gain clarity on what’s likely to be your main focus in most roles labeled “IT Business Analyst.” Let me clarify a couple of caveats:

• That’s assuming this doesn’t directly contradict the expectations at your specific workplace. But the truth is, employers often don’t really know what to expect from a BA. Understanding where a BA’s responsibilities end and someone else’s begin requires mature and well-defined processes — and those aren’t always in place. Sometimes, you’ll be hired and told to “just do your magic,” and then it’s up to you to shape the process. That’s exactly where the ideas in this article might come in handy.
• I’m not arguing that project roles must have rigidly defined boundaries. Collaboration between roles is great, and I’m all for the idea that you can (and should) agree on who does what. But those agreements should be situational — not the default way of working. You still need a starting point and a clear understanding of your own scope and responsibilities.

2) For recruiters and process designers: you’ll get a clearer picture — and perhaps gain more realistic expectations — of what an IT BA should be responsible for (and what they shouldn’t). Like any role, business analysis is a specialized discipline — a way of assigning certain types of work to someone whose skillset fits that domain, freeing others to focus on their own areas of expertise. So if your BA ends up designing databases (which is something your developers, DBAs, or solution architects are trained for), you have to ask: why are you assigning that responsibility to someone whose core competencies lie elsewhere?

So far, we’ve established a few things:
a) Business analysts suffer from inconsistent expectations across different regions and employers.
b) In most cases, the core responsibility of an IT BA is working with requirements for IT solutions.
c) Understanding what constitutes a “requirement” — and what doesn’t — helps analysts, recruiters, and managers determine which tasks belong to the BA and which should be handled by someone else.

Let’s begin with a simple question: What is a requirement? We’ll take a look at several definitions and try to unpack them.

BABOK v3 (IIBA):

A usable representation of a need

In other words, someone (or something) has a need, and a requirement is how that need is expressed in a way that can actually be used. A bit vague — but it’ll do for a starting point.

CPRE Glossary of Requirements Engineering Terminology (International Requirements Engineering Board) v. 1.0.0:

• A need perceived by a stakeholder
• A capability or property that a system shall have
• A documented representation of a need, capability, or property

Let’s also throw in a very similar set of definitions from the IEEE:

IEEE Standard Glossary of Software Engineering Terminology (Institute of Electrical and Electronics Engineers):

• A condition or capability needed by a user to solve a problem or achieve an objective
• A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, or specification
• A documented representation of a condition or capability as in 1 or 2

Now, let’s highlight a few meaningful differences. The IEEE uses “user,” while IREB prefers “stakeholder” — which is better, since not all stakeholders are end-users. That makes the definition broader and more inclusive. The first two points from both sources provide a solid foundation for understanding what a requirement is. To fine-tune this further, let’s consult Karl Wiegers — not a formal standard, but widely respected in the field:

Karl Wiegers & Joy Beatty, Software Requirements, 3rd Edition:

A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.

This aligns well with the previous definitions, so let’s explore all of them together.

As you probably know, there are different types of requirements. I won’t go into the full taxonomy, but here’s a simplified structure based on BABOK, Mr. Wiegers, and some of my own tweaks — focused specifically on software/IT solutions:

From the first group of definitions — “a need perceived by a stakeholder” — we’re clearly talking about business needs. Personally, I recommend making a distinction between “needs” and “requirements”, but even if you treat requirements as expressions of stakeholder needs, it’s a good starting point.

This aligns with business requirements — what the organization (or its representative, usually the sponsor) wants to achieve with the upcoming change. For example:
“Reduce document handling costs by 20% within a month.”

That also leads us directly into the next layer — stakeholder requirements: what stakeholders need in order to reach those business goals. For instance:
Mary, the secretary, needs to be able to create documents in electronic format, and the document creation process needs to be fast.

The second group of definitions points to another kind of requirement — the third layer in the hierarchy:
A capability or property that a system shall have.

This is where we’re already talking about a solution — meaning we’ve gone through the process of analyzing possible options (in our case, IT-based, since we’re talking about IT BAs), selected the optimal one, and are now describing its functional expectations. So if the solution is a custom-built web system for document management, then we’re looking at solution requirements — what the system must be able to do, or how well it must behave.

What else useful about requirements can we draw from BABOK?

One concept I really like there is Business analysis information. The key point behind this term is that a BA doesn’t work with requirements alone, which is obvious. A BA deals with layers of information, and the part that’s valuable for their tasks is business analysis information — the information that supports business analysis on the project.

Business analysis information refers to the broad and diverse sets of data that business analysts analyze, transform, and report.
Examples include elicitation results, requirements, designs, solution options, solution scope, and change strategy.

Here’s what to take away:

a) Besides requirements, a BA handles a sea of other information (for example, describing the AS IS state — current process descriptions, domain actors, or current system flaws “requirements” doesn’t really fit; requirements are aimed at the TO BE state).

b) Requirements are part of this information.

c) Requirements are the most valuable subset of business analysis information since, as we described earlier, refining requirements is the BA’s main focus.

At the same time, considering that besides business analysis information there is other information in the project, all these “informations” can be roughly illustrated like this:

Key points from the picture:

a) The concepts of Business analysis information and Requirements, plus how they relate.
b) The fact that there is other “information”:

• Project information — this is the domain of the project manager or whoever actually fulfills that role. The BA’s focus is on the target solution, not the project of developing it. The BA is responsible for a clear understanding of what the target solution should be in terms of its functional and non-functional content. The project manager handles the activities of implementing that solution — timelines, budgets, team, resources, processes, etc.
• Designs — the “engineering” aspects of the solution. How the development of the solution per the BA’s requirements will proceed. This includes development decisions like technology stack, architecture, coding standards, database structure, and so on. Basically, the technical details of how the solution will be realized.
• Other stuff — for example, testers also obviously have their own information base and decision area.

c) The relationship between Requirements and related information (project and technical). As you can see, the boundaries aren’t clear — these areas overlap. This is the difficulty in separating requirements from non-requirements, with all the consequences discussed at the start of this article. We’ll try to unpack this further.

Let’s begin by imagining an ideal, crystal-clear project process, where all typical project roles exist, each with clearly defined boundaries of work and responsibility, and those don’t overlap. This isn’t about efficiency — development trends toward tighter collaboration and teamwork, which is great. Still, as I mentioned at the start, such clarity is needed at the beginning — after that, mature professionals will figure out how and where to collaborate or even substitute for each other.

In this perfectly spherical vacuum process:

• The BA = requirements and the path leading to their elaboration.
• The project manager = overall control of everyone on the project to develop the solution based on BA requirements.
• Developers and their variations (architect, front-end, back-end, DBA, build engineers, etc.) = designs (technical solution aspects).
• Testers = quality control of the solution.

If we take the picture above as a base, everything looks neat. But there are two problems:

1) Not all employers believe this is the “correct” role division. For example, in setups where there are business and system analysts (popular in Russia and some neighboring regions), the business analyst covers part of the IT BA work described earlier — roughly everything up to the solution requirements (the first two levels). The system analyst handles solution requirements and, interestingly, part of the designs — partially doing developer work, usually architectural issues. It seems system analysts struggle to separate themselves from developers without “on-the-fly” agreements.

2) Not everyone knows or can clearly tell whether something is a requirement, project info, or a design. This often causes questions like “Why am I responsible for this if it’s someone else’s job?” or “Why did you do my work and think for me?”

If we base ourselves on the idea that the BA is responsible for requirements and it is their default boundary, then we need to precisely understand where requirements start and end. It’s easy to see they ideally start at business requirements level, but where to stop to avoid slipping into project or technical details (designs)? The tricky part is that the definition “A capability or property that a system shall have” doesn’t give a black-and-white answer. For example, isn't the database structure a system property and therefore a requirement? Is a piece of code a system property?

Here, I suggest adding to the definition the well-known classification of requirements and understanding that solution requirements (which fit that definition) can be functional and non-functional, plus transition requirements by their side. Knowing these types and what they include makes it easier to see where to stop to avoid non-requirements. Functional requirements describe system functions and behavior within those. Non-functional requirements characterize functional requirements, mainly as quality attributes (reliability, security, performance, usability, etc.). In other words, solution requirements are mostly useful characteristics from the stakeholders’ perspective, describing behavior, information, and qualities in a working, value-delivering solution. Database structure is not a useful/valuable characteristic for stakeholders — it’s a building block seen only by development-side stakeholders during development. That’s the boundary between the BA’s focus and the developers’.

Separating requirements from project information is generally easy: requirements characterize the target solution, project information characterizes the project to develop it. Examples with comments:

Separating requirements from technical details (designs) can be harder, but let’s explore. Beyond the “useful solution aspects VS development aspects” or “what VS how” concept, another useful question is: Is there a project role more competent and focused on this domain? If yes, probably these are implementation details and the role is the implementer. If not, cooperation is needed.

Examples with comments:

That’s the picture overall. I welcome comments (for example, in my channel — https://t.me/itmineba), since I understand that role specifics can differ.