Activity: Analyze System Behavior
This activity transforms the behavioral descriptions provided by the requirements into a set of elements upon which the design can be based.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Purpose

The purpose of this activity is to:

  • Refine the preliminary subsystem interactions into System Operation Realizations and /or System Use-Case Realizations in the System Design Model.
  • Aggregate similar subsystem interactions into subsystem use cases and construct the Subsystem Use-Case Model.
  • Refine the System Analysis Model and System Design Model (in terms of subsystems and their relationships) and update the Subsystem Vision and the Subsystem Supplementary Requirements artifacts, based on work done on subsystem interactions, and changes in environment, subsystem non-functional requirements, and the subsystem vision.
  • Refine the Process Model at the system level, based on changes to the system structure (decomposition into subsystems) and the system's environment.
  • Create locality interactions in the form of sequence or collaboration diagrams (in the System Deployment Model) using the Locality Model (Conceptual level of System Deployment Model), and the sorted set of subsystem services.
  • Refine the Locality Model into a Descriptor Level Model and then to an implementation level, through analysis of the localities, their characteristics and hosted subsystem services.
  • Update the appropriate viewpoints in the System Architecture Document with any architecturally significant changes.
Relationships
Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
Staffing

The System Operation Design task is performed by the System Designer role, which in this activity requires a combination of analysis and synthesis skills, in first describing subsystem interactions in detail and then synthesizing these interactions into descriptions of required subsystem behavior in use cases. The results of this work are reviewed by the System Architect and any needed adjustments and refinements are made with the broad system architectural picture and issues in mind. This work is a continuation of that begun in Define Candidate System Architecture, and the same cross-functional team can be used, augmented as necessary with specific skills and knowledge relating to the domains of the emerging subsystems.

Usage
Usage Guidance

The driving task in this activity is System Operation Design, with the System Architect ensuring the design maintains the architectural vision, while still accommodating change and feedback as design discoveries are made. The System Designer delivers updated artifacts to the System Architect to allow for sanctioned Structural, Process and Deployment model changes, and the System Architect refines these as necessary. Pragmatically, the way this might work is that the team does system operation design, reviews the results from an Architectural viewpoint, then iterates back through system operation design, until comfortable with the result (that is, the result meets functional and non-functional requirements and satisfies architectural constraints).