Identifying Key Non-Functional Requirements

Hello! In the previous lesson, you set the boundary for a support-assistant pilot: agents receive sourced drafts when approved policy supports them, unsupported drafts are withheld, agents control sending, and review-required replies need approval of their final text. Those are functional requirements—they describe what the workflow must do. A pilot can satisfy every one of them in a demonstration and still fail in use if drafts take too long, peak traffic overwhelms the service, sensitive ticket text leaks, or operating costs exceed the budget.

This lesson is about identifying non-functional requirements (NFRs) for that same workflow. You’ll translate customer expectations into measurable constraints for latency, throughput, availability, security, privacy, and cost. The figures below are illustrative proposals, not facts agreed with a customer; a forward deployed engineer would confirm them with the people who use, fund, secure, and operate the system.

Start with the consequence of failure

“Make it fast and secure” gives a delivery team almost no basis for design or testing. A better discovery question is: What happens when this quality is insufficient? If an agent waits too long for a draft, they may abandon the assistant. If the service fails during a busy support period, they need a manual path. If a ticket contains personal information, the question is not merely whether the API is encrypted, but where that information goes and how long it remains there.

Microsoft Learn’s Build for business needs makes the central design point: business requirements should justify technical choices. Read its short discussion before looking at specific metrics.

The image below places an ML workflow at the center of several operational concerns. Notice that performance, reliability, security, and cost apply across the lifecycle, rather than appearing only at deployment. Privacy is not separately labelled in this image; for our ticket workflow, it still needs explicit requirements.

An NFR becomes useful when it names a scope, a target or rule, and a way to check it. For example, “fast” is vague. “During the pilot’s support hours, 95% of valid draft requests show either a draft or an explicit no-draft result within eight seconds, measured from the agent’s click to the visible result” defines whose wait matters and where the stopwatch starts and stops. Eight seconds is a proposed value to test with agents, not a universal standard.

Latency, throughput, and availability describe different failures

These three qualities interact, but they are not interchangeable:

• Latency: How long does one request take from the user’s perspective?
• Throughput: How much work must the system handle in a given period, including bursts?
• Availability: When users need the workflow, what fraction of their valid attempts receive a usable response?

Google’s Service Level Objectives chapter supplies the measurement vocabulary. An SLI is a defined measurement; an SLO is a target for it. An SLA is an agreement with consequences if its terms are missed. At this stage, we are proposing requirements and possible SLOs, not promising an SLA.

For latency, choose the operation and endpoint of measurement. A support agent cares about the time until a result appears, not just the time an API takes to acknowledge a request. The result might be a cited draft or a deliberate “no draft—no approved policy found.” If retrieval, model generation, and the interface all contribute to the wait, measuring only model time would understate it. A proposed pilot target might be: 95% of valid requests complete within eight seconds during support hours, measured in the agent interface over each calendar week. Record timeouts and failed requests separately; a low latency percentile calculated only from the successful requests could hide failures.

For throughput, ask about normal demand and the busiest plausible interval. Suppose the pilot expects 100 requests per business day, normally around four per minute but occasionally 12 per minute for ten minutes. “100 per day” alone does not establish whether the service handles that burst. A candidate requirement is: at 12 valid requests per minute for ten minutes, the workflow continues to meet the agreed latency target without dropping requests. State assumptions that affect load, such as typical ticket length and the number of documents searched. Test with representative requests, not just empty inputs. Throughput is a capacity to accommodate demand; it is not a promise that users will generate a particular number of requests.

For availability, first specify what “usable” means. An intentional no-draft response is usable when no approved policy supports an answer; a timeout, blank screen, or fabricated draft is not. The fabricated draft also violates a functional acceptance criterion, which should be tested directly rather than concealed inside an availability percentage. An illustrative operational target is: 99.5% of valid draft requests made during agreed support hours return a usable result, measured over a rolling 30-day window. The team must agree whether planned maintenance counts and whether the measurement comes from the interface, an API, or both.

Availability is not the whole recovery story. Ask how long agents can work manually and which state must survive an outage. Recovery time objective (RTO) is the target time to restore the workflow; recovery point objective (RPO) is the maximum acceptable loss of recent persisted data. For example, the customer might provisionally accept restoration within one hour and up to 15 minutes of lost draft history. That must not imply permission to send a review-required reply with an unknown approval state: if approval cannot be verified after recovery, sending stays blocked. The exact recovery targets need confirmation with the customer’s workflow and operations owners.

Security and privacy need separate questions

Security asks whether access and actions are authorized and whether information is protected against unauthorized disclosure or alteration. Privacy asks whether personal data is collected, used, shared, retained, and deleted in acceptable ways. Encryption helps with security, but it does not decide whether retaining a full ticket in model-request logs for months is appropriate.

Watch the security portion of 6 Pillars of the AWS Well Architected Framework (you should really know this), from Be A Better Dev. Use its identity and encryption discussion as a starting checklist, not as a complete privacy policy.

For the pilot, trace the sensitive material: ticket text may enter the application, a retrieval step, a model request, and operational logs. The policy documents have their own access rules. Identify who or what may access each item and for what purpose. Candidate security requirements could include:

Only agents authorized for a ticket may request or view its draft. The application’s service identity may read only the approved policy set needed for the pilot. Ticket and policy data must be encrypted in transit and at rest. A send action must still enforce the previously agreed agent-control and final-text approval rules.

These are more testable than “use strong security.” Permission tests can try an agent without ticket access; configuration reviews can check service permissions and encryption settings; workflow tests can attempt an unapproved send. The precise identity system and encryption implementation are later design choices. A security requirement should specify the protection needed before it names a product.

Privacy requires another conversation, usually with the customer’s privacy or data owner. Ask which ticket fields can contain personal or confidential information, whether they may be sent to an external model provider, whether a reduced or masked version will suffice, whether inputs are retained by that provider, and what deletion or residency obligations apply. Do not infer permission to use production ticket data simply because an integration can access it. For illustration, a customer-approved pilot rule might be:

Send only fields necessary to prepare the draft; exclude credentials and unnecessary identifiers; do not place full ticket text in ordinary application logs; retain draft records for no longer than the period approved by the data owner; and document any external processor that receives ticket content.

“Fields necessary” and the retention period must be specified before this becomes a complete requirement. Validate it by inspecting representative request payloads and logs, reviewing provider settings or agreements, and testing deletion and access rules. A model that produces good drafts does not compensate for a data flow the customer never approved.

Cost is a workload constraint, not a final bill estimate

Cost requirements often get written as “keep it cheap.” That conceals the most important questions: At what volume? For which environments? Which expenses count? What happens if demand grows? The Microsoft Learn reading noted that consumption charges are only part of total cost; operations and recovery also require effort.

For this pilot, an initial estimate should at least account for model requests and input/output volume, retrieval or search, storage, logs, network transfer where applicable, and any baseline infrastructure running when no agent is using the assistant. Include the work required to operate it when comparing designs. If the illustrative workload is 100 requests per business day, roughly 2,200 requests in a 22-day month, an illustrative planning constraint might be: keep incremental pilot operating spend below $600 per month at the stated volume, including model, retrieval, infrastructure, and logging charges. That number has no authority until the customer’s budget owner accepts it and the team estimates costs using the intended workload.

A useful cost requirement also names a response to variance: assign an owner to review spend and forecast against the agreed budget. A cost limit must not silently weaken other requirements. If usage or model prices push the pilot over budget, the team can revisit eligible volume or the approved design; it must not bypass access controls, stop recording required operational evidence, or substitute unsupported drafts.

This is where NFRs become real trade-offs. A tighter latency target may require more ready capacity. Greater redundancy may improve recovery but raise baseline cost. Retaining less sensitive data may reduce privacy exposure yet limit how long a draft can be investigated. Record the conflict and seek a decision from the relevant owner rather than claiming every target can be maximized at once.

Put the six requirements into a pilot register

The following is a compact draft for stakeholder review. Each line identifies something to confirm and a way to gather evidence. It is not a set of commitments already made.

Before treating the register as ready for implementation, resolve its open terms: the pilot’s support hours, a “representative” request, the agreed retention period, the actual monthly budget, and the owners who can approve each target. The point is not to produce six polished sentences in isolation. It is to make the customer’s operating expectations specific enough that the team can design, test, and negotiate against them.

Conclusion

Functional requirements establish what the support assistant must do; non-functional requirements establish the conditions under which it is acceptable to use. For this pilot, identify the user-visible wait, normal and peak load, usable-request availability and recovery needs, permissions and data handling, and cost at a stated volume. Give each requirement a scope, a proposed target or rule, a measurement or test, and a decision owner. Keep proposed figures visibly provisional until the customer confirms them.

Next, you’ll map the workflow into source, processing, storage, model, service, and user-facing components. These NFRs will give that architecture a purpose: each component and data flow should help satisfy a requirement, not exist merely because the technology is available.