Assess Architecture Conformity To Priority Needs Or Value

Assessing the compliance of an architecture with priority needs or value is a process that must be initiated very early in the development cycle with the identification of value-bearing needs for the customer and the implementation of the compliance matrix defining the elements expected at the different phases (justification, elementary tests, global tests.).

Among the main pitfalls:

• Poor exchanges between engineering strata and poor consideration of potentially reported
  non-conformities.
• Liar poker policy vs contracts and financial constraints (or to get the contract).
• The upstream team does not use minimum requirements engineering (no upstream tag) in order to give a factual matrix.
• All needs come first.
• Lack of clearly defined requirements.

Here are some good practices to consider:

• Identify priority needs (KDD, key design drivers) with issuing stakeholders.
• Capitalize on the state of the art and have a management of this state of the art (updated by R&T in particular) to know at any time what we are capable of.
• Have a good management of multi-layer engineering margins.
• Have a factual statement of the coverage of the technical proposal which is taken into account with the associated level of performance.
• Element contributing to the T of the QCDT during the phase transition.
• Very early in the development cycle, have a preliminary mapping of the Key Driver. Parameters (main indicators) on the different layers of analysis (need, system, subsystem, etc.) allowing a preliminary assessment of the feasibility and conformity to needs. Establish a traceability link between these KDPs.

We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:

“ With us, the prioritization of value is done by the teams in charge of writing the black box. The response is done by the architecture in the form of a batch with a logical division which represents the integration chain.

“ Contractual constraints stronger than non-compliance alerts from sub-systems and customer notified too late of non-compliance, program canceled late and financial and image losses at the end.

“ Development of a pre-sizing model to link operational KDPs, KDP systems and KDP subsystems. Development of a diverted DSM matrix -> “KDP Structure Matrix” to ensure a traceability link of KDPs and analyze the impacts of non-compliance with certain parameters.

“ All needs come first. With us, it is very difficult to have the analysis of the value as justification. The magic phrase “The market will never accept” is very often used.