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. |
|
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
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).
|
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
| |
|