Skill Hub — Systems Analysis

Interface Requirement Analysis

Define what data crosses a system boundary, in which direction, under what conditions, and with what quality and error-handling requirements.

What this skill is for

This skill produces a clear, stakeholder-validated specification of what an interface must do before any technical design begins. It answers: what business event triggers data to cross a boundary, which data elements are required, who owns each element, how often the transfer must happen, what quality and validation rules apply, and what happens when something fails. The output bridges business needs and integration architecture, preventing scope creep and late discovery of mismatched expectations.

When to use this skill

Business needs to send sales orders from SAP S/4HANA to a third-party logistics platform.
A new vendor onboarding process requires master data synchronization from SAP MDG to an external procurement system.
Finance requires invoice data from SAP S/4HANA to a data warehouse, with a defined frequency and format.
An incident reveals that an existing interface has no documented error-handling requirements, and teams argue about who owns the failure.
Procurement wants real-time purchase order confirmations from suppliers, but the current interface is batch-only.
You are scoping an integration project and need to separate functional requirements from non-functional requirements before the technical team estimates effort.

Real work situations

Example 1: Sales order outbound to 3PL with missing error handling

A company sends SAP S/4HANA sales orders to a third-party logistics platform via IDoc. The interface transmits order header, items, and schedule lines. The 3PL rejects incomplete orders, but the interface requirement never specified a retry policy, an alert threshold, or a fallback action. When the 3PL returns a rejection, the IDoc status remains 53 (success) because the technical handshake succeeded, but the business process stops. The requirement analysis reveals that functional error handling was never defined, and the non-functional requirement for latency was described as "as soon as possible" instead of a specific SLA.

Example 2: MDG business partner to Salesforce with identity mismatch

SAP MDG distributes customer master data to Salesforce. The functional requirement assumed that MDG would send the Salesforce external ID, but MDG does not store it. The data element boundary was never analyzed: MDG owns the SAP customer number, Salesforce owns the external ID, and the integration middleware performs the mapping. The interface requirement analysis shows that the mapping ownership was undefined, leading to duplicate records in Salesforce when the mapping table was corrupted.

Example 3: Material master bidirectional sync with PLM bypassing approval

A material master interface between SAP S/4HANA and a PLM system is bidirectional: basic data and classification flow from PLM to S/4HANA, and procurement-relevant data flows back. The functional requirement did not specify who owns the approval step when PLM changes overwrite S/4HANA data. The non-functional requirement did not specify a maximum latency for the reverse flow. As a result, a PLM change reached S/4HANA production before the procurement team could review it, causing a purchase order with incorrect material data.

Inputs required

Source system name, version, and primary purpose (one sentence).
Target system name, version, and primary purpose (one sentence).
Business process or event that triggers the need for data transfer (e.g., sales order creation, material master release, invoice posting).
Data element list required by the target system, with format, length, and mandatory/optional classification.
System of record assignment for each data element.
Frequency and volume profile: expected transfers per hour, day, or month; peak load timing.
Non-functional requirements from business: maximum latency, availability window, throughput, security class.
Error handling expectations from business and operations: retry count, alert threshold, escalation path, manual fallback.
Data ownership and governance rules: who can create, change, and approve each data element.
Existing interface documentation, API specifications, or data contracts (optional).

Questions to ask

What business event triggers the need for data to cross this boundary? Is it a creation, an update, a deletion, or a scheduled batch?
Which system is the system of record for each data element that crosses the boundary?
What happens if the interface is unavailable for 1 hour? For 1 day? Does the business process stop, queue, or proceed with stale data?
What validation must occur before data leaves the source system? What validation must occur after it arrives at the target?
How are duplicates detected and handled? Is there a unique key that both systems agree on?
What is the maximum acceptable latency from the business event to data delivery at the target?
Who owns the interface when it fails: the source system team, the target system team, or the integration team?
What is the escalation path if data quality errors are detected at the boundary after delivery?
Does the target system require data in a different format, code set, or unit of measure than the source?
Is there a requirement for audit trail, logging, or compliance documentation across the boundary?

Working method

Identify the business event and trigger. Define the exact business event (sales order created, material released, invoice posted) that causes data to cross the boundary. If the trigger is not a business event but a schedule, state the schedule and the business reason.
Define the data boundary. List every data element that must cross. For each element, state whether it is created, updated, or only referenced. Identify what data stays inside each system.
Classify data elements by ownership and direction. For each element, name the system of record. Classify direction as outbound (source to target), inbound (target to source), or bidirectional. If direction is bidirectional, define the trigger for each direction separately.
Specify frequency, volume, and timing. Quantify how often transfers occur, how many records per transfer, and whether timing is real-time, near-real-time, hourly, daily, or event-driven. Identify peak periods.
Define transformation and validation rules. For each data element that changes format, code, or structure across the boundary, document the transformation rule. Define validation rules at the source exit and the target entry.
Define error handling and recovery rules. For each failure mode (source unavailable, target unavailable, data validation failure, duplicate detected, timeout), specify the expected behavior: retry, alert, queue, manual fallback, or abort.
Define non-functional requirements. Translate business needs into measurable constraints: maximum latency in seconds, minimum availability percentage, maximum throughput in records per minute, security classification, and retention requirements.
Validate with stakeholders. Review the requirement with the source system owner, target system owner, business process owner, and integration team. Confirm that each party agrees on ownership, error handling, and SLAs.
Classify and document. Separate functional requirements (what data, when, how validated) from non-functional requirements (how fast, how available, how secure). Publish the requirement before technical design begins.

Decision rules

If data is created in the source and consumed in the target, the direction is outbound. If the target updates the source, the direction is inbound or bidirectional, and each direction must be specified separately.
If the interface specification lacks an error-handling requirement for at least three failure modes (source unavailable, target unavailable, data validation failure), do not approve it for design.
If the target system has stricter validation than the source, define a transformation or enrichment step; do not assume the source will change.
If the interface is real-time but one system is batch-oriented, flag a frequency mismatch and require a business decision.
If duplicate detection is not specified, assume duplicates are possible and require a detection and handling rule.
If data ownership is unclear for any element, produce an ownership matrix before interface design proceeds.
If the volume exceeds 10,000 records per hour or the latency requirement is under 5 seconds, require performance testing as a non-functional requirement.
If the interface crosses an organizational boundary (external vendor, SaaS, acquired company), include data classification, compliance, and audit requirements explicitly.

Deliverables

Interface Requirement Specification — Document containing business event, data boundary, element ownership, direction, frequency, validation, error handling, and non-functional requirements.
Data Element Boundary Table — Table of all data elements with source system of record, target requirement, direction, mandatory/optional status, and transformation rule.
Error Handling Specification — For each failure mode, the expected behavior, retry policy, alert threshold, escalation path, and manual fallback.
Frequency and Volume Profile — Quantified transfer schedule, peak load, and growth assumption.
Interface Ownership Matrix — For each data element and failure mode, the named owner and escalation contact.

Templates

Interface Requirement Analysis (Markdown format)

## Interface: <Source> to <Target>

### Business trigger


### Data boundary

| Data Element | Source System of Record | Direction | Mandatory? | Format (Source) | Format (Target) | Transformation Rule | Validation (Exit) | Validation (Entry) |
|--------------|------------------------|-----------|------------|-----------------|-----------------|---------------------|-------------------|--------------------|
| Order number | SAP S/4HANA | Outbound | Yes | CHAR 10 | VARCHAR 20 | Prefix with region code | Exists in VBAK | Unique in 3PL |
| Delivery block | SAP S/4HANA | Outbound | No | CHAR 2 | VARCHAR 5 | Map internal code to 3PL code | Valid in TVLS | Recognized by 3PL |
| External ID | 3PL | Inbound | Yes | VARCHAR 30 | CHAR 20 | Strip leading zeros | 3PL validation | Exists in mapping table |
| Shipment status | 3PL | Inbound | No | VARCHAR 10 | CHAR 2 | Map 3PL status to SAP delivery status | 3PL format check | Valid in TVLS |

### Frequency and volume

| Scenario | Frequency | Volume | Peak Timing | Latency Requirement |
|----------|-----------|--------|-------------|---------------------|
| Standard orders | Event-driven | 500/hour | 09:00–11:00 | < 60 seconds |
| Bulk orders | Daily batch | 10,000/day | 02:00–04:00 | < 30 minutes |
| Returns | Event-driven | 50/hour | 14:00–16:00 | < 5 minutes |

### Error handling

| Failure Mode | Retry Policy | Alert Threshold | Escalation Path | Manual Fallback |
|--------------|--------------|-----------------|-----------------|-----------------|
| Source system unavailable | Retry 3x, 5 min interval | After 3 failures | SAP Basis team | Manual IDoc reprocessing (BD87) |
| Target system unavailable | Retry 5x, exponential backoff | After 5 failures | Integration team | Hold in queue, notify logistics supervisor |
| Data validation failure (exit) | No retry | Immediate | Source data steward | Correct in SAP (VA02), re-trigger |
| Data validation failure (entry) | No retry | Immediate | Target data steward | Correct in 3PL, request re-sync |
| Duplicate detected | No retry | Immediate | Integration team | Manual deduplication by logistics supervisor |
| Timeout (> 60s) | Retry 2x | After 2 failures | Integration team | Manual check in SXMB_MONI / WE02 |

### Non-functional requirements

| Attribute | Requirement | Measurement Method | Owner |
|-----------|-------------|--------------------|-------|
| Latency | < 60 seconds (event), < 30 min (batch) | IDoc creation to 3PL acknowledgement timestamp | Integration team |
| Availability | 99.5% during business hours (08:00–18:00) | Monitoring dashboard uptime | Integration team |
| Throughput | 500 events/hour sustained, 1000/hour peak | Message queue depth metric | Integration team |
| Security | Data encrypted in transit (TLS 1.2+) | Certificate audit | Security team |
| Retention | IDoc logs retained 90 days | SAP archiving policy | SAP Basis team |

### Ownership matrix

| Element / Failure | Source Owner | Target Owner | Integration Owner | Escalation Contact |
|-------------------|--------------|--------------|-------------------|--------------------|
| Order number | Sales process owner | Logistics supervisor | Integration team | Integration lead |
| Delivery block | Sales config owner | Logistics supervisor | Integration team | Integration lead |
| Source unavailable | SAP Basis team | — | Integration team | SAP Basis lead |
| Target unavailable | — | 3PL support | Integration team | 3PL account manager |
| Data validation | Source data steward | Target data steward | Integration team | Data governance lead |

### What this interface does NOT do

- Does not perform business logic validation (credit check, pricing) — that happens inside SAP.
- Does not archive data long-term — both systems retain independently.
- Does not serve as a backup for either system.
- Does not handle real-time inventory queries — only order and status events.

Quality checklist

Every data element has a defined source system of record.
Every interface has a named business event trigger, not a technical schedule alone.
Error handling is specified for at least three failure modes: source unavailable, target unavailable, and data validation failure.
Frequency and volume are quantified, not described as "as needed" or "as soon as possible."
Non-functional requirements include latency, availability, and throughput with measurable numbers.
Ownership is assigned for source, target, and integration for each data element and failure mode.
A business stakeholder has validated the requirement, not only technical staff.
The "does NOT do" section clarifies boundaries to prevent scope creep.

Common mistakes

Mistake: Documenting technical interface design (protocol, endpoints, payload structure) instead of requirements. Consequence: The solution is locked in before business needs are fully understood, and change requests are expensive.
Mistake: Omitting error handling requirements. Consequence: Production failures require ad-hoc decisions, cause SLA breaches, and damage trust between teams.
Mistake: Confusing functional requirements with non-functional ones. Consequence: Performance, availability, and reliability issues are discovered late in integration testing or after go-live.
Mistake: Assuming the target system can accept whatever the source sends. Consequence: Data transformation gaps are discovered during integration testing, causing project delays and data quality incidents.
Mistake: Not defining ownership for each data element and failure mode. Consequence: When the interface fails, teams argue about responsibility and resolution time increases.

Weak output vs Strong output

Weak output — Generic interface wish list

The interface should be secure and reliable. It should use a modern API standard like REST or OData. The data should be transferred in JSON format. Error handling should be robust, with retries and logging. The system should be available during business hours. Performance should be fast enough for users.

Why it is weak: No specific data elements, no direction, no ownership, no quantified SLAs, no failure modes, no business event trigger. It is a list of aspirations that cannot be reviewed, tested, or held accountable.

Strong output — Copy-paste ready interface requirement table

## Interface: SAP S/4HANA (IDoc) to 3PL (REST API)

### Business trigger
Sales order created or changed in SAP S/4HANA (type OR) triggers
outbound transfer to 3PL within 60 seconds of save.

### Data elements

| Element | Source | Direction | Mandatory | Target format | Transform | Exit validation | Entry validation |
|---------|--------|-----------|-----------|---------------|-----------|-----------------|------------------|
| VBELN | SAP | Outbound | Yes | VARCHAR 20 | Prefix "SO-" | Exists in VBAK | Unique in 3PL |
| POSNR | SAP | Outbound | Yes | VARCHAR 6 | Zero-pad to 6 | Exists in VBAP | Matches header |
| MATNR | SAP | Outbound | Yes | VARCHAR 18 | No leading zeros | Exists in MARA | Valid in 3PL catalog |
| LFIMG | SAP | Outbound | Yes | DECIMAL | Same | > 0 | > 0 |
| Delivery block | SAP | Outbound | No | VARCHAR 5 | Map TVLS to 3PL code | Valid in TVLS | Recognized by 3PL |

### Error handling

| Failure | Retry | Alert | Escalation | Fallback |
|---------|-------|-------|------------|----------|
| SAP IDoc failure | 3x, 5 min | After 3 | SAP Basis | BD87 manual reprocess |
| 3PL HTTP 4xx | No retry | Immediate | Integration | Correct data in SAP, re-trigger |
| 3PL HTTP 5xx | 5x, exponential | After 5 | 3PL support | Queue + notify logistics lead |
| Timeout > 60s | 2x | After 2 | Integration | SXMB_MONI check + manual retry |

### Non-functional requirements

- Latency: IDoc created to 3PL ACK < 60s (p95)
- Availability: 99.5% during 08:00–18:00 CET
- Throughput: 500 orders/hour sustained, 1000/hour peak
- Security: TLS 1.2+, mutual auth certificate
- Retention: IDoc logs 90 days, 3PL ACK logs 1 year

Why it is strong: It names the exact data elements, transformations, validations, retry policies, and SLAs. An integration team can estimate effort from this, a tester can write test cases, and an operations team can set up monitoring.

Agent instructions

AI Prompt Pattern

You are a systems analyst defining interface requirements for an enterprise SAP landscape. Before you produce any output, gather:
1. The source system name and the target system name.
2. The business event that triggers data transfer (e.g., sales order created, material released, invoice posted).
3. The data element list required by the target system, with format and mandatory/optional status.
4. The system of record for each data element.
5. The frequency, volume, and peak load from the business process owner.
6. The business-defined maximum latency and availability expectations.
7. The error handling expectations from operations: retry, alert, escalation, manual fallback.

Produce the output in the Interface Requirement Analysis template format: data element boundary table, frequency and volume profile, error handling table, non-functional requirements table, ownership matrix. Separate functional requirements from non-functional requirements. For every data element, state the source of record, direction, and validation rules. For every failure mode, state the retry policy, alert threshold, and escalation path. End with a "does NOT do" section.

Do gather the business event, data element list, and stakeholder expectations before producing any output. Do not guess requirements.
Do separate functional requirements (what data, when, how validated) from non-functional requirements (how fast, how available, how secure).
Do specify error handling for at least three failure modes: source unavailable, target unavailable, and data validation failure.
Do name the system of record for every data element. If ownership is unclear, flag it and ask for assignment.
Do quantify frequency, volume, and latency. "As soon as possible" is not a requirement.
Do link to Atlas integration patterns when the interface involves SAP S/4HANA, MDG, or SAP Integration Suite.
Don't write technical design. Do not specify protocols, endpoints, or payload structures unless the stakeholder explicitly requested them.
Don't omit the ownership matrix. An interface without ownership will fail in production with no one accountable.
Don't skip the "does NOT do" section. Scope creep in interface projects is common and expensive.
Don't invent data elements or SLAs. If the stakeholder cannot provide them, list placeholders and ask for confirmation.

Related skills

System Context Mapping — Define the system boundaries where the interface operates.
API Integration — Technical design and implementation of API-based interfaces.
Data Integration and Interoperability — How data flows across systems and how interoperability is governed.
Requirements Elicitation — How to extract and structure stakeholder needs before interface analysis begins.

Related Atlas pages

SAP Integration Architecture — Patterns and constraints for SAP system interfaces.
API Contracts — How API agreements define interface boundaries and responsibilities.
Data Contracts — How data agreements constrain what crosses system boundaries.

Verification status and limitations

This skill is a public working interpretation of interface requirements analysis for enterprise and SAP systems. It is not official BABOK, TOGAF, or SAP integration documentation. It focuses on the practical subset of requirements work that prevents integration failures before technical design begins. It does not cover detailed protocol design, security architecture, or infrastructure sizing. Use it as a structured starting point for requirements workshops and stakeholder reviews, not as a comprehensive framework substitute.