Arcadia Method

Hello,
I am trying to get familiar with the Capella Tool, but more particularly on the Arcadia Method as well.
On the attached document it is described a normal process for Functional Analysis, in this respect if I am not wrong, what it is called “le Besoin” from my diagram, is addressed by the OA Phase of the Arcadia Method and the “Function of services” of the diagram by the SA Phase …
Now the tricky step is to pass from the SA to the LA with Arcadia, a lot of literature is stating that the SA is then refined as top down approach decomposing via internal functional analysis the function of services into functions not perceive by the external context.
It is also usually the approach adopted for SW intensive system and then more appropriate for design, however Arcadia doesn’t propose such decomposition and at this stage, the Arcadia proceed with a bottom up approach, I presume more dedicated for a system view identifying via this process the CIs that will compose the System in per se.
If my analysis here above is correct, I understand then the logic but then come the issue that raise my concern, when we start any analysis of functional services provided by the a system identified by its interaction toward external environment and forming mainly the scenarii of the operations (what the Arcadia SA is doing) and if then we perform a top down (instead of bottom-up) approach of all these identified scenario via an for example an eFFBd methods, focusing on the dynamic approach, and then after we use a structured analysis grouping the identified functions (functions identified via the effbd methods and that form component) as described via the IEEE 1220 Standard, the result will be also a system architecture, I don’t believe that we could find the same result as the Arcadia bottom up !!! Where is the error in my analysis description described above ?
Thank you in advance for your reply.
Frédéric

I think I have discovered the missing point :
I join the 2 attachment here below that is explaining the logic :
On the second graphic :
Inside the Black Border, a Top down Analysis could be done, from top level services function for each scenarii using as example
effbd, in order to reach a dynamical view that represent the functions identified in the SA analysis of the Arcadia Method, as per example here attached.
These Top level functions could be identified as departure procedure and as Control Vehicle Traffic as per page 92, 93 of the book

Hello Frédéric,
your attached document applies well to some lifecycles among those covered by Arcadia : need (on the left) and solution (on the right) are clearly separated, and ‘need functions’ are a way to capture, inside system need Analysis, SA, the user need (usually made of Operational Analysis, OA, and user/customer Requirements mainly).
The solution is built from ‘solution functions’ describing how the system shall behave, and from grouping or segregation of these functions into structural components.
In Arcadia ( and Capella), you can definitely apply your diagram as is: a “top down”, left to right, approach, defining solution functions from need functions. One way of doing so is to decompose each need function into several solution functions, and here again Arcadia and Capella will support you for this (for example, LA functions can be initialised based on a copy of SA functions, so as for you just to refine them as needed). So Arcadia and Capella do propose and support such decomposition
.
But I have to mention that few operational projects, up to now, found this approach sufficient: in your design process, you may want to group parts of different need functions to be mutualised into one single function; you may need to reuse one function into several contexts (and upper level functions); you may want to apply functional patterns that are not aligned with need functions boundaries…
Furthermore, the criteria for organising functions can be different for need and solution: you typically want a functional-based decomposition in need analysis (in the same way as you would chapter your requirements); but in solution, you might want to separate processing functions, user interface functions, external interfaces management functions, safety or security functions… at first levels of decomposition. This will not necessarily match need functions decomposition.
This means that, in spite of a top-down approach, design may lead to a different functional decomposition from need. If so, of course, you should check that each need function is fulfilled by at least one solution function, and Arcadia recommends using justification links between both to formalise this compliance traceability.
For the last part of your description, I am not sure I got it, could you elaborate more?
Just remind that the functions decomposition above is in no means the structural architecture of the solution. Separate from it, another components decomposition will implement the functions, each function being allocated to one component, according to architectural considerations (such a s performance, safety, product line, reuse of existing components, and more).
Jean-Luc

Yes, you are right. But have a look to my answer (written in parallel with your second message).

Yes, thanks Jean Luc for your answer
Now it is more clear