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

2025-06-22 10:49 Business analysis

See Part One here.

Continued example for functional requirements:

❌ A common misstep here — one that’s not particularly critical and only considered a "mistake" from the perspective of a purist analyst working within a conventional, textbook framework (i.e., it may not even be a mistake for an analyst whose responsibilities shift the standard boundaries of their role) — is crossing the line between this level of requirements and the next.

But wait — you might point out — there is no “next” level, and you'd be right. So what we're actually talking about is the boundary between requirements and design specifics.
I’ve already referenced an article that explains this in detail, but here’s a summary: based on the requirements, experts from the development team will build the solution. So how do you know when you've done your job — when you've finished defining the requirements and further details fall into the domain of other experts? Put simply: once you find yourself venturing into a domain for which there is already a designated expert on the team, you're stepping beyond the requirements space and into design territory, which is outside your responsibility.

Here are a couple of anti-examples — situations where a seemingly appropriate requirement is actually incorrect in a certain context:

If the team has a UX specialist or a UI designer, the following requirement would be invalid:
❌ 1.1. When the user opens the system, the system must display a “Login” page where the user must enter a username and password to log in.

Why is this incorrect? As an analyst, you're operating in terms of “pages” and “enter” but the concept of the UI and the way users interact with the system is not your responsibility. By framing the requirement this way, you limit the specialist’s freedom to design the most appropriate interaction model.
A more appropriate formulation would be to abstract the requirement from the UI specifics and phrase it like this:
✅ 1.1. When the user opens the system, the system must provide the user with the ability to specify a username and password to authenticate with their account.

Similarly, if the team has someone responsible for system architecture or component design, and that person isn’t you, then the following examples are also problematic:
❌ When the user confirms the login, the system must check whether a exists in the database with the user's account.
❌ When the user confirms login on the frontend, the system must send a request to the backend to verify the account's validity.

At the requirements stage, we don’t yet know how the system will be implemented in terms of components. Sure, we can clarify those things with the team — but why should we, when it’s more correct to abstract the requirements from their implementation and avoid stepping outside our role?

How to develop:

Take the set of User Stories or Use Cases from the previous stage (i.e. what users must be able to do within the solution).
Use these as a basis to derive the solution’s features. This is an optional step — many analysts work just fine using the original User Stories/Use Cases as the “atomic units” into which the solution is broken down, grouping detailed behavioral requirements around them.
Enrich the User Stories / Use Cases / Features with a detailed description of the system’s behavior: how it reacts to user actions or other events (e.g., automated system actions triggered by timers), and make sure to cover all negative scenarios as well.

What they look like:
A collection of User Stories, Use Cases (here and here), or Features, each with detailed behavior descriptions within the Software Requirements Specification document, or within a page or section in Confluence (or any other tool the analyst uses to store requirements).

What happens if you ignore them:
It’s practically impossible to ignore or omit the functional capabilities of the solution. If you skip this part of the requirements work, you essentially fail to communicate what the solution must do — its functionality and behavior — to the development team.

In reality, this information will still get passed to the team in one form or another, assuming your project includes any kind of work on requirements at all. It might not be written down in a document — maybe it will be communicated verbally — but that still qualifies as working with requirements.

For information systems, there’s a specific subtype of functional requirements — Data Requirements. Information systems deal with, well, information (thanks, Captain!), meaning that most of their functions operate on some sort of data. Without describing that data, it’s hard to provide a comprehensive view of what a function actually does.

Most features in a software system revolve around data: viewing it, creating it, modifying it, or deleting it. This is where the CRUD(L) model comes into play — Create, Read, Update, Delete, and List — one of the most useful tools in a business analyst’s arsenal. Data requirements summarize which types of data the solution handles and describe their details: type, format, whether they’re required, and so on.

Let’s break it down with a few simplified examples.

You’re buying a microwave for yourself

This isn’t an information system, so data requirements don’t apply — unless the microwave’s software includes a component that needs to store information (like a history of heating cycles).

A mass-market product: a thermometer for extreme temperatures

Data:
1) Temperature Measurement
1.1. Measurement Date (required; format: DD/MM/YYYY)
1.2. Temperature (required; format: degrees Celsius, range: -100 to +100)

Software system: A web app for ordering office lunches

Data:
1) User Account
…
2) Daily Menu
…
3) Menu Item
…
4) Order
4.1. Order Author (required; reference to a user account)
4.2. Order Date (required; format: DD/MM/YYYY)
4.3. Dishes in the order (required; array of references to Menu Items)
4.4. Portion count per dish (required; array of positive integers)
4.5. Total cost (required; positive float with two decimal places)

How to develop:

Create a context diagram for the solution, showing the data exchanged between the system and its users or external systems. Identify the information "flying around" between them.
Dig into the functional features of the solution and their behavioral descriptions to extract all relevant data the system works with.
Define data classes/entities and their attributes based on all collected data. For each attribute, describe key implementation-relevant details: whether it’s required, its type, format, etc.

What they look like:
A logical data model (a diagram showing entities and their relationships — more on this here and here) and a data dictionary describing each entity’s attributes. This can live inside a Software Requirements Specification (SRS) document or on dedicated pages in Confluence or any similar system used to store requirements.

What happens if you ignore them:
Not the end of the world. Data requirements are more of a supporting perspective — they help analysts refine the functional requirements and help the development team implement them correctly. The risk is that skipping them may result in lower-quality functional requirements — missing pieces, inconsistencies, ambiguities — which can then lead to scope creep, extended requirement sessions, rework, bugs, or simply more interruptions from the team seeking clarifications.

Now that we’ve fully described the system’s functions and behavior, it’s time to move into the “exciting” world of its additional aspects — Non-Functional Requirements (NFRs).

Analysts aren’t big fans of NFRs — they’re not as straightforward as functional requirements, especially when it comes to phrasing them clearly and precisely. But ignoring them can be dangerous, so let’s dive in.

Non-functional requirements are the properties or characteristics of the system — i.e., the conditions under which it must operate. In contrast to what the system should do (functional requirements), NFRs define how well it should do those things, or what qualities it should possess.

The categories of NFRs can vary depending on the type of solution. For example:

For a physical device, relevant NFRs may include material, shape, and so on.
For certain types of software, things like data integrity or installability might matter — but not for all systems.
Some NFRs are common across most domains, such as usability, security, and safety.

Since we’re focusing on software requirements from an IT analyst’s perspective, we’ll look at a standard classification scheme for NFRs in software systems.

Quality attributes define the qualitative characteristics of the system. In simple terms, they answer the question: How well should the system work? These characteristics can significantly affect how effectively users or stakeholders interact with the solution. For instance, a menu page could load in 10 seconds — or in 5 minutes — depending on system performance.

Quality attributes are typically divided into external and internal:

External quality attributes: What end users directly perceive.
Internal quality attributes: Important for other stakeholders, with less direct impact on user experience.

In practice, analysts usually deal with external attributes, while internal ones are often theoretical knowledge — though a thorough analyst should still at least give them some thought.

There are dozens of quality attributes (some frameworks list 40+), but here are the key ones:

External Quality Attributes:

Usability — How user-friendly or easy to use the system should be.
Performance — How fast or how much the solution performs its functions.
Availability / Reliability — To what extent the solution must be available or unavailable for use (time intervals, downtime, etc.), and how reliable it is.
Security — How well the solution protects against information leaks and unauthorized access.
Installability — How easy it is to get the solution up and running.
Safety — How safe the solution is in terms of impact on user health or property.

Internal Quality Attributes:

Efficiency — Although not always an external quality attribute, it's often important for end users. It concerns how efficiently the solution consumes the resources it needs to operate.
Portability — Not always an internal attribute either; refers to how easily the system can be moved to another operating environment.
Reusability — To what extent components of the solution can be reused in developing other solutions.
Scalability — How easily the solution adapts to increasing loads.
Modifiability — How easy it is to make changes to the solution’s functionality or other aspects.
Verifiability — How easy it is to verify that the solution works as intended.

Let’s try to formulate examples for each type:

You’re buying a microwave for yourself

Usability: The microwave handle must be designed to allow a full hand grip (preferably considering average hand size).
Performance: The microwave must accommodate containers at least 30 cm in diameter and 20 cm in height.
It must heat a dish weighing X to temperature Y at power level Z.
Availability/Reliability: The microwave must be able to operate continuously for up to 1 hour at maximum power.
Security: —
Installability: The microwave’s packaging must allow it to be unpacked by hand, without requiring any additional tools.
Safety: The microwave handle must not cause burns, regardless of the power setting or heating duration.
Efficiency: The microwave must consume no more than X units of electricity per Y time unit when operating at maximum power.
Portability: —
Reusability (for the manufacturer): The microwave handle must comply with standard X so that it can be used across the entire microwave product line.
Scalability: —
Modifiability (or more accurately, Maintainability): The heating element must comply with standard Z to simplify service and maintenance.
Verifiability: —

A mass-market product: a thermometer for extreme temperatures

Usability: The thermometer must have a 4×4 cm measurement initiation button so it can be operated while wearing protective gloves.
Performance: The thermometer must display the temperature within 3 seconds of starting the measurement.
Availability/Reliability: The thermometer must remain operational in ambient temperatures ranging from -100°C to +100°C.
Security: —
Installability: —
Safety: —
Efficiency: The thermometer must use no more than 1% of the battery charge per temperature measurement.
Portability: The thermometer must be equipped with a carrying strap.
Reusability: —
Scalability: The thermometer must support batteries of different capacities (standards X, Y, and Z).
Modifiability: —
Verifiability: —

Software system: A web app for ordering office lunches

Usability: The user must be able to access the menu within no more than 3 actions after opening the system's start page.
Performance: Page load times must not exceed 2 seconds with a local network bandwidth of ≥100 Mbps.
Availability/Reliability: The system must be available 100% of the time between 12:00 and 14:00 on working days.
Security: Only the creators of orders and users with the "Payroll Department" role must be able to view existing orders.
Installability: —
Safety: All dishes listed in the system must be labeled with potential allergy risks.
Efficiency: System data must occupy no more than 1 GB of hard disk space on the server.
Portability: —
Reusability: The authentication module must be designed as a reusable component for future corporate web applications of the client.
Scalability: The hosting environment must support up to 300 simultaneous users without requiring upgrades or migration.
Modifiability: Developers must be able to update dish prices without interrupting system operation.
Verifiability: The system must include a hidden option (not available to regular users) to test layout compatibility across various devices.

❌ Just as with functional requirements, it's better to abstract from implementation details (“how”) and focus on the value of the requirement to stakeholders (“what”). This distinction can be blurry, but in all of the following anti-examples, the logic is that it’s up to the development team experts — not the analyst — to determine whether the requirement’s proposed implementation is appropriate, especially when it falls outside the analyst’s responsibilities.
The ‘Menu’ page must be available as a first-level system menu item.
JavaScript scripts must load in under 1.5 seconds at ≥100 Mbps network speed, and image files must not exceed 1 MB in PNG format.
The system must be developed using the ultra-language ProgrammingScript2.0 to ensure maximum security against unauthorized access.
Dish prices must be stored in XML files, dynamically retrieved without requiring code recompilation.

How to develop:

While working with stakeholder requirements (let’s take a step back here), keep an eye out for quality-related keywords from stakeholders — things like "fast," "convenient," "reliable," "secure," etc. These often signal quality attributes and should be noted and captured along with other types of requirements.
It’s also a good idea to discuss quality attributes separately with stakeholders using a checklist (for example, the one above). Go through it point by point to understand how important each attribute is. Once the relevant quality parameters are selected, try to formulate concrete requirements based on them and express them in a high-quality manner — meaning the requirements should be verifiable, complete, understandable, etc.
Remember that quality attributes can generate functional requirements. In such cases, these also need to be detailed. For example, a security requirement like "The system must log all user actions that modify data" leads to a functional feature — logging of changes — which must be elaborated with behavioral requirements: when exactly the system should log, and what kind of records it should create.

What they look like:

If you’re working with documentation (like a Software Requirements Specification or Technical Specification), quality attributes should be grouped and listed in a dedicated section.

If you’re working with a backlog and User Stories, there are several ways to handle this:

For quality attributes relevant only to specific pieces of functionality, include them as acceptance criteria within those User Stories.
If the attribute entails a standalone task that can be completed in a short timeframe, it can be expressed as a separate User Story.
If you're unsure of the best approach, at the very least keep a separate list of these requirements on a dedicated page or within a knowledge base (e.g., Confluence). The team can then help determine how to translate them into backlog items.

What happens if you ignore them:

Consequences can range from minor to very significant. In small-scale projects, overlooking quality attributes rarely causes major problems. In larger or more complex projects, project parameters like time and budget may increase significantly if these requirements are discovered too late. Some quality attributes can heavily influence system architecture, and the cost of rework could be massive. In short: don’t skip these requirements. They’re worth discussing during stakeholder interviews.

The next type of NFRs: Design Constraints. These are a unique kind of requirement that, to fully grasp, your brain has to click into place. A more detailed explanation can be found here, but here’s a summary:

When external stakeholders (e.g., customers, users, regulators) or external conditions (business rules, integration requirements) dictate implementation-specific details — things like technology choices or system design — these should be considered requirements too. More precisely, they should be treated as Design Constraints — limits imposed by external conditions that affect the team’s freedom of implementation.

We’ve discussed that implementation details (UI design, architecture, tech stack, database structure) are typically within the development team's creative domain — where they’re free to make decisions based on the analyst’s requirements. However, sometimes external circumstances intrude on that freedom and dictate the "how."

For example, if a client says, “We need the database to be SQL-based because our internal expert will be maintaining it,” that’s a design constraint. As analysts, we need to be aware of this special category of requirements and make sure to document them clearly for the development team.

You’re buying a microwave for yourself

✅ The interior coating of the microwave must be made of non-toxic material — this stems from national regulations in the country where the product will be manufactured.

A mass-market product: a thermometer for extreme temperatures

You could create a similar statement here that limits the manufacturing team’s freedom. Just don’t confuse constraints with other types of requirements — constraints refer to implementation specifics, not functional or non-functional characteristics (even if dictated by external sources like regulations). Constraints are about how to implement a requirement, not what to implement.

Software system: A web app for ordering office lunches

✅ The system must be implemented in Java — because the client insists on this due to their internal team's expertise.
✅ The code must use CamelCase notation — for example, if the client plans to submit the code for government audit, which requires that convention.

❌ The most common error here is confusing team-made implementation choices with constraints. Analysts often see examples that include “implemented in Java” and assume they need to list the entire tech stack. That’s incorrect.
The development team has its own internal documentation for these decisions. It’s not the analyst’s job to dictate implementation unless external factors impose a requirement. Analysts should only document constraints that are mandated from outside and that the team must follow.

How to develop:

While working with stakeholder requirements, watch for signals when stakeholders cross into implementation territory — mentioning how to do something instead of what to do. Note these carefully.
Ask proactive questions, especially to the client, about whether there are any such constraints.
Clarify whether these are true constraints — investigate the reasoning and necessity. Ideally, unnecessary constraints should be challenged or removed. Once validated, document these constraints alongside other external requirements.

What they look like:

These are usually presented as a separate section in a Software Requirements Specification, or as standalone entries in Confluence or similar tools where the analyst maintains requirement documentation.

What happens if you ignore them:

In theory, design constraints can have a huge impact. For instance, if they limit the tech stack, you might need to redo all the development work.

In practice, critical constraints are usually voiced proactively by stakeholders, so missing them often leads to only minor issues. Still, many analysts tend to overlook this category entirely — and while that rarely leads to disaster, it's still best not to skip it.

To be continued in Part Three.