Task: Refine System Structure
This task focuses on keeping the system structure aligned with any significant changes driven by modifications of the system's environment or other refactoring factors.
Discipline:  Analysis & Design - Systems Engineering
Purpose
Based on work done on subsystem interactions, Subsystem Supplementary Requirements, Subsystem Vision, and changes in the environment, to refine the System Analysis and System Design Models (in terms of subsystems and their relationships) and update the Subsystem Vision.
Relationships
Steps
Review changes

The System Architect is prompted to perform this activity by:

The System Architect examines these changes to determine what effect, if any, they have on the logical viewpoint, that is, the way the system is decomposed into collaborating subsystems.

Refactor/augment subsystems

The System Architect determines the subsystem structure initially in Task: System Architectural Analysis, then the detail of how subsystems collaborate is added by the System Designer in Task: System Operation Analysis and then  Task: System Operation Design perhaps doing some refactoring in the process. In the light of this work and any other changes or feedback, the System Architect examines the System Use-Case Realizations (subsystem interactions) to check the validity of the subsystem model, and then adjusts it if necessary.

Capture updated Logical viewpoint in System Architecture Document

Decisions made in this activity are captured in the System Analysis Model (if this is separately maintained) and System Design Model; those aspects which the System Architect considers to be significant are also recorded in the Work Product: System Architecture Document (in this case as part of the Logical viewpoint).

Update subsystem requirements artifacts

If changes are made to the partitioning, then the corresponding requirements artifacts, Subsystem Vision, Subsystem Supplementary Requirements and Subsystem Use-Case Model, might also have to be updated.

Evaluate the results

The effectiveness of proposed solutions at all levels need to be reviewed with the stakeholders and the development team to ensure that all requirements (cost, capability, constraints) are satisfied, and that the rationale (domain conventions, architectural considerations of cohesion and coupling, and so on) for arriving at the particular decomposition is sound. The chosen decomposition must also satisfy any political or economic mandate for subcontracted development of subsystems. Techniques such as simulation and prototyping can be used to provide more objective demonstrations of the adequacy of the design(s).