Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
ARCH.082 Trade off system requirements and constraints
SM-2823
-
Populate Confluence page for activity definition: ARCH.082 Trade off system requirements and constraints
Finished
Goal | Decide on the optimal scope for the system |
---|---|
Requirements met by this process step | ISO 15288 6.4.3.3 c) 1 |
Inputs | AMOD-116 System implementation constraints AMOD-049 Non-functional requirements implementation AMOD-050 Stakeholder non-functional requirements AMOD-103 Consolidated system functions AMOD-120 Record of system capabilities and missions |
Outputs | AMOD-146 System needs and constraints tradeoff decision record |
Methodology | There exists a large number of viable and popular methods for carrying out architectural tradeoffs. To refine the definition of the goal of this activity: the intent is to determine the set of requirements that can be committed to while achieving the greatest possible value to stakeholders. For minor decisions, it will be sufficient for the lead system architect to make the decision, and justify it with a Rationale element in the model. For more complex decisions, a more formal method is needed to provide a robust basis for the decision. The preferred methodology for complex tradeoffs is Decision Analysis and Resolution, as defined by the Capability Maturity Model Integration programme. Briefly summarised, the DAR methodology requires:
A template for AMOD-146 System needs and constraints tradeoff decision record is provided here for applying the DAR methodology: Template for tradeoff records (DAR technique) Other, comparable architectural tradeoff methods such as ATAM, CESAM's tradeoff method, House of Quality/QFD may be used as long as they define the information above in a clear way. NB: it is permissible for a solution to be selected that is not shown by the analysis to be the optimal one, if there is an overbearing influence that was not considered in the evaluation criteria. However, in this case, this should be recorded on the template so that the history of the decision is traceable. |
Tools and non-human resources | Tradeoff templates/tools as selected by the decision-maker Team for Capella |
Cardinality | Once per tradeoff needed between system needs and external constraints |
Completion criteria | The preferred solution has been selected and its selection justified. |
Design review | ARCH.R.4 System review - consolidated |
Step done by (Responsible) | Lead system architect |
Provides input to/assists (Contributes) |
|
Uses outputs (Informed) | Stakeholder |