Hello!
I am new to ARCADIA and Capella and I find it very interesting and usefult for our tasks. Before that I used Enterprise Architect … but Capella workflow is much more clean and robust.
I have a question regarding Operational Analysis and Operational Capabilities.
I model a system which collects data from several external systems and combine this data to provide one particular feature (capability) to the User.
I made several Operational Processes describing the processes of receiving Data-Group-1 and Data-Group-2. And create another process from central activity (where all the data is being combined) to the user.
So, there are three OPs describing the capability end-to-end.
What does it mean when I specify all 3 OPs as “Involved Operational Processes” in one particular Capability? That all 3 OPs are implementing this Capability? Or any of these OPs implements this Capability?
Or it is better to create one OP end-to-end from the external system to the user?
Thanks a lot for your replies.
PS I made two OPs for data collection because this data (and this OPs) could be reused for other Capabilities. Like OC-1 = OP1 + OP2; OC2 = OP2 + OP3 etc.
Hi there,
A few comments:
- To answer your question, OPs are “describing” OCs. For one OC, you may have one or (more generally) more OP describing it. So when you specify them as “involved Operational Processes”, this does not mean that they are implementing the OC but they are contributing to explain what your OC is about. You may also use Operational Scenarios to describe your OC, that’s another way to do it
- In the operational analysis, you should not model the system of interest. If you want to model the OC of your system, then you should move to the System Analysis layer.
Stephane
3 Likes
As @StephaneLacrampe did mention in his reply, a capability must likely will have more than one OC. Think about scenarios where the behaviour is performed as expected, “happy day scenario, and others where you may explore the what” ifs", “rainy day scenarios”.
Maybe keep asking the question: “what capabilities the users need from the system.”,will help you to identify capabilitirs, users involved and scenarios (OC).
Think about scenarios as a means for later validation.
The operational analysis is focused on the user needs: what the user need from the system. The system is not considered at this level of the analysis.
The system analysis is focused on what the system must do for the users. It is at this level that the system is first time represented as a “black-box”.
I hope that helps.
1 Like
Thanks a lot for your answer.
Maybe I did it wrong on OA level.
I have an Actor (human) and the new System to develop and several external subsystems (all of them specified as one Oper Entity). These external subsystems are OE and are black boxes for us. We just get data from them and do not modify or develop them. And I’ve specified just some high level Activities for these subsystems. Like “Provide this or that information”.
After that I’ve created several OP: One from subsystems to System. And second from the System to the Actor. So, I use several OPs specified for every OC to declare the full end-to-end chain (from subsystems to new System and to Actor).
Hope I’ve explained it well.
Am I right with such approach?
Or I should not declare any external subsystems on OA level? But they are important parts for the System installation/integration and for the Project in total.
@ekondratiev if you are capturing subsystems at operational analysis, it should only be captured at logical level.
You need to identify and understand what is the system boundary. A subsystem is part of the system, hence, they are within the system boundary, and only visible when it is explored the “white box” (logical architecture).
You may consider to have a look at the Catapult example.
I hope that helps.
@HelderCastro, maybe I was explained it wrong.
Subsystems here aren’t part of the System but external systems (equipment) installed in the whole environment.
And the System gets data from this external equipment. So, this equipment provides some information for the System and for the Actor (human) indirect thru the System interpretation.
Like the car driver gets driving info from the dashboard while dashboard system gets a lot of data from the engine and other onboard equipment.
@HelderCastro, and for this example with a car I’ve created one O-Process from car system to the System (like Engine Information Data Process) and another O-Process from System to the Actor (driver) like (Driving Support Process).
From the Actor PoV it is the System providing him this info(support). But for the System this process comes from the Engine Control Unit.
But now I am start thinking that I should specify only the System and the Actor on OA level… And add those external systems like ECU etc on System Level only. Right?
UPD: Maybe it is similar to Catapult Train Release Use-Case? Train there acts like an external system which provides some data/influence to the System, right?
So, in my case there are around 10 such “trains” all of them are being used for different use-cases.
If the external entities use the system then they probably should be captured at operational analysis.
If the external systems contribute to fulfil the mission system, then they most likely should be captured at system level.
The external systems may be identified and required for the system to fulfil the user needs.
The actor (driver) seems to use the system, hence, rightly captured at OA.
If the external systems are only providing data to the system to fulfil the driver needs, then you may consider to capture at SA.
1 Like
@HelderCastro, thanks a lot! It really helps!
Best regards.
Hi,
Some precisions about the OA: the goal of this Arcadia perspective is to focus on the end-users and stakeholder needs (often in order to simplify we speak just about end-users needs but, for example, some projects mets some major issues forgetting the rulemaking regulation organisms during OA).
In order to reach this goal, indeed it is really not recommended to model the system (in this case, generally we model the SA in OA); you have to identify what are the capabilities of the end users and stakeholders, define their activities and interactions, generally in building the operational processes describing the operational capabilities. It should allow to help you to identify the constraints of the end-users and stakeholders.
Once this work is finished, in SA you have to ask the question how your system can realizes, contributes or not contributes to the operational activities of operational actors and entities.
So, in OA, you should model what you call “subsystem” only if it allows to have a better understanding of end-users and stakeholder needs.
The OA is complex to build (how far you have to go, have I to model the moon 
) but can be very usefull to undestand in which context my system is going to “live”; it allows to discover unexplicit requirement and others.
2 Likes
@SMonier, thanks a lot.
It is much clear now.
) but can be very usefull to undestand in which context my system is going to “live”; it allows to discover unexplicit requirement and others.