Functional vs Non-Functional Requirements

• Functional requirements : concrete behaviours the system must provide : the features, inputs, and outputs that define what it does, testable by a yes-or-no feature check.
• Non-functional requirements : quality attributes that constrain how well those behaviours are delivered, such as latency, availability, consistency, durability, security, and scalability.
• Service level objective (SLO) : a numeric target for a non-functional requirement, such as p99 latency under 200 ms or 99.99% availability.
• CAP tension : non-functional requirements often conflict, and the designer must make explicit trade-offs aligned with the domain.

What are functional requirements?

Functional requirements are the features. For a banking transfer system they include "a user can transfer money," "a user can view their balance," "a user can download a statement," and "a user receives a notification after a transfer." Each one is testable with a simple check: did the transfer happen, is the balance shown. You can model them as use cases or user stories, and they map directly to API endpoints.

package com.bank.api;

import java.math.BigDecimal;
import java.time.LocalDate;

public interface BankingApi {
    TransferResult transfer(String from, String to, BigDecimal amount);
    BigDecimal balance(String accountId);
    Statement statement(String accountId, LocalDate from, LocalDate to);
}

What are non-functional requirements?

Non-functional requirements are the quality attributes. The four most discussed in interviews are latency, availability, consistency, and scalability. Latency is how fast a single request returns, usually expressed as a percentile like "p99 under 200 milliseconds," meaning 99% of requests are faster than that. Availability is the fraction of time the system is up, expressed in nines, where three nines is about 43 minutes of downtime per month and five nines is about 26 seconds. Consistency is whether every reader sees the latest write. Scalability is whether the system keeps its latency and availability as load grows.

package com.bank.design;

public record ServiceLevelObjective(
    long p99LatencyMs,         // e.g. 200 ms
    double availability,       // e.g. 0.9999 (four nines)
    boolean strongConsistency, // true for money
    long targetPeakQps         // e.g. 6000
) {
    public String downtimePerMonth() {
        double downMinutes = (1 - availability) * 30 * 24 * 60;
        return String.format("%.1f minutes/month", downMinutes);
    }
}

How are they different?

Functional requirements are verb-driven and binary : the feature either works or does not. Non-functional requirements are numeric and continuous : the latency is not just "fast" but "p99 under 200 ms." A system can pass every functional test and still fail customers if it is too slow, too often down, or shows stale data.

| Aspect | Functional | Non-Functional |
|---|---|---|
| Describes | What the system does | How well it does it |
| Testable by | Yes/no feature check | Numeric SLO measurement |
| Example | "User can transfer money" | "p99 latency under 200 ms" |
| Maps to | API endpoints, use cases | Architecture decisions, SLOs |

package com.bank.design;

public class RequirementTypes {
    // Functional: does the feature exist?
    boolean canTransfer = true;   // yes or no
    boolean canViewBalance = true;

    // Non-functional: how well does it perform?
    long p99LatencyMs = 200;         // numeric target
    double availability = 0.9999;    // four nines
    boolean strongConsistency = true; // domain-driven choice
}

Why do non-functional requirements conflict?

Non-functional requirements usually conflict and force trade-offs. Strong consistency fights availability during a network partition, as the CAP theorem states. Low latency fights durability if you acknowledge writes before they are safely replicated. High availability fights cost because redundant servers and multi-region deployments are expensive.

package com.bank.design;

public class NfrConflicts {
    public static void main(String[] args) {
        System.out.println("Conflict                    | Banking resolution");
        System.out.println("----------------------------|----------------------------");
        System.out.println("Consistency vs Availability | Choose consistency (CP)");
        System.out.println("Latency vs Durability       | Accept higher latency");
        System.out.println("Availability vs Cost        | Pay for multi-region");
        System.out.println("Scalability vs Consistency  | Shard carefully by account");
    }
}

How do you write good non-functional requirements?

Write non-functional targets as numbers with units so you can later prove the system met them. Say "p99 transfer latency under 200 ms" instead of "the system should be fast." Say "99.99% availability measured monthly" instead of "the system should be reliable." Vague requirements cannot be tested, monitored, or defended in an interview.

package com.bank.design;

public class GoodNfrs {
    // BAD: vague, untestable
    // "The system should be fast and reliable."

    // GOOD: numeric, measurable, domain-aligned
    // "p99 transfer latency < 200 ms"
    // "Monthly availability >= 99.99% (four nines)"
    // "Strong consistency on balance reads (no stale data)"
    // "Peak throughput: 6,000 transfers per second"
}

When should you choose strong consistency vs eventual consistency?

The domain decides. For money you favour consistency and durability even at the cost of some latency, because a wrong balance could allow a double-spend. For a social feed or trending list you favour availability and speed and accept slightly stale data, because a like count being one second behind harms nobody.

package com.bank.design;

public class ConsistencyChoice {
    public static String choose(String dataType) {
        return switch (dataType) {
            case "account_balance" -> "STRONG : wrong balance = double-spend risk";
            case "transaction_ledger" -> "STRONG : append-only, audit-critical";
            case "social_feed" -> "EVENTUAL : stale like count is harmless";
            case "analytics_counter" -> "EVENTUAL : approximate is fine";
            default -> "Evaluate per data type";
        };
    }
}

What should a senior engineer emphasize?

A senior engineer treats NFRs as architectural drivers, not afterthoughts. They name which NFR drove each design decision : "I chose PostgreSQL because I need ACID (consistency). I added a cache because I need sub-200ms reads (latency). I deployed across two regions because I need four-nines availability." They also name what they sacrificed : "The cost of strong consistency is higher write latency and reduced availability during partitions."

What are common interview follow-up questions?

Interviewers commonly ask: "Which non-functional requirement drove your database choice?" "What happens to your SLOs during a deployment?" "How would you monitor these NFRs in production?" (dashboards, p99 percentile tracking, uptime SLIs). The ability to connect a requirement to a measurable SLO to a monitoring dashboard is what separates a senior answer from a junior one.