By Carrie Alsvary
Below is a summary of BABOK section 7.15 and Agile Techniques 10.24 from the Agile extension to the BABOK guide version 2.
Technique 10.24 – Interface Analysis

Purpose – Interface Analysis is used to identify where, what, why, when, how and for whom information is exchanged between solution components or across solution boundaries.
Description – An interface is a connection between two components or solutions. Most solutions require one or more interfaces to exchange information with other solution components, organizational units, or business processes.
Interface types include:

  • User interfaces, including human users directly interacting with the solution
  • People external to the solution such as stakeholders or regulators
  • Business processes
  • Data interfaces between systems
  • Application programming interfaces (APIs) and
  • Any hardware devices

Interface analysis defines and clarifies the following:

  • Who will use the interface
  • What information is being exchanged through the interface, as well as the volume of the data
  • When information will be exchanged and how frequently
  • Where the information exchange will occur
  • Why the interface is needed, and
  • How the interface is or should be implemented

Identifying interfaces early allows the Business Analyst to elicit more detailed stakeholder requirements, thus ensuring the solution will meet the need. It helps to reveal which stakeholders benefit from or depend upon various components of the solution, and this helps the Business Analyst determine which stakeholders are needed for additional elicitation.


  • Preparing for Identification – The Business Analyst can use many techniques to understand which interfaces need to be identified (document analysis, observation, scope modeling, and interviews). A context diagram can reveal high-level interfaces between human actors, organizational units, business processes, or other solution components. The results of the analysis can reveal how existing interfaces are being used and help to strengthen the cause for a change. The results may also help identify any key issues that need to be resolved in order for an interface solution to be created.


  • Conduct Interface Identification – Business Analysts identify what interfaces are needed in the future state for each stakeholder or system that interacts with the system. The relationship between stakeholders and interfaces can be many-to-many or, in some cases, one-to-one. Some interfaces may be less obvious or less frequent such as an interface used for regulatory functions or auditing, or for employee training. Identified interfaces can include interfaces from solutions other than the operational solution.

For each interface, Business Analysts:

  • Describe the function of the interface
  • Assess the frequency of the interface usage
  • Evaluate which type of interface may be appropriate, and
  • Elicit initial details about the interface


  • Define Interfaces – The requirements for an interface are primarily focused on describing the inputs and outputs from that interface, any validation rules that govern the inputs and outputs, and events that might trigger interactions. There may be a large number of interaction types, and each one will need to be specified. Interactions may be triggered by the typical or alternate flow of inputs and outputs in the business solution, or by exceptional events such as failures.

Business Analysts consider who will use the interface, what information is passed over the interface, and when and where the interface takes place. The interface defines user workflow between systems, user roles and privileges, and any management objectives for the interface. Interface definition is dependent upon usability guidelines, such as accessibility requirements or general workflow requirements.
In order to identify any major design issues, interfaces between solution or process components and people require detailed analysis of the interface to be conducted up front. Interface definition includes:

  • The name of the interface
  • The coverage or span of the interface
  • The exchange method between the two entities
  • The message format, and
  • The exchange frequency.

Usage Considerations – Strengths

  • By engaging in interface analysis early on, increased functional coverage is provided
  • Clear specification of the interfaces provides a structured means of allocating requirements, business rules, and constraints to the solution
  • Due to its broad application, it avoids over analysis of fine detail.

Usage Considerations – Limitations

  • Does not provide insight into other aspects of the solution since the analysis does not assess the internal components.

Agile Extension 7.15 – Reviews
Purpose – Reviews help to determine if the planned solution aligns with the need.
Description – Reviews demonstrate a working solution in order to solicit feedback. This can be formal or informal and is performed by the team that completed the work. Reviews are most successful when they tie the work to the vision, objectives and goals for the organization and the initiative.
Elicit feedback early and often to increase the chances that the solution will effectively meet the need. The process of eliciting feedback can empower the team.
This also allows the product owner or customer representative to use the feedback to prioritize the next features to develop and to include in the backlog.

  • Solution Being Delivered

Reviews demonstrate part of the completed solution that is being delivered. This is something tangible to which stakeholders can react and provide feedback to.

  • Stakeholders

Reviews include:

  • Key Stakeholders: These are the stakeholders that are best able to provide feedback regarding if the completed solution will meet the need.
  • Team: All team members working on the initiative are present to facilitate discussion and elicit feedback.
  • Product Owner/Customer Representative/Product Manager: the decision maker who leads the initiative and is responsible for ensuring the feedback on the solution is solicited from stakeholders.

Usage Considerations – Strengths

  • Elicits feedback in an informal manner from stakeholders
  • Lightweight facilitation and conducted on a regular cycle
  • Serves as a check point for the team to validate whether they are on track to deliver the solution when needed
  • Face-to-face communication is preferred
  • Engage stakeholders as early as possible
  • Continue regular engagement with stakeholders during the Delivery Horizon

Usage Considerations – Limitations

  • If Reviews include a wide range of stakeholders, feedback can be too varied for the team to analyze and act upon effectively
  • If hierarchy is highly valued within an organization, higher ranked stakeholders’ feedback could be considered more important than other feedback, regardless of their interaction and understanding of the product or service goals.