page_title: Arcadia (engineering)
section_title: Presentation of the approach and key concepts
hierarchical_section_title: Arcadia (engineering) / Presentation of the approach and key concepts
caption_attribution_description: Français&#160;: Décomposition en phase d'ingénierie
context_page_description: ARCADIA is a system and software architecture engineering method, based on architecture-centric and model-driven engineering activities.
context_section_description: The first level views used to elaborate and share the architecture model are described below:
  "Define the Problem – Customer Operational Need Analysis",
  The first step focuses on analysing the customer needs and goals, expected missions and activities, far beyond System/SW requirements. This is expected to ensure good adequacy of System/SW definition with regards to its real operational use – and define IVVQ conditions.
  Outputs of this step consist mainly in an "operational architecture" describing and structuring this need, in terms of actors/users, their operational capabilities and activities, operational use scenarios giving dimensioning parameters, operational constraints including safety, security, lifecycle, etc.
  "Formalisation of System/SW Requirements – System/SW Need Analysis",
  The second step focuses now on the system/SW itself, in order to define how it can satisfy the former operational need, along with its expected behaviour and qualities: system/SW functions to be supported and related exchanges, non functional constraints (safety, security...), performances allocated to system boundary, role sharing and interactions between system and operators.
  It also checks for feasibility (including cost, schedule and technology readiness) of customer requirements, and if necessary gives means to renegotiate their contents. To do this, a first early system/SW architecture (architectural design model) is sketched, from system/SW functional need; then requirements are examined against this architecture in order to evaluate their cost and consistency.
  Outputs of this step mainly consist of system/SW functional Need description, interoperability and interaction with the users and external systems (functions, exchanges plus non-functional constraints), and system/SW requirements.
  Note that these two steps, which constitute the first part of Architecture building, "specify" the further design, and therefore should be approved/validated with the customer.
  "Development of System/SW Architecture – Logical Architecture",
  The third step intends to identify the system/SW parts (hereafter called components), their contents, relationships and properties, excluding implementation or technical/technological issues. This constitutes the system/SW logical architecture.
  In order for this breakdown in components to be stable in further steps, all major [non-functional] constraints (safety, security, performance, IVV, Cost, non technical, etc.) are taken into account and compared to each other's so as to find the best compromise between them. 
  This method is described as "Viewpoints-driven", viewpoints being the formalization of the way these constraints impact the system/SW architecture.
  Outputs of this step consist of the selected logical architecture: components and interfaces definition, including formalization of all viewpoints and the way they are taken into account in the components design. 
  Since the architecture has to be validated against Need, links with requirements and operational scenarios are also produced.
  "Development of System/SW Architecture – Physical Architecture",
  The fourth step has the same intents as logical architecture building, except that it defines the "final" architecture of the system/SW at this level of engineering, ready to develop (by lower engineering levels). Therefore, it introduces rationalization, architectural patterns, new technical services and components, and makes the logical architecture evolve according to implementation, technical and technological constraints and choices (at this level of engineering). 
  Note that the same "Viewpoints-driven" method as for logical architecture building is used for physical architecture definition.
  Outputs of this step consist of the selected physical architecture: components to be produced, including formalization of all viewpoints and the way they are taken into account in the components design. Links with requirements and operational scenarios are also produced.
  "Formalize Components Requirements – Contracts for Development and IVVQ",
  The fifth and last st
caption: Breakdown
exif: {}