Generally speaking, OA/SA are about the need so there should be nothing about “how the system will fulfill its expectations”. Nevertheless, there could/can be physical constraints or design decisions that are part of the need…
At the OA stage, you should not model anything about the system of interest. You are interested in the context, in the stakeholders’ needs, and the environment.
At the SA level, the System is a black box and you’re interested in defining its boundaries.
Now having said that, first I would say that you are right, this is hard, and it is a very good sign that you are finding it hard because you are asking yourself the right questions. Then it becomes easier with practice I think, but still, these are always important questions to ask yourself. Also, one other type of question which is very important is: “to what level of modeling do you drill down to?”
I have not looked at the Level-Crossing example for some time so my answers may not be accurate, but:
- “In the Level-Crossing example the Emergency Stop mode is added at the System level. Why wouldn’t adding an emergency stop mean going back to the Operational level and designing it there first?” -> This is a mode of your system of interest, you are not modeling the system of interest at the OA level.
- “Would new ‘Enable train movement’ and ‘Disable train movement’ operational activities be required which would become switching the power off/on at the system level?” -> Maybe: there could be a situation where you could say that enabling/dissabling train movement is done only by an operator (a person) and that the crossing system is ringing a bell to alert the operator to stop or start the train. Obviously, nobody would do that, but I am just illustrating the decisions you are making at the system level: deciding what are your system boundaries means deciding which functions are part of your system, and if “disabling train movement” is part of your system, it has some important consequences on the design and cost of your system as it is a high safety concern.
- “For example, in this case with the emergency stop we have decided that one is required, and also how to implement it (power off) at the same stage. My understanding so far is that we should try to separate what we are trying to achieve and how we will do it.” -> Yes you are right. But there may be a train regulation about level-crossing systems that when a car or an obstacle is detected on the level-crossing platform, then the level-crossing platform should disable the power of the train. In that case this becomes a requirement on your system.
Another top maybe: think that people making needs models (OA/SA) and Solution models (LA/PA) may not be from the same organization. A regulatory organization may be doing your need model about the level-crossing system, and hand it over to suppliers for pricing and building it. So what you put at which level on your model is sometimes a question of responsibility: Is the regulatory organization imposing to power off the train, if yes then this should be in the need model that is sent to the suppliers.
One final point: the level crossing example is just an example, and it has not been done by someone from this field/domain. So this model may be very different from what is done in reality, the goal of this model is to illustrate the Arcadia method, not to be an accurate level-crossing model.
I hope this helps.