Capability Pattern: Define Subsystem Operations [within Scope]
This activity covers the work around defining operations provided by the (sub)systems.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Purpose

The purpose of this activity is to identify for each subsystem the main set of operations, group them into interfaces and recursively define their realizations in terms of the operations supported by the next level subsystems.

Relationships
Description

This activity describes a top-down approach of logically decomposing the system across multiple aspects driven by the chosen architectural viewpoints and views (see the Use Case Flowdown and Supplementary Requirements Flowdown concepts).

Although in most of the cases the starting point will be the top-level use cases, this is not a pre-requisite. If the use-case techniques are not employed by the modeling team, this operation-based approach could still be used as long as you can define the operations for the top-level system. This is also true when this activity is performed for a subsystem for which only the operations have been defined.

There are two other main characteristics of this approach. One, this is a play around two perspectives on the (sub)systems: black box and white box. You start with the black box perspective and define the externally visible properties of the system(s), mostly in terms of operations. Then you open up the black box, define or identify its elements and describe how each system operation is realized by the elements' operations. The second characteristic of this approach is the fact that is recursive. You are applying the same general method at lower, more detailed levels, for finer-grained subsystems.

A simplified workflow through this activity is presented below:

Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
Staffing

This activity is best carried out by a small team (playing the role of System Architect and System Designer, and usually guided by one or two individuals who have deep experience in architecting systems in the relevant domain) staffed by cross-functional team members. Issues that are typically architecturally important include performance, scaling, distribution, or other specialty engineering requirements. Significant architectural constraints might also flow from physical and environmental requirements. The team should also include members with domain experience who can identify key abstractions. The team should also have experience with model organization and layering.