# Functional and non-functional integration requirements

*Integration Architect Study Guide · Evaluate Business Needs · Last updated October 16, 2026 · https://www.certifyforce.com/study-guide/integration-architect/evaluate-business-needs/functional-and-non-functional-integration-requirements*

How to sort integration requirements into what the integration does and how well it must do it, which requirements decide timing (wait, fire, batch or events), and how to turn vague availability, cost and support wishes into measurable objectives.

- Certification: Salesforce Integration Architect
- Exam section: Evaluate Business Needs
- Study guide: https://www.certifyforce.com/study-guide/integration-architect

**Official exam objective:**

> Given a use case, identify functional and non-functional requirements needed for integration.

## What the exam expects

- Classify a stakeholder statement as a functional requirement (what data moves and what business behavior happens) or a non-functional requirement (response time, concurrency, volume window, availability, recovery).
- Pick out the requirement that decides timing: a person waiting, an infrequent change cadence, or surges and new consumers that favor events.
- Ask the question that settles direction (which system is the source of truth) and turn "must never be down" into measurable objectives.
- Capture total cost of ownership and the maintaining team's skills as requirements.
- Key terms: **functional requirement** (a capability or data movement the integration must deliver); **non-functional requirement** (a quality the integration must meet, such as latency or availability); **SLO** (service level objective, a measurable reliability target); **RPO / RTO** (maximum acceptable data loss window / maximum acceptable downtime); **source of truth** (the system whose value wins and from which data flows).

## Key facts

| Fact | Detail | Source |
|---|---|---|
| SLOs typically measure | Availability, latency (p50/p95/p99), throughput, error rate, recovery time | [Reliability](https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html) |
| RTO vs RPO | RTO = maximum acceptable downtime; RPO = maximum acceptable data loss window in time | [Reliability](https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html) |
| Directionality question | "What system should be the source of truth?" sits in the data flow area | [Data Integration with Salesforce](https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html) |
| Maintainability area | Maintaining team, its skills, total cost of ownership, low/pro-code debugging | [Data Integration with Salesforce](https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html) |
| Human waits for a response | Not a fit for event-driven architectures (asynchronous, no guaranteed response time) | [Event-Driven Architectures](https://architect.salesforce.com/docs/architect/decision-guides/guide/event-driven.html) |
| Infrequently changing source data | Use batch patterns instead of events | [Event-Driven Architectures](https://architect.salesforce.com/docs/architect/decision-guides/guide/event-driven.html) |
| Event-driven good fits | Surges, multiple consumers, frequent new systems or devices, IoT, offline mobile | [Event-Driven Architectures](https://architect.salesforce.com/docs/architect/decision-guides/guide/event-driven.html) |
| Request and Reply vs Fire and Forget | Salesforce waits for completion vs hands off without waiting | [Pattern Summary](https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_pat_summary.htm) |
| Availability vs cost | Higher availability costs more; SLOs match investment to business need | [Well-Architected Framework](https://architect.salesforce.com/docs/architect/well-architected/guide/framework.html) |
| Maintenance share of capacity | Typically 60–80% of development capacity for mature solutions | [Resource and Cost Optimization](https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization.html) |

## Check yourself

- When is an event-driven design a poor fit even though the systems support events?
- Which discovery question settles data-flow direction?
- Why should an architect turn "never down" into an SLO instead of building maximum redundancy?
- What two requirements answer a CIO's worry that an integration will be costly to support after the partner leaves?

## Sources

- [Data Integration with Salesforce](https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html)
- [Using the Right Tools and Patterns for Event-Driven Architectures](https://architect.salesforce.com/docs/architect/decision-guides/guide/event-driven.html)
- [Reliability | Well-Architected](https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html)
- [Well-Architected Framework](https://architect.salesforce.com/docs/architect/well-architected/guide/framework.html)
- [Resource and Cost Optimization | Well-Architected](https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization.html)
- [Pattern Summary](https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_pat_summary.htm)

## About the full unit

The "Core concepts", "Exam traps" and "Worked scenario" sections of this unit, its 9 linked practice questions, and unlimited timed mock exams are included with the Integration Architect pack (USD $19): https://www.certifyforce.com/practice-exams