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.097 Evaluate subsystem boundary options against the architectural tradeoff criteria

GoalDetermine, in a traceable and reproducible way, the optimal alternative for each of the choices of subystem scope that exist.
Requirements met by this process stepISO 15288 6.4.4.3 e)
Inputs

AMOD-010 Trade space assessment

AMOD-116 System implementation constraints

AMOD-080 Subsystem option sketch

AMOD-075 Subsystem implementation constraints

ARCH.M.140 Method for tradeoff decisions

OutputsAMOD-124 Subsystem architecture tradeoff record
Methodology

The outputs of already performed activities shall be analysed to derive the key impacts on architecture candidates. This includes results from market explorations, organisational factors (e.g. strategies, regulatory and legal constraints), business factors (e.g. business concepts of operations) and any other factor that may impact the system suitability at any stage in its lifecycle. These analysis results are found in AMOD-010, AMOD-116 and AMOD-075 in general terms.

Within this activity the following steps are suggested to be performed concurrently to ARCH.090 Identify alternative subsystem options to ensure that determined factors are applicable to the architecture candidates at hand:

  1. From input materials define the criteria for assessing the architectural options, and the score weighting (if using)
  2. Evaluate each option against each criterion
  3. Make a decision on which option to adopt

The DAR (Decision Analysis and Resolution) method is recommended and the template for AMOD-124 is constructed on this basis. However, there are several trade off techniques in literature. Basic guidance: ARCH.M.140 Method for tradeoff decisions

It is not mandatory to select the option that scores highest in the evaluation, if there is a good reason to favour another option; in this case, the rationale must be very clearly stated and it may result in the need to adjust the weighting of the criteria, or introduce new criteria representing the decisive factor.

The decision may be made individually by the Lead System Architect or in a more collective group with other involved stakeholders; in this second case, voting systems may be needed in order to score each option in a way that represents the collective opinion of the group.

Tools and non-human resourcesDependent on the tradeoff technique used
CardinalityOnce per subsystem architecture decision.
Completion criteriaThe Lead System Architect is satisfied with the outcome of the decision.
Design review

ARCH.R.7 Subsystem capability review

ARCH.R.8 Subsystem review - consolidated

Step done by (Responsible)Lead system architect
Provides input to/assists (Contributes)
  • System architect
  • Subsystem architect
  • Other technical experts as needed
Uses outputs (Informed)None outside ARCH.