In the op analysis we focus in understanding the user needs. From my understanding, we translate them into operational capabilities. A doubt/question still remains. This is still a “translation”, an “answer” so to say, to the interpretation of the user expressed (or elicited) drivers and needs… and the raw expression and its rationale should also be captured somewhere (and thus assumptions could be reviewed, for instance?).
What would be a best practice to do this? Are we deriving these operational capabilities from requirements, for instance? Do we express this in the Operational Capability description? Do we assume that the scenario connected to the Operational Capability should complement (or address) this issue?
Requirements seems the way to go as they would support the last level of “validation” in the life cycle.
Hi. There are several practices. One powerful one is to build an operational analysis along with your customer and/or key stakeholders. This drives to a shared understanding of their expectations, needs, challenges and pain points. Later on you will be able to propose a solution that addresses them (fully or partially), using for instance the Systems needs Analysis perspective. Hope this helps.
Thanks for your input but my question is a little bit different. Working with the clients/users is paramount.
My point is about capture and register of needs perceptions, expressions, assumptions. Notice that defining an Operational Capability, during the Operational Analysis, is already a result of an interpretation. Off course there is a degree of robustness if this is done and agreed upon with the client. But during the development life cycle people can change and move and the “why” can be lost. so, how to best keep traceability of the “source”… that originated that interpretation.
Here again several alternatives exist. One very simple one is to use the Description tab of Capella elements to document rationales / justifications / assumptions / etc. When rationales apply to several elements, then we can use Constraints or a specialized Requirement using the Requiremets Viewpoint. Finally, some projects document these rationales in their textual requirements database (out of Capella) and create links between Capella elements and them.