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

2025-06-23 09:41 Business analysis

This is the continuation of the article “Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide”. See Part 2 here.

Another aspect of NFRs — External Interface Requirements.

Let’s start by recalling that an interface, in its broadest sense, is a mechanism through which a system interacts with the outside world. For example, a human being is a complex system with interfaces like eyes, mouth, ears, fingertips, and so on. Software systems, likewise, can — and typically do — have interfaces: mechanisms for communicating with other software or hardware systems, as well as with users.

The user interface (UI) is the mechanism by which a user interacts with the system. This doesn’t necessarily mean a graphical interface — it could also be a command-line interface or even a voice interface. Apart from users, software systems often communicate with other software systems, usually via APIs (Application Programming Interfaces), or with hardware devices. Hardware interfaces are encountered much less frequently in a typical analyst’s work (note: we’re not talking here about the system environment in which the solution operates — e.g., the server hosting a web application — but rather external devices the system must communicate with). For instance, maybe your software directly controls a printer or communicates with a payment terminal.

The key takeaway here is this: as analysts, we must clearly identify the external entities — software and hardware — that the solution needs to interact with in order to function, and we must describe these interactions accurately in the requirements.

It’s also important to clarify that I personally adhere to the practice of excluding UI requirements from this category. I leave only software and hardware interfaces here. The reason is that, in practice, UI is an inseparable part of functional requirements, and for our target audience, UI (if it’s part of the analyst’s responsibilities and not the domain of a separate UX designer) is deeply tied to behavioral functional requirements. Describing UI separately in some “supporting” chapter detached from system behavior would be inconvenient and uninformative.

Also, note that the level of depth and detail in this category can vary significantly depending on the team’s working style. Most often, external interface requirements include the following set of information:

What external interfaces exist — what other systems the solution needs to interact with.
What the interaction points are for each of them — for instance, all the API methods the solution must call, and the points in the functional requirements where these calls are to occur.
How each point of interaction works: protocols, data formats, data mapping (correspondence between internal data and external request/response formats), and any transformation logic needed. Some of this can be found in the third-party system’s documentation (e.g., most widely-used public APIs provide full descriptions online), so there’s no need to duplicate it — better to provide a link.
How the system should respond to errors from external systems — for example, if the API returns a “data not found” message.

In short: descriptions of third-party system interfaces themselves usually already exist — either publicly or in documentation — and the development team can study these on their own if you point them in the right direction. Your job as an analyst is to describe how these interfaces are used in your solution: when to call them, what to send in a request, what data to extract from a response, and how to handle unexpected situations.

Quick examples (very brief, since we're not writing a full specification here):

You’re buying a microwave for yourself

The microwave must be equipped with a USB port for connecting to a diagnostics system.

Software system: A web app for ordering office lunches

The system must regularly import menus from the “Cafe Menu Aggregator” web application.
The system must import data daily at 08:00 (GMT +3).
API method (see documentation at this link): GetDailyMenu
Request data:
Date = current date at time of call
Response data:
For each Meal in the response: Name (dish name), Price (dish price), Img (dish photo).
If the response code is 152 Menu not found, the system must display the message “Sorry, the menu for today is unavailable.” on the Menu page.

How to develop:

Build a Context Diagram to identify which external systems (other than users) interact with the solution, either by calling it or being called by it.
Study the documentation for each such system and define the requirements in detail using the checklist above.

What they look like:

Requirements detailed using the checklist above, placed in a dedicated section of the Software Requirements Specification (SRS) document.
Interaction points with external interfaces will also be reflected in the functional behavioral requirements (within the descriptions of relevant Features or Use Cases).
Alternatively, they can be documented as separate pages or entries in Confluence or any other requirements management system used by the analyst. You can also describe specific third-party system interactions directly in User Story acceptance criteria if that’s where the interaction will be implemented.

What happens if you ignore them:

If you overlook the need for integration with an external system altogether, the project scope may unexpectedly balloon — and that piece will often be one of the more complex and risky to implement.

If you under-specify the details, it usually won’t cause critical issues — the development team can cover it with some clarifying questions — but it’s not ideal.

The final category of NFRs: the “Miscellaneous” bucket.

This is a catch-all category for requirements that don’t fit neatly into any of the other NFR types we've already discussed. Given the wide variety of solution types, this category can include a lot of directions. Common types of “miscellaneous” requirements for software solutions include:

Operating environment requirements — in what context the system must operate or be deployed (e.g., supported browsers; specific mobile or desktop platforms and versions; server specs needed to host the system; device screen resolutions; the public URL where the system will be accessible).
Localization requirements — support for multiple languages, data formats, time zones, etc.
UI design requirements — color schemes, branding standards, etc.

You’re buying a microwave for yourself

The microwave must be red (RGB code: #E30F47) — UI design requirement
The power cord must be compatible with plug type Z — operating environment requirement

A mass-market product: a thermometer for extreme temperatures

The thermometer must be certified under standard Y before use — certification requirement
The thermometer must operate in a range of -100°C to +100°C — operating environment requirement
The thermometer must be available in “Extreme Tourism” retail stores — this could be an operating environment requirement, or interpreted as a quality attribute (Installability)

Software system: A web app for ordering office lunches

The system must function correctly in the following browsers: Google Chrome (latest version), Firefox (latest version) — operating environment requirement
The system must be accessible at: https://meals.bestsolutions.net — operating environment requirement
The interface must be available in Russian and English — localization requirement. (Note: this should generate associated functional requirements — e.g., how the user switches languages, plus all UI text in both languages.)
The visual design must comply with the corporate brand book (see description here) — UI design requirement

One last category — Transition Requirements.

This final category is often overlooked by analysts — more due to unfamiliarity than intent. Transition requirements are different from all the others in one key way: they are temporary. All the other requirements are permanent — i.e., they describe the solution for as long as it exists (unless those requirements change). Transition requirements, by contrast, describe what must be done once or periodically to successfully deploy the solution in a live environment.

Transition requirements can apply to the solution itself (e.g., a temporary feature or a one-time setup step), or to the surrounding environment (e.g., notifying users or training staff).

Common examples:

Migrating data from old processes into the new IT solution.
Training users on how to use the system.
Setting up user accounts and permissions for existing staff.

You’re buying a microwave for yourself

A user manual must be written for the microwave and included in the package.

Software system: A web app for ordering office lunches

User accounts must be created for all company employees.

How to develop:

Study typical examples of transition requirements (for example, this list).
Discuss with stakeholders, asking leading questions like: “Is there anything else we need to do when launching the solution to ensure it’s ready for use?”

What they look like:

Clearly formulated requirements within a dedicated section of the Vision and Scope or Software Requirements Specification document (to make sure neither you nor stakeholders forget them at go-live). Alternatively, keep these in a Confluence page or other documentation system where the analyst tracks requirements.

What happens if you ignore them:

Usually, the consequences aren’t severe. Still, just like any other requirement, skipping this category might lead to unexpected increases in project scope — e.g., discovering late in the game that someone needs to do a lot of setup work. Thankfully, these are typically low-effort tasks compared to building the core solution.

That’s all, really. I hope this article has shown how, by moving step by step — from the reasons for building the solution, to the needs of stakeholders, to what must be implemented (in terms of both functions and non-functional aspects) — we ultimately arrive at a comprehensive specification of the target solution from a requirements perspective.

This gives the client confidence that their investment is being used to build the right thing, reassures stakeholders that their needs are addressed, and gives the development team a full blueprint to build exactly what’s required.

As always, I’d love to hear your feedback — especially your thoughts on where this explanation might be unclear or incomplete. After all, this is a core responsibility of an IT business analyst.