Interface requirement

An interface requirement governs whether both sides of a boundary can work together, not merely an API address

Build an interface inventory before deciding how deeply each boundary must be specified

Project interfaces include more than backend APIs: file exchanges, messages, identity, human handoffs, and operational channels also cross boundaries. Listing sender, receiver, business object, and owner reveals which interfaces this phase builds, which depend on a customer or supplier, and which changes require both sides.

1. Are both sides named and owned?

   Do not write only “connect to the customer system.” Identify the system, service, organisation, role, and current accountable contact.

   Check the system context, interface register, and responsibility matrix.

2. Have all operating modes been considered?

   Normal, peak, maintenance, degraded, disconnected, recovery, migration, and retirement modes may use different paths.

   Check the operational concept, exception scenarios, and retirement plan.

3. Have implicit interfaces been found?

   Copy-and-paste work, shared accounts, temporary spreadsheets, email attachments, and operations scripts are often real dependencies missing from formal design.

   Check observation, logs, operating procedures, and support history.

A complete interface contract coordinates several dimensions at once

Matching field names proves only that both sides can parse some data. Working together also requires shared business meaning, identity, timing, error, and recovery behaviour. An interface contract is therefore a bilateral responsibility, not a provider's technical note.

What a verifiable interface requirement records

“Integrate with ERP” cannot be estimated or accepted directly. A verifiable requirement says which event causes one party to send which versioned object to another, how receipt is confirmed, and which state each side preserves after failure or timeout. That makes a contract, data, or responsibility failure identifiable.

Derive interface requirements from system boundaries and actual interactions

Existing documentation often records an ideal call while real operation includes manual entry, overnight files, redelivery, and legacy compatibility. Follow a business object through its lifecycle and compare logs, incidents, and work on both sides to find interactions carrying responsibility outside the document.

1. Map the system context and responsibility boundaries

   Use business scenarios, the operational concept, and the system boundary to identify external entities, independently changing internal elements, and people. Do not assume the current API catalogue contains every interaction.

2. Trace information, control, and state end to end

   For normal and exception paths, find where an input originates, where it becomes authoritative, who consumes and acknowledges it, and what record remains at the end.

3. Check actual systems and constraints

   Review supplier specifications, schemas, rate limits, networks, identity, licences, maintenance windows, and support commitments, then probe a sandbox where possible to compare documentation with behaviour.

4. Interview both sides separately

   Ask business, development, security, data, operations, and suppliers to explain fields, states, failures, and responsibilities. Record conflicting meanings, assumptions, and unresolved decisions.

5. Establish semantics and the failure model

   Agree objects, identifiers, states, units, time, and success before choosing transport. Enumerate invalid, unauthorized, missing, conflicting, duplicate, late, and unavailable conditions.

6. Allocate without losing shared responsibility

   State what the provider guarantees, how the consumer must use the interface, and what a platform or network supplies. Do not phrase an external dependency as a result one party can guarantee alone.

7. Walk through examples and counterexamples

   Have both parties interpret the same normal, boundary, exception, and old-version cases. Samples expose ambiguity, but the approved rules and schema remain normative.

8. Baseline both sides and the change process

   Approve version, owners, open parameters, verification environment, and decision record before implementation; subject later changes on either side to impact analysis.

Retries, duplicates, ordering, and partial failure must be explicit at the interface

A network timeout means the sender did not receive an answer; it does not prove the receiver did nothing. Blind retry can duplicate an order, payment, or message. Both sides define request identity, retry conditions, final-state lookup, and compensation responsibility instead of assuming the other side handles it.

Interface security requirements begin with trust boundaries and business impact

Authentication proves a credential, not that it may view this customer, change this object, or export these fields in bulk. Continue from the credential to business object and action: least privilege, sensitive data, audit, revocation, and the real consequence of compromise.

1. Does each hop establish the other party?

   Define how user, service, device, and organisation identities are established, bound, conveyed, verified, and revoked. Internal network location is not identity.

   Check identity flows, credential lifecycle, and service-to-service authentication tests.

2. Does authorization match the business object?

   Define which tenant, object, fields, and actions a subject can use. A downstream service must not trust an upstream role string without verification.

   Check resource, action, and cross-tenant negative tests.

3. Is only necessary data exchanged?

   Review each field for purpose, sensitivity, masking, encryption, region, cache, log, retention, and deletion. Debugging convenience is not an automatic purpose.

   Check data flows, dictionaries, privacy review, and logging.

4. Are input and output treated as untrusted?

   Constrain size, type, structure, rate, and executable content; verify signatures and origin; address injection, parser differences, malicious files, and resource exhaustion.

   Check schema validation, fuzzing, throttling, and content-security tests.

5. Can credentials rotate and become invalid?

   Define issuer, audience, scope, lifetime, storage, rotation, revocation, compromise response, and clock skew. Tokens and secrets must not enter ordinary logs or errors.

   Check credential inventory, rotation exercise, and revocation test.

6. Can incidents correlate without excessive disclosure?

   Use correlation identifiers, protected logs, and a common time basis across parties. Public responses expose stable consumer information; detailed diagnostics stay in controlled channels.

   Check responses, logs, and alerts in normal and adversarial cases.

Constructed procurement-service to ERP interface requirements

This customer-independent procurement-to-ERP interaction shows both parties agreeing object identity, version, acknowledgement, and failure recovery. Names, fields, and times are placeholders. The important distinction is that transmission, business acceptance, and final persistence are not the same result.

Joint verification, release, and continuing governance of an interface

A one-sided mock test does not prove that two production systems can operate together. Both sides use the same contract and representative data for positive, exceptional, and recovery tests, coordinate version, capacity, and rollback at release, and retain enough correlation to diagnose incidents across the boundary.

1. Perform a static consistency review

   Both parties review names, meaning, direction, units, timezones, schema, states, errors, identity, capacity, version, and responsibility. Close TBDs or assign an owner and deadline.

2. Verify early with contracts and simulators

   Provider and consumer use machine-readable schemas, examples, stubs, and contract tests so field and state differences appear before a complete integration environment exists.

3. Integrate in representative conditions

   Use approved versions, credentials, networks, data scale, and time configuration; cover normal, boundary, failure, concurrent, and older-consumer cases with logs and correlation from both sides.

4. Create faults and uncertain outcomes

   Exercise timeout, disconnection, duplicate, disorder, throttle, invalid credential, partial completion, dependency recovery, and replay. Confirm no unauthorized or duplicate business effect and no irreconcilable state.

5. Verify reconciliation, capacity, and security

   Compare bilateral records with authoritative state, load-test against performance requirements, and test identity, authorization, leakage, malicious input, and audit evidence.

6. Record acceptance against the interface version

   Record the requirements baseline, build or service versions on both sides, environment, data, configuration, results, open deviations, and bilateral confirmation. One successful call is not interface acceptance.

7. Observe and rehearse after release

   Monitor success, rejection, latency, backlog, duplicates, unknown outcomes, reconciliation differences, and version adoption. Maintain escalation, credential rotation, dependency-outage, and manual fallback paths.

Both sides assess interface changes; provider compatibility alone is insufficient

A provider may call a new field additive while a strict consumer fails on it. A changed error meaning or default order can alter business outcomes without changing the schema. Compatibility is judged against actual use, semantics, and operational risk on both sides—not merely whether the endpoint returns 200.

Enterprise AI interface requirements cover models, knowledge, tools, and human boundaries

Enterprise AI crosses several trust boundaries: internal material enters retrieval, retrieved content enters a model, the model proposes tool actions, and failures route to a person. Each crossing can change data authority, state, and responsibility, so a model request schema alone is not a complete interface.

Interface requirements and neighbouring concepts

An API specification, data model, integration design, and service level may each describe part of an interface, but none alone is the full requirement. Interface requirements govern how both sides fulfil business responsibility and connect technical structure, operating quality, and change control.