Business Analysis Notes

Techniques BABOK Guide v3, 10.24

Interface Analysis

5 min read · Updated

In short Interface analysis finds every point where a solution exchanges information with something else, whether a person, another process, another system or a device, and defines what is exchanged, in which direction, when and with what rules. It clarifies the boundary of the solution and uncovers requirements that are easy to miss until integration testing.

Based on: IIBA, BABOK® Guide v3, technique 10.24 “Interface Analysis”; Watermark Learning, BABOK v3 Study Tables (2016), technique 10.24; D. Gobov, I. Huchenko, State of Business Analysis in Ukraine 2020.

On this page

What it is#

An interface is a connection between two components that lets them exchange information. The BABOK Guide describes interface analysis as working out the details of the information exchanged between components of a solution, or across its boundary. It clarifies the system’s boundaries and gives context for eliciting more detailed stakeholder requirements, so the solution covers everything it needs to.

The BABOK Guide’s list of interface types is broader than “system integrations”:

  • user interfaces, where people interact with the solution;
  • people outside the solution, such as stakeholders who receive reports or messages;
  • business processes that hand work to or from the solution;
  • data interfaces between systems;
  • application programming interfaces (APIs);
  • hardware devices.

The work follows three steps: prepare for identification (gather context: scope, existing documentation, system diagrams), conduct interface identification (find each interface and its purpose), and define the interfaces (describe the information exchanged and how).

It is widely used. In a 2020 survey of business analysts in Ukraine, Gobov and Huchenko found interface analysis among the most common elicitation techniques, after interviews and document analysis.

When to use it#

The BABOK Guide places it in Conduct Elicitation, Assess Requirements Changes (finding interfaces a change affects) and Specify and Model Requirements (identifying and validating the inputs and outputs of the solution). Use it when:

  • the solution must connect to existing systems, partners or devices;
  • you are buying an off-the-shelf product and must fit it into your landscape;
  • a change request arrives and you need to know what else it touches;
  • you want to assign requirements, rules and constraints to the right component.

Its strengths are that it surfaces functional requirements early, helps allocate requirements across the solution, and keeps analysis focused on what crosses the boundary instead of everything inside. Its limit is the same focus: it tells you little about the internals of the solution. Combine it with process, data and use case models.

How to do it#

  1. Draw the boundary. Start from a context diagram or scope model and list every external party.
  2. Identify interfaces by type: users, external people, processes, systems, APIs, devices. Ask each stakeholder “What do you send, receive or look at?”
  3. Name an owner on both sides of each interface.
  4. Define each interface: purpose, direction, trigger and frequency, content (linked to the data dictionary), volume, format or channel, validation rules, error handling, security, and service levels.
  5. Check the content by walking a real case through the interface end to end.
  6. Record dependencies and risks: what if the other side is down, late, or changes its format?
  7. Agree and baseline the definitions with the owners on both sides, and keep them under change control.
  8. Reuse the inventory for impact analysis whenever a change request arrives.

Example#

The Workshop (a fictional chain of bike-repair workshops) lists the interfaces of its planned booking and repair system:

ID Interface Type Direction Content Trigger / frequency Owner (other side) Open questions
I-01 Online booking pages User interface Customer to system Booking request On demand Product owner Mobile-first?
I-02 Message gateway System System to customer Booking confirmation, status messages On status change Messaging provider Delivery receipts? Cost per message?
I-03 Parts supplier ordering System or process Both Parts order, delivery note Daily before supplier cut-off Parts supplier API, file or portal?
I-04 Workshop tablet User interface Mechanic to system Repair progress, parts needed During repair Workshop managers Works offline?
I-05 Card terminal Device Both Payment amount, result At handover Payment provider Is integration needed or manual entry?
I-06 Accounting export Data interface System to accounting Daily sales summary Nightly Bookkeeper Format and cut-off time

Writing I-03 in detail raises a requirement nobody had stated: the supplier only ships next day if orders arrive before a cut-off time, so the system must batch parts orders and warn mechanics when the cut-off is near. I-05 raises a scope question for the owner: integrate with the card terminal now, or keep manual entry for the first release.

Common mistakes#

  • Only listing system-to-system links → include users, external people, processes and devices.
  • Finding interfaces late → build the inventory during early elicitation, not during integration testing.
  • No owner on the other side → agree a named contact before defining content.
  • Defining only the happy path → specify errors, retries, timeouts and what happens when the other side is unavailable.
  • Ignoring volumes and timing → record frequency, peaks and deadlines; they drive design and cost.
  • Designing the other party’s system → define what crosses the boundary, not how the other side works internally.

Checklist#

  • The solution boundary and all external parties are identified.
  • Every interface has a type, direction and purpose.
  • Owners are named on both sides.
  • Content is defined and linked to the data dictionary.
  • Triggers, frequency, volume and timing are recorded.
  • Error handling, security and service levels are specified.
  • Definitions are agreed and under change control.

Sources and further reading#

  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.24 “Interface Analysis”.
  • Watermark Learning. BABOK v3 Study Tables. 2016 (study aid for the BABOK Guide), technique 10.24.
  • D. Gobov, I. Huchenko. State of Business Analysis in Ukraine 2020. DataArt, 2020.