As far as I have understood, it is quite common to define new actors during LA and PA, in response to refinement of the system’s model, without necessarily updating OA and SA. What is not clear to me is if it is then also possible to define new capabilities (or capability realizations maybe?) only at LA/PA level, provided for the newly identified actors.
Honestly, I’d be curious to understand how you understood that. I would probably argue the opposite, as in terms of methodology, you should have identified most of, if not all, your stakeholders at the OA and SA engineering perspectives. SA is where you define the boundary of your system and its interfaces with the external actors.
When you move to the LA/PA levels, you’re actually defining the solution (how the system will work to fulfill the need, and how it is going to be developed and build), in other words, your focus is to define and refine the inside of your SOI, so this is typically not the time when you would focus on discovering external actors.
Your question seems to imply that by default you are not supposed to define new capabilities at the LA/PA perspectives, or it is not possible to do so. If you follow this path, then it means that Capabilities at the LA/PA level are the sames as the ones at the OA/SA perspectives. Although this may be the case for some of them, I would be very careful in assuming this. Generally speaking, this issue here originates from the misconception that SA is a refinement of OA, LA is a refinement of SA, and PA is a refinement of LA. This is generally wrong, especially for the functional part of the model. The relationship between the engineering perspectives is REALIZATION. In other words, if you take a System Capability, at the LA level, you need to ask yourself the question: What are the Logical Capabilities of my system that are required to realize this System Capability? This answer is not a refinement of your System Capability. It is not necessarily “Sub capabilities”. If you’re just doing sub-capabilities, sub-functions, etc… between your engineering perspectives, it means that you are duplicating your model from one perspective to another and then refining it. You loose the value of the Arcadia methodology. You’d be better starting directly at the PA level and do everything in one engineering perspective, it is going to be much more effective in terms of model maintenance.
Let me give you a dummy example:
System Capability (or function) could be:
- Provide answers to customer request
Logical Capability(ies) (or functions) could be:
- Provide access to database of information to operator
- Provide means for communication with customers
- Provide tools to compose answers manually
Or they could be:
- Provide natural language interpretation of customer requests
- Provide automated retrieval of relevant data from knowledge sources
- Provide AI-generated responses to customer requests
- Provide confidence scoring for automated answers
I am just making this up, right. My point here is that these Logical Capabilities or functions are ways to realize the SA ones, not refinement.
I have explained this in a certain number of posts over the years, here’s one for example: Need guidance on Capella usage - #2 by StephaneLacrampe
I hope it helps…
Stephane
Hi Stephane, thanks for your answers. My initial thought comes from the fact that some actors could be related to technology or architectural decision (test equipment, power supply, manufacturing equipment…), thus it would be difficult to identify them precisely before LA/PA; I would rather avoid flowing back to SA/OA elements that are coming up due to considerations specific to LA/PA.
Regarding the next point, I definitely agree that REALIZATION allows to define additional Capabilities (moving beyond simple refinement) starting from the ones identified during previous analyses, but I tend to associate Capabilities to actors, so that’s why I was asking about the possibility of defining new Capabilities (new actors at LA/PA - > new Capabilities at LA/PA).
I also understand that it is indeed possible to address all stakeholders starting from OA, applying a good level of abstraction.
Makes sense.
(To be honest, I would argue that some of these actors should be identified at the SA stage. If you’re in a client-supplier relationship, you may expect your customer that provides the SA that it gives you the Test Equipment Actor that it intends to use to test your system… And if you’re talking about some Test Equipments that appears only at the LA phase because they are here to test only a sub-component that you created and was unknown at the SA layer, one may argue that then they are not external to your SOI but actually internal (ie your SOI is not only the system but the test equipments that you have to provide as well). Same for Power Supply. If it is a general supply power to the system, you may want the stakeholders (client, etc…) to identify and specify them at the SA level, or you may be designing a system that will not match what the customer will be able to provide in terms of supply power, and if it is an internal power supply (let’s say a solar charger), then it is part of your SOI. But anyway, no need to argue here and I am totally comfortable with you identifying new Actors at the LA level, there are certainly a lot of cases where this would apply, but make sure they are actually actors and make sure they are not missing from the SA as it may require/trigger a discussion with your stakeholders, whish is desirable in that case).
But maybe more interesting, to your question, which I understand as “Can the tool do it” : Yes. Not all available diagrams and process paths are available through the activity explorer. Typically at the LA perspective, you can create Capabilities from the project explorer, or you can create capabilities diagrams from the project explorer as well and then create these capabilities from there (see the 2 images below).
I hope this helps.
Stephane