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
Goal | Determine, in a traceable and reproducible way, the optimal alternative for each of the choices of subystem scope that exist. |
---|---|
Requirements met by this process step | ISO 15288 6.4.4.3 e) |
Inputs | AMOD-010 Trade space assessment AMOD-116 System implementation constraints AMOD-080 Subsystem option sketch |
Outputs | AMOD-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:
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 resources | Dependent on the tradeoff technique used |
Cardinality | Once per subsystem architecture decision. |
Completion criteria | The Lead System Architect is satisfied with the outcome of the decision. |
Design review | |
Step done by (Responsible) | Lead system architect |
Provides input to/assists (Contributes) |
|
Uses outputs (Informed) | None outside ARCH. |