Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide (Part 1)

2025-06-21 20:14 Business analysis

Let’s talk about requirements.

This article will, to some extent, repeat points from my earlier posts. However, I believe it’s helpful to bring everything together in a single, accessible guide — one that allows you to see the coherent big picture. The emphasis here is on how to mentally structure and gently fall in love with that picture — which, in my view, is a critically important skill for any analyst.

While the article is mostly aimed at beginners, I’m confident that even seasoned analysts will find a few gaps in their understanding to fill. Where appropriate, I’ll also include links to other posts that dive deeper into specific topics for more advanced readers.

Let’s start with the basics: Business Analysts in IT (and not just IT) work with requirements. That’s not all they do, of course, but ultimately, requirements are the central point around which their work revolves. Systems Analysts, if that role exists in your world, also work with requirements — perhaps different types (though not always), but still within the overall picture we’re going to examine. In other words, if you reduce the responsibilities of all IT analysts to a bare minimum, it boils down to this: define and deliver a high-quality set of requirements to the development team — requirements for what kind of IT solution needs to be built for the client.

If you’re not yet familiar with business analysis, here are a couple of key concepts that will appear throughout the article:

Solution — This refers to what the development team is going to deliver in the course of the project. If we’re asked to build a new piece of software, the solution is the target software system. If we’re asked to upgrade an existing product, the solution is an enhancement to system X. More broadly, the solution might be a hybrid of software, hardware, and human processes — or even something completely non-IT (if we take a broader view of business analysis). For instance, hiring new team members or implementing more efficient internal workflows on the client’s side can also be a solution. The analyst focuses on the solution (in a project, the analyst is the owner of knowledge about the solution the team needs to implement). In contrast, the project manager focuses on the project — the people building the solution, the resources, deadlines, processes, and so on.

Stakeholder — A person or group of people with related the solution. This is a simplified definition, but sufficient for our purposes. It includes the client (who’s paying for the solution), users (who will use the solution), the development team (including us, the analysts), the government or regulators, and others. The solution affects all these entities in some way, or they, in turn, influence the development and implementation of the solution.

Our first step in this journey is to understand what “requirements” are and what counts as a requirement — which is not as simple as it may seem. The full picture only starts to come into focus as you gain hands-on experience working with them. In essence, this is about defining the core scope of our work as analysts — what we need to focus on, and what areas we should approach with caution. The key thing to internalize is that “requirement” means different things in different companies and teams. This directly impacts the responsibilities of analysts, depending on how the work is structured and how roles are divided within the project team.

Let’s begin with a couple of well-known definitions of “requirement”:

BABOK: A usable representation of a need.

That’s... okay, but let’s find something a little less abstract.

IEEE 610.12-1990:

A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a solution or a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
A documented representation of a condition or capability as defined in (1) or (2).

That’s more helpful. Now, let’s translate that into Human:

A stakeholder has a need in the context of the project — something that helps them solve a problem or achieve a goal.
Something the solution must contain, since there's a need for it.

That’s basically all you need to get started. These two aspects cover all types of requirements. And they are closely related: the second flows naturally from the first. That is, the solution must include whatever stakeholders need to ultimately be satisfied. So the core job of an analyst is simple (conceptually):

Understand what all the relevant people and organizations need from the project.
Ensure the solution is designed to meet those needs.

The tricky part comes in identifying the edges of what counts as a requirement. For example:

Are the client’s financial goals for the solution requirements?
Is the system’s database architecture a requirement?
Is the user interface a requirement?

You’ll find different answers depending on the team and context. Later I’ll present a generalized view of how these questions are typically answered — but keep in mind that teams vary in how they define and handle requirements. Where it’s relevant, I’ll point out that interpretations may differ. If you want to go deeper into this topic, I recommend reading this article — it’s aimed at those interested in advanced business analysis. For any analyst, one of the most important skills is learning to clearly identify the boundaries of the requirements space for the specific context you're in. This will help you avoid internal doubts like, “Should I even be getting involved in this?” You’ll know which parts are your job, and which are better left to other domain experts on the team.

Also, requirements are essentially about someone needing something from the solution. And it’s important to keep that idea clearly in your mind. For example:

A description of how the client currently works — not a requirement.
Business rules currently in force (from the client, industry, or government) — not requirements.

This doesn’t mean analysts shouldn’t study such information — on the contrary, it’s often essential. But that information is supporting context. It helps us formulate high-quality requirements but is not a requirement itself. Requirements are always aimed the target solution.

Let’s now explore how requirements can be classified, how to understand the different types, and why this specific structure is used.

If you’re new to this, here’s a heads-up: there’s no single universal classification that everyone agrees on. Several models exist, each with varying levels of popularity. Be prepared for the fact that a term you use might mean something slightly different elsewhere — that’s just the reality.

That said, since BABOK is the most widely recognized standard in the field of business analysis, we’ll use its classification as our base and then expand on it as needed.

According to BABOK, there are three main levels of requirements:

Business Requirements
Stakeholder Requirements
Solution Requirements, which further split into:

Functional Requirements
Non-Functional Requirements

There’s also a related, auxiliary type: Transition Requirements. And this is also the order in which requirements are usually developed, which we’ll explore further in the following sections.

Business Requirements:

Business requirements answer the question: “Why does the customer need the solution?” The customer, in this context, is the one financing the implementation of the solution. So, we can rephrase the question as: “Why is the customer willing to pay for the solution? What’s motivating them?” It’s crucial to begin with this point because we should start any project by focusing on what’s being paid for — and on satisfying the person funding it. Everything else — other people’s needs and "nice-to-haves" — comes second.

At a minimum, business requirements are expressed as goals (commonly referred to as business goals) that the solution helps the customer achieve. In more advanced cases, a business analyst may break these down further, adding levels (more specific goals or , success criteria, and other clarifying details). However, no matter the format, the goal is to answer the fundamental question above. Figuratively, all business requirements should sound like: “The customer is willing to pay money in order to…”

Let’s look at some examples with varying focus:

You’re buying a microwave for yourself

✅ Enable food reheating.
❌ Buy a microwave.
This is a classic mistake: “implement a solution to implement a solution.” The requirement should reflect motivation, need, or the ultimate business effect — not describe a specific solution. Otherwise, we prematurely limit our analysis and miss possible alternatives (e.g., buying a gas burner, stove, or even building a campfire — all potentially valid solutions).

A mass-market product: a thermometer for extreme temperatures

✅ Earn $1,000,000 in product sales within a year.
❌ Provide the market with a unique thermometer.
This doesn’t reflect the customer’s motivation. “Provide” for what purpose? Is the customer really investing just to altruistically gift something to the market?

Software system: A web app for ordering office lunches

✅ Increase employee satisfaction with the company by 50%, as measured by a survey within six months of release.
❌ Enable office lunch ordering.
That’s a requirement of the next level — something important to users, not to the one funding development.

Each of these examples reflects the customer’s motivation to varying degrees (you as a consumer, a startup founder, or someone responsible for implementing the office food service system).

Where to look:
Technically, any stakeholder can contribute to identifying business requirements, as they may hold useful contextual knowledge. But in most cases (read: with higher probability), the core of this information lies with the customer — the person financing the project — or their appointed representative.

How to develop:
You can dive deeper into the topic here, here, and here, but let’s outline the key points:

The stage of business analysis aimed at defining business requirements is called Strategy Analysis or Discovery.
Many project teams, consciously or not, skip this stage and these types of requirements. The attitude is often: “It’s not the peasant’s job to question the lord’s motivations — he pays, and that’s enough.” Sometimes that approach is fine. Other times, it's dangerous.
High-quality business requirements begin with a clear understanding of the business needs of the customer. These needs eventually evolve into business requirements.

What they look like:
Business goals (ideally SMART) documented in a Vision and Scope document, or as separate pages/entries in Confluence or whatever system the analyst uses to store requirements.

What happens if you ignore them:
If the customer neglects or sloppily handles business requirements (and we shift that responsibility onto them), it’s a potential disaster: the team may build something that doesn’t actually serve the investor’s true goals — either in part or entirely. Imagine you go to a doctor and say, “I want procedure X.” You're the customer, and X is the solution you’re requesting. If the doctor doesn’t ask why you need it — doesn’t challenge your assumption — and just writes the referral, is that actually valuable? Sometimes yes, but not always. In IT, the stakes are higher: ignoring motivations can mean burning a huge budget. If analyzing customer motivations is within the scope of the provider's services, but the analyst skips it, consequences can be extremely negative. And even if the contract doesn’t give the customer grounds to complain (like the doctor example), the overall perception of the project may still be extremely poor.

Next level: stakeholder requirements. Why do these come next? Let’s think it through: to achieve the business goals, what must we do? Eventually, we realize: to meet business goals, we must deliver a solution that solves the problems of key stakeholders or aligns with their needs and expectations. For example, to earn money from a mass-market product, the product must 1) satisfy users and 2) comply with marketplace and legal requirements. This logic is consistent: to fulfill business requirements, we must fulfill stakeholder requirements.

A helpful analogy here is Impact Mapping. At the first level of the impact map, we articulate the business requirements. The second and third levels answer:

Who can help or hinder goal achievement? (≈ stakeholders)
How do we want to change their behavior to help achieve the goals? (≈ their requirements)

Stakeholder requirements are expressions of what individual stakeholders need from the solution. They focus on their personal needs. In practice, most stakeholder requirements are actually user requirements, as users are a major category of stakeholders (aside from the customer). Some methodologies even equate this level with “user requirements.” While that’s not necessarily wrong, keep in mind: not all stakeholders are users. In earlier examples, we had other types — marketplaces, government agencies, etc. Still, our primary focus will usually be on future users of the solution.

Stakeholder requirements describe:

The tasks users should be able to accomplish with the solution.
Any other expectations or conditions stakeholders may have.

The key question: “What do users and stakeholders need from the solution? What should it allow them to do, and how should it behave?” (Always keeping in mind the business goals it supports.)

At this point, it’s important to understand: stakeholder requirements are a bridge between business requirements ("what the customer wants to achieve") and solution requirements ("what the team must build"). Solution requirements (the next level) are direct derivatives of stakeholder requirements. While the stakeholder says: “I need X from the solution,” the resulting solution requirement will state: “The solution must include feature A, parameter B, property C.” Sometimes these will closely resemble the original stakeholder requirements. Other times, they’ll be more technical or detailed. Either way, stakeholder requirements are intermediate — they exist primarily to produce solution requirements. Once that happens, they serve little independent purpose.

Let’s look at some examples again:

You’re buying a microwave for yourself

You:
✅ It should heat food.
✅ It should be able to fit large dishes.
✅ It should be convenient to use.
❌ Given the auxiliary nature of stakeholder-level requirements, it may seem like it’s hard to make serious mistakes when formulating them — the main thing is to capture them as fully as possible. However, there is a general guideline: don’t descend to the level of solution requirements at this stage, and don’t talk to stakeholders in those terms. When a stakeholder says (or when you phrase a question to them like): “The solution should include…”, they’re not expressing their actual need/motivation — they’re describing what they believe the solution should contain. And it’s important to always remember that in the abstract vacuum of "designing solutions", it’s the analyst and development team who are responsible. To craft great solutions, we must understand the stakeholders’ needs and motivations.

The microwave should have a digital interface. The manufacturer might fulfill the stakeholder-level requirement “It should be convenient to use the microwave” in different ways. For example:
The microwave should have a digital interface.
The microwave should have a voice interface.
This is precisely why we avoid limiting ourselves or the client by prematurely describing how exactly a stakeholder-level requirement will be met. Instead, we phrase it in terms that reflect the stakeholders’ motivation, rather than the “I need X to be in the solution” mindset.

A mass-market product: a thermometer for extreme temperatures

Users:
✅ It should be able to measure temperatures ranging from -100°C to +100°C.
✅ It should be convenient to use in extreme conditions.

Client (yes, clients can also have these requirements — not answering “Why am I investing in this product?” but rather “What do I want from the solution to meet business needs?”):
✅ The thermometers should be visually branded so it’s always clear who made them.

Government:
✅ All thermometers must comply with standard X and pass certification Y.

❌ The thermometer should have a large button so that it’s easy to press while wearing gloves at the North Pole. (Here, again, we’ve prematurely dropped from stakeholder needs to the level of specifying the actual solution.)

Software system: A web app for ordering office lunches

Users (employees):
✅ I want to be able to order food during working hours.
✅ The food should be delivered to my desk.
✅ Ideally, I wouldn’t have to pay myself — the cost should be deducted from my salary.
✅ It’s important that other employees can’t see my order history.

Users (payroll department):
✅ We need to be able to access complete information about employee orders and their costs.

Development team:
✅ It should be easy to update menu prices in the system, as this will need to happen often.

❌ The system should allow exporting orders as Excel files.
❌ Access to the system must be via HTTPS. (These are again examples of dropping to the level of solution requirements prematurely.)

Where to look:
Ideally — from future users and all other relevant stakeholders. But you must realize that access to them may be limited. A client may take the stance: “Work out the solution details with me — don’t bother the end users; I know what they need.” And sometimes, like with mass-market products, it may be objectively difficult or impossible to reach end users, because the product is aimed at an open market rather than a known user base.

This is far from ideal, and the analyst should make an effort to engage real end users or their representatives. But in practice, the client may end up being the sole voice for these requirements — even if they don’t plan to use the system themselves. This carries substantial risk at this level (e.g., delivering something that doesn’t meet users’ actual needs), but isn’t necessarily catastrophic. For some projects (usually small or simple ones), it may be enough to rely solely on the client — though keep in mind they may unintentionally distort actual user needs.

How to develop:

Identify stakeholders as thoroughly as possible. Determine who among them may have requirements that are important to capture. Segment users into categories based on similar characteristics — for instance, by the types of tasks they’ll perform using the solution. Don’t forget indirect users (those who use the system via intermediaries) and non-human users (e.g., external software interacting with your system via API).
Engage identified stakeholders (not necessarily all of them — just representative and accessible ones) and extract their requirements using interviews, surveys, observation, and other techniques.
While gathering these requirements, use a checklist of solution-level requirements to ensure completeness. Since stakeholder requirements will eventually “evolve” into solution-level ones, it makes sense to use the latter as a checklist to avoid overlooking anything when working at this level.
Present user-facing stakeholder requirements in the form of User Stories or Use Cases. For example, a User Story Map can help you structure user stories, and a Use Case Diagram can visualize use cases. Prototypes (early interface mockups) can also help during discussion and validation.

What they look like:
There’s no single standard here. Since these requirements are auxiliary — they’re just a foundation for solution requirements — analysts typically store them however is most practical. Possible options:

Not stored at all: stakeholder requirements are extracted, immediately converted into solution-level requirements, and only the latter are documented.
Partially stored: Where relevant, stakeholder requirements are included within the context of solution requirements. This often happens naturally if User Stories or Use Cases are used, since stakeholder requirements are reflected in their phrasing or titles. Any stakeholder requirements not expressible this way are handled as in option 1.
Fully stored: You maintain a separate document (e.g., “Stakeholder Requirements”) or dedicated pages in a system like Confluence, grouping stakeholder requirements by source stakeholder. This can be valuable primarily for traceability — helping future team members understand where specific solution requirements originated.

What happens if you ignore them:
You can technically skip these requirements only if, for some reason, you’re jumping straight to solution requirements — e.g., asking the client “Just tell me what should be in the solution”, or brainstorming features yourself for your own product, skipping this step entirely.

The key consequence: you end up with a product people don’t use — because it lacks essential functionality, is inconvenient, slow, etc. This, in turn, undermines business goals. Addressing user needs and aligning the solution with them is a crucial responsibility of a business analyst — and for consumer products, it’s vital to survival.

Other consequences can include missing state, industry, or development/support team requirements — all of which can be overlooked if you don’t explicitly think about such stakeholders.

Moving on to Solution Requirements.

If the analyst’s ethical mission is to bring happiness to the client (i.e. to help achieve their business goals), then the primary and most labor-intensive task is to develop a solid set of solution requirements and hand them over to the development team.

Solution requirements are essentially descriptions of what must be incorporated into the solution in order to fulfill the stakeholder requirements.

If we return to the Impact Mapping analogy, this corresponds to the fourth level of the Impact Map: “what, in terms of the solution, can or must we implement to bring about the desired behavioral change in stakeholders.” This includes features the system must provide, qualitative attributes it must exhibit, types of access it must support, and so on — in short, every aspect of what the final solution should be.

Let’s recall the definition of a “requirement”:

A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a solution or a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
A documented representation of a condition or capability as defined in (1) or (2).

Based on what we already know, it’s easy to infer that the first point aligns with business requirements and stakeholder requirements: the client has an objective aimed at solving a problem, and stakeholders have needs and expectations.

The second point reflects the solution level. Though that definition is somewhat narrow in scope and should be expanded: “…and to implement what is described in point 1.” We don’t add things to the solution just for the sake of a contract — we do it primarily to fulfill what stakeholders truly need.

Just like other types of requirements, solution requirements are logical if you think about them. For many types of solutions — especially software (which, as IT business analysts, is our focus) — how can we fully describe what the solution must be, so that the implementers can develop it exactly as needed? We must describe its functionality (in simple terms, what it must do), as well as its supporting parameters — those that set the stage for functionality (qualitative attributes such as appearance, usability, reliability, etc.; methods of use; required certifications, and so on).

Of course, certain types of solutions (e.g., implementing a new business process) might require a different internal structure for their requirements. But since we are focused on software, those alternative schemes don’t concern us here.

Unlike stakeholder requirements, solution requirements are phrased from the point of view of the solution itself. That is, they can explicitly or implicitly start with: "The solution must include…,” or “The solution must be able to…”

Let’s start with the full picture of solution requirements. (This is a customized view — while it draws from popular theories, it includes practical nuances based on experience.)

Where to look (applies to all solution requirements):
Conceptually, there is no need to “find” them. As analysts, we already have the stakeholder requirements, and our task is to design a solution that realizes those needs. However, in practice, we do not work on these requirements in isolation from stakeholders. We'll continuously validate and specify how exactly to implement each stakeholder requirement with the same users and stakeholders we previously interviewed.

Let’s go over each subtype:

Functional Requirements – these are the backbone of solution requirements. They describe what the solution must be capable of doing for its users — in other words, how the solution, through its components and behavior, will support operations performed by users.

The key subtype here includes functional capabilities and their detailed behavioral requirements — meaning the solution is broken down into logically distinct features that address user needs, with detailed specifications of how each function should behave (as a response to user actions or other events).

Let’s go back to our examples:

You’re buying a microwave for yourself

Functional capabilities of the microwave:
1. Heating contents
1.1. Power adjustment
1.2. Time adjustment
1.3. Start/stop heating
2. Opening/closing the door

1. Heating contents:
1.3. Start/stop heating
1.3.1. The microwave must allow the user to place items inside for heating.
1.3.2. The microwave must enable the user to start and stop heating at a set power level for a specified duration.

A mass-market product: a thermometer for extreme temperatures

Functional capabilities of the thermometer:
1. Temperature measurement
2. Battery replacement
3. User settings

1. Temperature measurement:
1.1. The thermometer must have a button to initiate temperature measurement.
1.2. When the user presses this button, the thermometer must measure the ambient temperature.
1.3. Once measurement is complete, the thermometer must display the temperature on the screen.

Software system: A web app for ordering office lunches

Functional capabilities of the web application:
1) Authentication/authorization (log in and log out functionality; assigning user roles)
2) Order management (viewing, creating, editing, canceling orders; exporting orders as PDF)
3) Menu management (importing new menu from Excel; viewing menu)
4) Home page

1) Authentication/authorization:
1.1. When the user opens the system, it must display a login page where the user enters a username and password.
1.2. Upon login attempt, the system must verify:
A) That both fields are filled. If either is empty, the system must show: “Please enter your username/password.”
B) That a user account with those credentials exists. If not, it must show: “Invalid username and/or password.”
1.3. If the login is successful, the system must assign the appropriate role and redirect the user to the “Menu” page.

To be continued in Part Two.