# arc42 section 3: Context and Scope

Checks for section 3 (Context and Scope) of an arc42 document.

Business and technical context, external interfaces

- The conceptual data model contains entities, attributes, relationships and business rules. → [Conceptual Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model.md)
- The model lists entities and their attributes without data types or storage details. → [Conceptual data model building method](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-building-method.md)
- The document gives an overall view of data repositories, their relationships and their owners. → [Data Architecture](https://arc.fuet.ch/concepts/data-architecture/data-architecture.md)
- Analytical data that domains provide is treated as a product with a standardized interface. → [Data reusability and standardized access](https://arc.fuet.ch/concepts/data-architecture/data-reusability-and-standardized-access.md)
- The data architecture describes data entities, not logical or physical storage design. → [Define Target Data Architecture Method Phase](https://arc.fuet.ch/concepts/data-architecture/define-target-data-architecture-method-phase.md)
- A gap matrix is created using the TOGAF Gap Analysis technique. → [Define Target Data Architecture Method Phase](https://arc.fuet.ch/concepts/data-architecture/define-target-data-architecture-method-phase.md)
- External data sources the system uses appear as external systems in the context view. → [Use of external and open data](https://arc.fuet.ch/concepts/data-architecture/use-of-external-and-open-data.md)
- For each open data source, the document states that the data is machine-readable and how it can be obtained. → [Use of external and open data](https://arc.fuet.ch/concepts/data-architecture/use-of-external-and-open-data.md)
- Every diagram has a legend explaining the notation, including line styles. → [Architectural Overview Antipattern](https://arc.fuet.ch/concepts/documentation/architectural-overview-antipatterns.md)
- The overview diagram includes all external interfaces to human users and other systems. → [Architectural Overview Diagram](https://arc.fuet.ch/concepts/documentation/architectural-overview-diagram.md)
- Architectural assumptions are recorded and, where possible, drafted as decision records. → [Architecture Canvas](https://arc.fuet.ch/concepts/documentation/architecture-canvas.md)
- The business context shows the system as a black box with its domain interfaces to each communication partner. → [Business and Technical Context](https://arc.fuet.ch/concepts/documentation/business-and-technical-context.md)
- Business context arrows show data flows, not dependencies. → [Business and Technical Context](https://arc.fuet.ch/concepts/documentation/business-and-technical-context.md)
- Business and technical context are kept as separate views. → [Business and Technical Context](https://arc.fuet.ch/concepts/documentation/business-and-technical-context.md)
- Diagrams are organized by zoom level (context, containers, components, code), and each level zooms into the previous one. → [C4 Model](https://arc.fuet.ch/concepts/documentation/c4-model.md)
- Every container is an application or a data store that must be running for the system to work. → [Container Diagram (C4 Level 2)](https://arc.fuet.ch/concepts/documentation/c4-container-diagram.md)
- Every arrow carries a label naming the data that flows, and a legend explains the notation. → [Context View Antipatterns](https://arc.fuet.ch/concepts/documentation/context-view-antipatterns.md)
- The diagram shows the system as a black box with no internals. → [Context View Antipatterns](https://arc.fuet.ch/concepts/documentation/context-view-antipatterns.md)
- The system boundary is explicit and separates the system from its environment. → [Context View Antipatterns](https://arc.fuet.ch/concepts/documentation/context-view-antipatterns.md)
- The business context shows data flows between the system and its partners, not only dependencies. → [Data architecture documentation in arc42](https://arc.fuet.ch/concepts/documentation/data-architecture-documentation-in-arc42.md)
- Diagrams are stored as plain text in version control, not only as binary or hard-to-compare files. → [Diagrams as Code](https://arc.fuet.ch/concepts/documentation/diagrams-as-code.md)
- The context view shows the system as a black box with its communication partners and external interfaces. → [Essential Architecture Views (Context, Component, Runtime, Distribution)](https://arc.fuet.ch/concepts/documentation/contemporary-essential-views.md)
- Every diagram carries a legend explaining its notation. → [Modeling Method](https://arc.fuet.ch/concepts/documentation/modeling-method.md)
- Every diagram has a title that states its type and scope. → [Rules of Thumb for Modeling](https://arc.fuet.ch/concepts/documentation/rules-of-thumb-for-modeling.md)
- Every diagram carries a legend or key. → [Self-Invented Notation Drawback](https://arc.fuet.ch/concepts/documentation/self-invented-notation-drawback.md)
- Each view or viewpoint states which stakeholders' concerns it serves. → [Stakeholder Questions Addressed in Views](https://arc.fuet.ch/concepts/documentation/stakeholder-questions-addressed-in-views.md)
- The diagram shows the system as one box surrounded by its users and the external systems it interacts with. → [System Context Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-1-system-context-diagram.md)
- The diagram focuses on people and software systems, not technologies. → [System Context Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-1-system-context-diagram.md)
- Neighbouring systems are drawn outside the system boundary, so the scope is clear. → [System Context Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-1-system-context-diagram.md)
- Elements shown in the context view have a short name and business relevance, with detail kept elsewhere. → [Undetected Duplication Antipattern](https://arc.fuet.ch/concepts/documentation/undetected-duplication-antipattern.md)
- The runtime view uses scenarios chosen for architectural relevance, not a large number of scenarios. → [arc42 Architecture Documentation Template](https://arc.fuet.ch/concepts/documentation/arc42-documentation-template.md)
- The context diagram shows the system as a black box with its communication partners around it. → [arc42 Context and Scope](https://arc.fuet.ch/concepts/documentation/arc42-context-and-scope.md)
- The domain data exchanged with each partner is stated, so all stakeholders can understand it. → [arc42 Context and Scope](https://arc.fuet.ch/concepts/documentation/arc42-context-and-scope.md)
- The technical context maps each domain input or output to the channel that carries it. → [arc42 Context and Scope](https://arc.fuet.ch/concepts/documentation/arc42-context-and-scope.md)
- The document lists its bounded contexts and states which subdomain model each one holds. → [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)
- The glossary lists the key domain and technical terms that stakeholders use when discussing the system. → [Business Domain Understanding](https://arc.fuet.ch/concepts/domain-driven-design/business-domain-understanding.md)
- Where meanings differ between parts of the organization, the document separates them into bounded contexts. → [Business Domain Understanding](https://arc.fuet.ch/concepts/domain-driven-design/business-domain-understanding.md)
- The document includes a context map that shows the relationships between bounded contexts. → [Context Map](https://arc.fuet.ch/concepts/domain-driven-design/context-map.md)
- Each relationship is labeled with a named pattern such as Shared Kernel, Open Host Service or Published Language. → [Context Map](https://arc.fuet.ch/concepts/domain-driven-design/context-map.md)
- External systems sit behind a translating wrapper that separates them from own components. → [Deriving System Components from the Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/deriving-system-components-from-the-domain-model.md)
- Each story states whether it describes the current process (as-is) or a future one (to-be). → [Domain Storytelling](https://arc.fuet.ch/concepts/domain-driven-design/domain-storytelling.md)
- The model uses one shared vocabulary that developers and domain experts both understand. → [Domain-Driven Design of the Data Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-modeling-procedure.md)
- The document states which bounded context each term and model belongs to. → [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md)
- The document describes applications as logical groups of capabilities, not as specific computer systems. → [Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/application-architecture.md)
- The application portfolio is kept as a catalog in the architecture repository. → [Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/application-architecture.md)
- The documentation includes a list of all enterprise applications that is agreed and used to define a standard application set. → [Application Architecture Artifacts](https://arc.fuet.ch/concepts/enterprise-architecture/application-architecture-artifacts.md)
- Interfaces between applications are labeled with the technology used, such as REST or FTP. → [Application Interface Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-interface-diagram.md)
- The view is scoped to the application landscape, not to the internals of one software system. → [Application Interface Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-interface-diagram.md)
- Capability maps and value stream diagrams are kept as separate artifacts. → [Business Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/business-architecture.md)
- Applications are linked to the capabilities they support. → [Business Architecture Artifact](https://arc.fuet.ch/concepts/enterprise-architecture/business-architecture-artifacts.md)
- The capability map breaks capabilities into levels, each more detailed than the one above. → [Business Capability](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability.md)
- The map has about seven to ten level-1 capabilities and uses three levels or fewer. → [Business Capability Map](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability-map.md)
- The document states the purpose of the capability map and ties it to strategic decisions. → [Capability Map Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/capability-map-development-method.md)
- No two capabilities overlap; each business function has one home. → [Capability Map Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/capability-map-development-method.md)
- Capability names use nouns or gerunds, not verb-first phrases. → [Capability identification and naming](https://arc.fuet.ch/concepts/enterprise-architecture/capability-identification-and-naming.md)
- The capability map and the process map are separate and linked by relationships, not nested in each other. → [Capability versus process](https://arc.fuet.ch/concepts/enterprise-architecture/capability-versus-process.md)
- A target (future-state) architecture is described and used to steer decisions. → [Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-management.md)
- The document names the layers or domains it uses (business, data, application, technology). → [Enterprise Architecture Layers](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-structure-business-and-it-architecture.md)
- Stage names use a verb and a noun, such as "Process Payment". → [Operational Value Stream](https://arc.fuet.ch/concepts/enterprise-architecture/operational-value-stream.md)
- Baseline and target application architectures are both described, and a gap analysis between them exists. → [TOGAF Phase C: Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-phase-c-application-architecture.md)
- Each story's role matches the primary actor of its use case. → [Consistency of User Story and Use Case](https://arc.fuet.ch/concepts/functional-requirements/consistency-of-user-story-and-use-case.md)
- Every important black box in the building block view has a described responsibility. → [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md)
- Steps are ordered left to right, and vertical placement shows priority. → [Story Mapping](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md)
- Each use case is written as a structured description of how the system responds to requests from external actors. → [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md)
- Each use case is marked with its goal level. → [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md)
- Extensions are listed separately for each use case. → [Use Case Completeness Check](https://arc.fuet.ch/concepts/functional-requirements/use-case-completeness-check.md)
- User-goal use cases each have one actor, one sitting and one measurable outcome. → [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md)
- The main success scenario is a numbered list of simple actor-system interaction steps. → [Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md)
- Use cases in the document are detailed enough to be understood without the author. → [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md)
- Functional requirements are kept apart from quality requirements and constraints. → [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md)
- The most important stakeholder quality goals are stated, for example the top three. → [Architect's Four Key Work Products](https://arc.fuet.ch/concepts/fundamentals/architect-s-four-key-work-products.md)
- The document states whether a piece of work belongs to solution scope or enterprise scope, and does not leave the boundary implicit. → [Architecture Disciplines](https://arc.fuet.ch/concepts/fundamentals/architecture-disciplines.md)
- The document does not describe security as home-built technology when established solutions exist. → [Common Architect Mistakes](https://arc.fuet.ch/concepts/fundamentals/common-architect-mistakes.md)
- The architecture is communicated to stakeholders through views and patterns. → [Software Architect](https://arc.fuet.ch/concepts/fundamentals/software-architect-role.md)
- Quality goals are few, tied to major stakeholders, and kept separate from project goals. → [Software Architecture Basic Concepts](https://arc.fuet.ch/concepts/fundamentals/software-architecture-basic-concepts.md)
- The document states whether one enterprise-wide model or several canonical models with translation between overlaps are used. → [Canonical Data Model](https://arc.fuet.ch/concepts/integration/canonical-data-model.md)
- The document states which integration style connects each pair of applications (messaging, file transfer or shared database). → [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md)
- Where a messaging exchange imposes format requirements such as header fields, the document states that application data is wrapped in a compliant envelope. → [Envelope Wrapper](https://arc.fuet.ch/concepts/integration/envelope-wrapper.md)
- The document states the retention period of the event log and what that means for replay. → [Event Sourcing with Distributed Event Log](https://arc.fuet.ch/concepts/integration/event-sourcing-with-distributed-event-log.md)
- The document states the file format used between each producer and consumer, such as text, XML, or a mainframe feed. → [File Transfer](https://arc.fuet.ch/concepts/integration/file-transfer.md)
- The document states where the format identifier is carried (for example, payload prefix or header) and why. → [Format Indicator](https://arc.fuet.ch/concepts/integration/format-identifier.md)
- The document names the integration style used between each pair of systems (file transfer, shared database, remote procedure call or messaging). → [Integration](https://arc.fuet.ch/concepts/integration/integration.md)
- Each integration point names the integration style used and why it was chosen over the others. → [Integration Styles](https://arc.fuet.ch/concepts/integration/integration-styles-overview.md)
- The document states which channels are point-to-point (one consumer per message) and which are publish-subscribe (a copy to each receiver). → [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- The document names each wire protocol that clients use to reach the broker. → [Messaging Protocol Support in Message Brokers](https://arc.fuet.ch/concepts/integration/messaging-systems-and-protocols.md)
- The document states which subscribers need durable subscriptions so they do not lose messages while disconnected. → [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md)
- The document states how callers handle remote call failures caused by network problems. → [Remote Procedure Call](https://arc.fuet.ch/concepts/integration/remote-procedure-call.md)
- The document names which applications share the database and states that all of them are coupled to its schema. → [Shared Database](https://arc.fuet.ch/concepts/integration/shared-database.md)
- For each integration, the document states whether the exchange is synchronous or asynchronous. → [Software Connector Classification](https://arc.fuet.ch/concepts/integration/classification-of-integration-patterns.md)
- Conversations are drawn as hexagons with a single thin line. → [BPMN Conversation Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-conversation-diagram.md)
- Sub-conversations carry a small square marker with a plus sign. → [BPMN Conversation Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-conversation-diagram.md)
- Conversation links use double thin lines. → [BPMN Conversation Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-conversation-diagram.md)
- Each gateway type matches its routing intent: exclusive picks one path, parallel takes all, inclusive takes all whose condition is true. → [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-core-elements.md)
- A diagram meant as a topic overview omits internal process steps and does not imply message order. → [BPMN Diagram Types](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-diagram-types.md)
- Where message order between participants matters, a collaboration diagram is used rather than a conversation diagram. → [BPMN Diagram Types](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-diagram-types.md)
- Each participating organization in a cross-company process appears as its own pool. → [BPMN Focus on Connected Businesses](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-focus-on-connected-businesses.md)
- Each process model states whether it is a high-level descriptive model for stakeholders or a more detailed analytical model. → [Capturing Business Behavior via Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/capturing-business-behavior-via-process-modeling.md)
- Where a process is meant to be executed, the BPMN model and its XML are identified as the executable level. → [Capturing Business Behavior via Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/capturing-business-behavior-via-process-modeling.md)
- Tasks are named with an object and an infinitive verb. → [Process Analysis](https://arc.fuet.ch/concepts/modeling-bpmn/process-analysis.md)
- Process models use a named, standard notation such as BPMN 2.0 or EPC. → [Process Analysis and Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/purpose-of-process-analysis-and-modeling.md)
- All actors are drawn outside the system boundary box. → [Common Use Case Diagram Errors](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram-modeling-mistakes.md)
- Actor names describe roles, not job titles. → [Common Use Case Diagram Errors](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram-modeling-mistakes.md)
- No database, API, or server appears as an actor or use case. → [Common Use Case Diagram Errors](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram-modeling-mistakes.md)
- Required interfaces are drawn as sockets on the component that depends on them. → [Provided and Required Interface](https://arc.fuet.ch/concepts/modeling-uml/provided-and-required-interface.md)
- Each interface shown in a component diagram is drawn as a ball (provided) or socket (required), or as a class box with the interface stereotype. → [UML Interface](https://arc.fuet.ch/concepts/modeling-uml/uml-interface.md)
- Each diagram has a title naming its type and scope. → [UML Modeling Anti-Pattern](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-anti-patterns.md)
- The diagram draws a system boundary, so it is clear which functionality is in scope and which is not. → [Use Case Diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md)
- Extend relationships are used with care, and their meaning is made clear to readers. → [Use Case Diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md)
- Each include arrow starts at the base use case and points at the included use case. → [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md)
- Behavior shared by several use cases, such as Authenticate, is factored out into one included use case. → [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md)
- The document states which other products a component exchanges information with, and what it shares with them. → [Compatibility](https://arc.fuet.ch/concepts/quality-attributes/compatibility.md)
- The document states which formats or representations each interface uses, and how the parties agree on them. → [Interoperability](https://arc.fuet.ch/concepts/quality-attributes/interoperability.md)
- The system appears as a black box with its communication partners around it. → [Context View](https://arc.fuet.ch/concepts/vision-stakeholders/context-view.md)
- The domain interfaces state which data are exchanged with the environment. → [Context View](https://arc.fuet.ch/concepts/vision-stakeholders/context-view.md)
- Technical interfaces and channels to neighboring systems are documented. → [Context View](https://arc.fuet.ch/concepts/vision-stakeholders/context-view.md)
- Every external neighbor with two-way exchange shows both directions, as two arrows or one annotated arrow. → [Context View Antipattern: Forgetting Bidirectional Data Flows](https://arc.fuet.ch/concepts/vision-stakeholders/context-view-antipattern-forgetting-bidirectional-data-flows.md)
- Each flow is labeled with the data exchanged, and a legend states what arrows mean. → [Context View Antipattern: Forgetting Bidirectional Data Flows](https://arc.fuet.ch/concepts/vision-stakeholders/context-view-antipattern-forgetting-bidirectional-data-flows.md)
- The business context shows data flows, not dependencies. → [Context View Antipattern: Forgetting Bidirectional Data Flows](https://arc.fuet.ch/concepts/vision-stakeholders/context-view-antipattern-forgetting-bidirectional-data-flows.md)
- The top-level context diagram shows the system as a black box and stays an overview without excessive detail. → [Refining Complex Context Views](https://arc.fuet.ch/concepts/vision-stakeholders/refining-complex-context-views.md)
- Where many external systems exist, they are clustered by explicitly stated criteria. → [Refining Complex Context Views](https://arc.fuet.ch/concepts/vision-stakeholders/refining-complex-context-views.md)
- The business context covers all communication partners, users and IT systems, and shows data flows rather than dependencies. → [Refining Complex Context Views](https://arc.fuet.ch/concepts/vision-stakeholders/refining-complex-context-views.md)
- The business context lists all communication partners and is understandable by all stakeholders. → [System Idea and Vision Elements](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea-and-vision-elements.md)