Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH.M.040 Method for definition of capabilities

1. General introduction to use cases

In ARCADIA the concept of capabilities is used to described the highest level to abstract functionality, this concept is similar to use cases which are used in UML and SysML. Therefore in the following sections the main parts of the use case concept are described with representative key elements out of some MBSE books. This will help to understand the concept of capabilities. If you want to have detailled information please check out following books in detail: "A Practical Guide to SysML", "SysML distilled" or "SysML for Systems Engineering - A Model-Based Approach"

High level definitions of use cases

  • In A Practical Guide to SysML, third edition, Sanford Friedenthal, Alan Moore, Rick Steiner explains further: "Use cases described the functionality of a system in terms of how it is used to achieve the goals of its various users. The users of a system are the described by actors which may represent external systems or humans who interact with the system. A use case describes the goal of a system from the perspective of the users."
  • In SysML for Systems Engineering - A Model-Based Approach, third edition, Jon Hold and Simon Perry: "A Use Case is finally defined as a Need that is considered in a specific Context and that is further described by one or more Scenario."
  • In The Unified Modelling Language Reference Manual, second edition, James Rumbaugh, Ivar Jacobson, and Grady Booch define a use case as a “specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside objects to provide a service of value.”
  • In Writing Effective Use Cases, p. 1, Alistair Cockburn explains it this way: "A use case captures a contract between the stakeholders of a system about its behaviour. The use case describes the system’s behaviour under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behaviour, or scenarios, can unfold, depending on the particular requests made and the conditions surrounding the requests. The use case gathers those different scenarios together."

Key elements of use cases

Focussing on the content of use cases the key elements to define system’s use cases are described as follows. These are taken from the book "SysML distilled - A brief guide to the systems modelling language" by Lenny Delligatti.

  • A use case is a service/a behaviour that your system will perform. The use case name, therefore, is always a verb phrase.
  • Not every behaviour your system performs is a use case. Rather, use cases are the subset of system behaviours that external actors can directly invoke or participate in.
  • An actor can be a person or an external system that interfaces with your system.
  • The actors that invoke a use case are called primary actors. The actors that participate in the use case are called secondary actors. A primary actor can also be a secondary actor.
  • Each use case should represent a primary actor’s goal. Write the use case name -the verb phrase- from the perspective of the actor and not your system.
  • The use case name does not convey a lot of information. You will create a use case specification for each use case to narrate how your system and its actors collaborate to achieve the use case goal.

Specification of use cases

Furthermore as a starting point for a use case specification the book "SysML distilled" proposes the following:

Contents of a use case specification (excerpt)

The use case specification conveys the narrative that unfolds when a primary actor invokes the use case. Traditionally, use case specifications have been text documents. Alistair Cockburn offers an excellent use case specification format in his book Writing Effective Use Cases:

  • Use case name: a verb phrase
  • Scope: the entity that owns (provides) the use case (for example, the name of an organisation, system, subsystem, or component)
  • Primary actor: the actor that invokes the use case (the actor whose goal the use case represents)
  • Supporting (secondary) actors: actors that provide a service to the system (participate in the use case by performing actions)
  • Stakeholder: someone or something with a vested interest in the behaviour of the system
  • Pre-conditions: the conditions that must be true for this use case to begin
  • Guarantees (post-conditions): the conditions that must be true at the end of the use case
  • Trigger: the event that gets the use case started
  • Main success scenario: the scenario (the sequence of steps) in which nothing goes wrong
  • Extensions (alternative scenario): alternative sequences of steps branching off of the main success scenario
  • Related information: whatever your project needs for additional information

Note: It´s typical, on the first try, to create use cases that are too broad and too high level. If you do that, you´ll discover the problem when you try to write the use case specification. The narrative will have many decision points and many paths to execution that you regard as nominal (success) scenarios. Consider this a red flag. You need to refine each use case by using more precise verbs. You will know that a use case is at an appropriate level of granularity when it has exactly one main success scenario. All other paths of execution through the use case specification should be error or exception sequences.

1.1. Use case diagrams

The use case diagram provides a high-level description and visualisation of functionality that is achieved through interaction among systems or system elements and actors in a respective context. On a use case diagram all the relationships of use cases are shown. but no use case specification.

1.2. Use case relationships

Use cases which are related to actors and to other use cases can have different types of relationships.

Association

This is used to relate use cases to actors, is a simple unadorned line with neither name nor multiplicity as can been seen in the bidirectional association between Actor 2 and Use Case 1.

Specialisation/generalisation

A generalisation relationship shall be used to link the former to abstract use case with the refined use case. Generalisation between use cases allows for inheritance of behaviour and relationships. Specialisation/generalisation is shown by a line with an unfilled triangular arrowhead at one end. Specialisation refers to the case when a use case is being made more special or is being refined in some way. As in the diagram "Use Case 2" is a special kind of "Use Case 1".

Inclusion

This is used when a piece of functionality may be split from the main use case, for example to be used by another use case. A simple way to think about this is to consider the included use case as always being part of the parent use case. This is used to try to spot common functionality among use cases. It is highly possible that one or more of the decomposed use cases may be used by another part of the system. It is shown using a dashed line with an open arrow head, the line bearing the stereotype «include». The direction of the arrow should make sense when the model is read aloud. As in the diagram the base Use Case 1 includes Use Case 3 (the name base use case is equal to the name parent use case).

Note: A base use case is any use case that is connected to a primary actor via an association relationship. This means that a base use case is one that represents a primary actors goal.

Extension

This is used when the functionality of the base use case is being extended in some way. A simple way to think about this is to consider the extending use case as sometimes being part of the parent use case, which its functionality may change, depending on what happens when the System is running. Extending use cases are often used to capture special, usually error-handling, behaviour. The extend relationship is also shown using a dashed line with an open arrow head, the line bearing the stereotype «extend». It is important to get the direction of the relationship correct, as it is different from the «include» direction. The direction of the arrow should make sense when the diagram is read aloud. As in the diagram the Use Case4 extends the base Use Case1.

Technically, in a base use case, if there are alternative scenarios that have different post-conditions, different actors involved, triggered by something and could be considered as special behaviour, then may be an extending use case of the base ucse case should be created. Those extending use cases have different post-conditions, have an observable effect to new actors, considered as error handling behaviour and also share common behaviour. The concrete separation between base use case and extending use case should be done through extension point. Those extension points could be represented as a condition of a decision node of the base use case. If the condition is true, then the Extend action is performed.

2. General introduction to capabilities

As mentioned before there are not so many differences between the use case concept, e.g. given in SysML and the capability concept from ARCADIA that is used in the Capella tool. Only the relationship between a capability and an actor is called involvement relationship (SysML equivalent: Association relationship). The other relationships are called in the same way in both concepts so they do not need to be described again, sometimes the definition of a capability is a bit different but this is explained in the section below for each of the different architectures (Operational, System, Logical, Subsystem).

Capability diagrams are available at every engineering phase in Arcadia, but are particularly useful in operational analysis and system analysis. Two kinds of diagrams can be created for capabilities either the context of one capability of interest (COC, CC, CCRI) or the consolidated capability diagram (OCB, MCB, CRB). The context of one capability diagram shows only one capability of interest with its relationships to other capabilities and its involved actors. The consolidated capability diagram shows multiple capabilities and all their relationships. The consolidated capability diagrams should group capabilities on a similar theme. Capabilities may appear on multiple diagrams if they cross multiple themes.

The following example shows a subset of the capabilities that focus on a given aspect of the system and the relationships between them, to show that the relations between capabilities are equal to the relationships between use cases. 

 

Capabilities 5 and 6 involve Stakeholder 1, because they are types of Capability 4, which has a direct involvement relationship with Stakeholder 1. Capabilities 1 and 2 both involve Stakeholder 1, because Capability 4 is included within Capabilities 1 and 2. Capability 3 involves Stakeholder 1, because Capability 3 extends Capability 4, which has a direct involvement relationship with Stakeholder 1.

3. How to consolidate a set of capabilities

The following points needs to be considered to comprise the analysis of a set of capabilities.

  • Grouping: Organising the capabilities into groups will bring structure to the viewpoints and facilitate understanding. The groups are functional nature and/or depend on stakeholder allocation. Set relations (include, extend, generalise) between the system capabilities if required.
  • DuplicatesWhere duplicate capabilities exist, they should be eliminated. Ensure that a duplicate is replaced by the master item on all views where it appears, BEFORE deleting the duplicate. On deletion, the duplicate should no longer be related to any other model element.
  • If a deletion is not reasonable an inclusion, extension or generalisation relation between the capabilities should be considered. If the capabilities just "sound" similar, but have different meanings, their names should be changed.
  • Gaps: Gaps between the capabilities should be checked to ensure that nothing important has been missed. When there are obvious gaps identified the missing capabilities should be added. Nevertheless, the root cause of the lack should be identified to make sure this capability is required and was not omitted mistakenly.
  • Naming: The names of the capabilities must be consistent. They should use similar language and terms.
  • Ensure that all missions are linked to system capabilities to define which system capability is used by a mission (only system analysis).
  • Overlaps: The capabilities start conditions corresponding to the end conditions of other capabilities (and vice versa). Overlaps should be avoided. This may results in updating the pre- and post-condition.

Notes:

  • Operational capabilities that cannot be achieved by the system only have been transferred to the system level as missions.
  • Ensure that all missions are linked to system capabilities to define which system capability is used by a mission (in Capella the link is called "Capability Exploitation" link).

4. Operational capabilities as part of the operational analysis

4.1. Definition of operational capabilities

An operational capability is an ability, expected of one or more operational entities. The operational capability provides a service contributing to fulfilling a high-level goal to which one or more operational entities should contribute, and which is likely to influence system definition or usage. It is characterised by a set of operational processes and scenarios describing more precisely the conditions for performing the operational activities that contribute to it. Operational capabilities are similar to use cases. They describe the application of the system from the point of view of the user/operational entity.

4.2. Guidance to create a set of operational capabilities

It is useful to define only enough operational capabilities to provide a starting point for understanding the problem space at the beginning. Therefore any practical Brainstorming techniques or method to identify candidates can be performed. It is important that the decisions are justified, with a rational by agreeing a reasonable level and size. As part of the brainstorming it is not necessary to identify all dependencies/relationships between operational capabilities, nor to define very precise and synchronised start/end conditions at this stage. However, there should be some idea of these properties so that they can be used as a starting point and later be completed.

Operational capabilities are difficult to define empirically. The following attempts to provide some subjective guidance:

  • Operational capabilities are behavioural needs on a high abstraction level phrased as a Goal to be achieved;
  • Operational capabilities can be thought of as use cases or user stories where the user/primary actor that desires the goal is an operational entity and is explicitly identified;
  • An operational capability represents a context for fulfilling part of a mission without prejudice to the nature of the solution that could or should address it;
  • The wider system of interest needs to have an operational capability in order to meet the needs of its stakeholders;
  • Operational capabilities always deliver an observable result to one or more operational entities;
  • The observable result is delivered by an entity/actor of the wider system of interest (otherwise it is out of scope for the project of interest);
  • Operational capabilities have starting and ending conditions; between the start and end, there is some interaction between entities in the environment;
  • The capability title should be constructed as a verb-noun fragment. For example "plan a mission" is an operational capability wanted by a number of operational entity including the railway undertaking;
  • Consider whether the noun should be abstract, singular or plural; this makes a difference to how it is implemented - are we thinking about something to do with a single train unit, or the whole set of train units, for example?

Some aspects that might indicate that a concept is not an operational capability:

  • It is expressed in terms of what the system of interest needs to do (candidate for a system capability);
  • It delivers no observable result to any other operational entity (candidate for an operational activity);
  • It only expresses part of a larger sequence of interactions between operational entities (candidate for an operational activity);
  • It invokes quality characteristics (e.g. "Ensure safety", "Deliver punctual service", "Reduce delay") (candidate for rephrasing into measures of effectiveness, to be modelled as constraints on other capabilities);
  • It is expressed as a noun (e.g. "Safety", "Reliability"...).

As part of the completion of an operational capability the following tasks should be done:

  • Precise the pre- and post-conditions of the operational capability;
  • Check and complete the involved entities or actors of the operational capability;
  • Check and complete the relationships with other operational capabilities;

In some situation is may useful to split a operational capabilities. There are reasons why an operational capability of interest needs to split into more refined capabilities. These are due to:

  • the identification of several success scenarios;
  • different operational processes;
  • different preconditions;
  • different stakeholders involved with different intentions.

5. System capabilities as part of the system analysis

5.1. Definition of system capability and system mission

A system mission is a high-level goal to which the system should contribute. To be fulfilled, a mission should use a number of system functions, regrouped within one or more system capabilities. A mission can be broken down into submissions with more limited scope. 

The system capability as part of the the system analysis is the system’s expected ability to provide a high-level service allowing it to carry out an operational objective and to fulfil one or more missions. A system capability represents a system usage context. It is characterised by a set of functional chains and scenarios that it references, and which more precisely describes the conditions for performing the system functions that contribute to it. A capability can also reference a function that contributes to it by itself. A capability can use one or more other capabilities that it will reference. 

Although the ARCADIA method describes system capabilities from the system perspective. We have decided that a deviation from the established method is preferred for our purposes. So the system capabilities shall be written from an actor's perspective, similar to use cases. 

5.2. Guidance to create a set of system capabilities and system missions

System capabilities and system missions can be derived from the content of the operational analysis, therefore it needs to be decided for each operational capability and each operational activity whether they should be represented as a system capability, a system mission, or have no representation. The decision on which system level model element it shall represent the operational capability or activity, will be made on the basis of the criteria explained in the following section.

In the absence of a consistent operational analysis in the model under development, system capabilities and missions cannot be derived from there and must be defined independently. This can be done on the basis of brainstorming, using available operational concepts, even if an operational analysis is not explicitly present in the model. It could be the case that multiple operational concepts must be considered (e.g. from different IMs). The definition of all potential system capabilities and missions must be performed and later a consolidation of the potential system capabilities leads to a final set of system capabilities. A system capability which is defined independent of the operational analysis model must fulfill the same criteria as defined in the following section. 

The decision and rationale for the creation of each of the system capabilities and system missions shall be documented.

5.2.1. Operational capability to system capability transition rationale

An operational capability shall be transitioned to a system capability if it is achieved fully or in part by the system of interest. Furthermore, it must be assured that the entirety of the operational capability (from its pre-conditions to its post-conditions) will remain in one piece after transitioning to the system level, as shown in the following sketch:

The assurance that the operational capability fulfills those criteria must be made by analysing its pre-conditions and post-conditions along with the decisions made on the system boundary. All interactions contained in the operational capability will be transitioned into functional exchanges between system actors and the system.

5.2.2. Operational capability to system mission rationale

An operational capability shall be transitioned to a system mission if the operational capability will be achieved in part by the system; AND given the system boundary, the starting and ending conditions of the operational capability will not be the same as the starting and ending conditions of a system capability. In other words, looking at the operational process, not all those activities will become functional exchanges between a system actor and the system.

If the operational capability is achieved entirely without use of the system, make sure that no interaction between operational and system capability exists. This should be rare but is not impossible, depending on the decisions made on the system boundary.

5.2.3. Operational activity to system capability rationale

An operational activity shall be transitioned to a system capability, if it is expected that

  • the activity will be broken out into a set of system and actor functions AND
  • the activity is expected to be triggered by a system actor AND
  • the activity is expected to yield an observable valuable result to one or more system actors AND
  • the activity is not already contained within the process of an operational capability that has been directly traced down as a system capability.

6. Realised capabilities in the logical architecture

For the most part, the system capabilities/logical capability realisations can stay at the same level of granularity for the logical architecture. To show possible refinements/adjustments of the capabilities and also to support simulation and integration, verification, and validation activities the "capability realisations" still need to be shown on a dedicated viewpoint. Because this viewpoint is a statement of the capabilities that will may be tested in the simulation of the logical architecture. During decomposition of logical functions it may arise that a system capability must be split or specialised because the functional splitting results in variations of the functional chain.

Important note: The amount of refinement of capability realisations at logical architecture level should be kept to the minimum necessary, because each new capability realisation creates new work to do in verification and validation. Further refinement will be allowed at subsystem architecture level (which is modelled in the physical architecture level in Capella).

6.1. Refine the system capabilities at logical architecture level

The following example (non-exhaustive) demostrates under which conditions it may be appropriate to refine the system capabilities for the logical architecture.

After functional decomposition, the capability's value can be independently delivered to two or more actors. This means that the end conditions of the capability can now be expressed in two or more independent groups. The capability realisation should be refined by capability generalisation - there are now two independent types (CR 1.1 and CR 1.2) of the original capability.

After functional decomposition, a functional chain portion is defined that can be separated off and reused as a capability in its own right. In this case, the new capability realisation should be included in the capability realisations where it belongs to.

7. Realised capabilities in the subsystem architecture

In many cases, the system capabilities/logical capability realisations can stay at the same level of granularity for the subsystem architecture. To show possible refinements/adjustments of the capabilities and also to support simulation and integration, verification, and validation activities the "capability realisations" still need to be shown on a dedicated viewpoint. Because this viewpoint is a statement of the capabilities that will may be tested in the simulation of the subsystem architecture.

After the definition of the subsystems it is possible to capture the need to refine/adjust the capabilities. Either logical components and the allocated function was further decomposed then it may arise that a capability realisation must be split or specialised because the functional splitting results in additional variations or some logical components may need to be instantiated several times within different subsystem boundaries (for example, diagnostics, configuration data), resulting in several independent variant functional chains (example: logical capability realisation "update configuration data of topology" splits to "update configuration data of topology on Subsystem X", "update configuration data of topology on Subsystem Y", and so on, because these can be independently done at different times).

7.1. Refine the system capabilities at subsystem architecture level

The following example (non-exhaustive) demostrates under which conditions it may be appropriate to refine the system capabilities for the subsystem architecture.

a) After functional decomposition, the capability's value can be independently delivered to two or more actors. That means that the end conditions of the capability can now be expressed in two or more independent groups. The capability realisation should be refined by capability generalisation - that is, there are now two independent types of the original capability.

b) after functional decomposition, a functional chain portion is defined that can be separated off and reused as a capability in its own right; in this case, the new capability realisation should be included in the capability realisations it is reused within.

c) Where a logical component is reused more than once, but hosted inside separate subsystems, then it may become necessary to split the capability realisation so that it can be carried out independently for each hosting subsystem. This is particularly important for capabilities such as configuration data updates and diagnostics; at logical level these functionalities were defined once for the whole system; now, they will be deployed to separate subsystems so that they can work independently. The capability realisation should be refined by capability generalisation - there are now two independent types (PCR 8.2 and PCR 8.1) of the original capability.