Functional and Non-Functional Requirements

Module 1 of 6 in the chapter Understanding Integration Requirements, chapter 6 of the Integration Architect course. Each module stands on its own. Next: Listening for the Shape of the Integration

The question this module answers: When the business tells you what an integration should do, how do you find out everything else it has to do?

In chapter 1, The Building Nobody Described split requirements into two kinds: the declared ones the client tells you, and the implied ones they expect without saying, like the fire exits in a commercial building. This chapter turns that into a method. And the first step is a second way of sorting the same requirements: functional and non-functional.

What It Does, and How It Has to Behave

A functional requirement is something the business is asking for. I need it to do X. Send the orders to finance. Show the customer’s latest delivery. Tell the Retail Partner when a delivery’s status changes.

A non-functional requirement is about how it has to behave while it does that. Logging. Error handling. How fast, how much, how often, how safely. These are often system-level requirements, and they’re very often the implied ones: the business assumes them and never says them.

Take one Steve Trucking requirement, the status back to Redrock from chapter 5. The business gives you one sentence. Behind it are the questions that decide the design.

Click to enlarge

One sentence from the business, and the questions behind it.

Notice two things. First, most of the non-functional answers are numbers: minutes, deliveries a day, retries, days to keep a log. Module 3 is about getting those numbers out of the business. Second, nobody on the business side will volunteer them. If you don’t ask, you’ll find out in production.

Discover the Other System

Here’s what’s missed most often. When the business gives you an integration requirement, “it must send the data to this system,” they’ll usually mention the system. They won’t describe it. That’s our job: we have to do our own discovery on the system at the other end.

What I want to know about every system on the other side of an arrow:

• What it is, and who runs it: your company, a partner, a vendor’s cloud.
• Its API, and what version it is.
• How it signs callers in: its credentials and its authentication.
• How often it changes, and how you’ll hear about a change before it breaks you.
• Its tech stack. There may be capabilities nobody told you about. The business might not know the system can send webhooks, but if it can, that might be a better design than calling it every five minutes.
• Its uptime. When is it down, planned or not?

These are the details we usually have to find later, after the design is done. Find them first.

The last one caught me once. I was working at a large utility, calling its ERP, and we found out that once a month they took it down for the weekend, for a day or two. Nobody had listed that as a requirement. It wasn’t a failure; it was a schedule. So we had to build that outage into the system.

Click to enlarge

Frame 1 of 2: the weekend the ERP is down, and every call fails.

Click to enlarge

Frame 2 of 2: the outage built in. The calls wait, and go through on Monday.

Found before go-live, the monthly weekend is a queue in the design. Found after go-live, it’s a weekend of lost orders and a very long Monday.

What Goes in the Logs

Logging is a good example of a non-functional requirement that’s harder than it sounds. You need logs with details: when something breaks at two in the morning, a log that says “error” is no help. I’ve even seen logs that keep the low-level payloads, the whole message as it was sent.

But look at what’s in those payloads. If the integration carries confidential data, health information or personal information, every log that keeps the payload keeps that data too, often in a system with weaker controls than the one it came from. So the logging requirement has two halves: enough detail to fix a failure, and nothing in the log that shouldn’t be there. Which fields need to be masked, and which shouldn’t be logged at all?

You can only answer that once you know how the data is classified. That’s module 4.

Where the Data Lives

One more non-functional requirement that comes with the data: residency. If the business is under a regulation like GDPR, or has promised its customers that their data stays in a region, that promise doesn’t stop at the edge of Salesforce. Say the org keeps European customers’ data in Europe, and the integration sends their documents to an e-signature service hosted in the United States. The org complies. The integration doesn’t.

So when there’s a residency requirement, I want every system on the landscape flagged with where it keeps its data, and every arrow checked: does this one carry the data across a line it isn’t allowed to cross? Module 5 is about regulation, with the rules themselves.

A Checklist for Every Arrow

Put it together, and for every arrow on the landscape, you want the functional requirement in the business’s words, and then the non-functional ones:

• Timing: how soon, and synchronous or not (module 2).
• Volume and growth: how many, how big, at the busiest time, today and in three years (module 3).
• The other system: its API, version, sign-in, change rate, tech stack and uptime.
• Errors: what happens when it fails, what’s retried, what happens if it’s sent twice, and who is told.
• Logging: what’s kept, for how long, and what’s masked.
• Security and classification: what data travels, and how it’s protected (module 4).
• Regulation and residency: where the data may go (module 5).
• Constraints: limits, firewalls, windows, skills (module 6).

None of these is exotic. All of them get missed.

What an Architect Decides Here

• For every arrow: the functional requirement, in the business’s words, and its non-functional requirements, as numbers wherever they can be.
• For every system at the other end: its API and version, how it signs callers in, how often it changes, its tech stack and its uptime, found before the design is done.
• How each planned outage is built in.
• What each integration logs, for how long, and what’s masked or never logged.
• Where each system keeps its data, and which arrows cross a residency line.

Beyond the exam: what AI changes. AI is good at turning meeting notes into a tidy list of functional requirements. It’s much less good at the non-functional ones, because nobody said them in the meeting. AI gives you what you ask for, not what you forget to ask. So ask: give it the checklist above, and it will find many of its own gaps. Then check what it drafts against the checklist yourself. And AI adds non-functional requirements of its own: which fields may be sent to a model, where that model runs (residency again), and whether prompts and answers end up in a log.

Explore

• The Building Nobody Described: declared and implied requirements, and the three-year horizon.
• The Landscape as an Inventory: every arrow’s starter, mechanism, credential and owner.