The selection of requirements that are considered "architecturally significant" is driven by several key driving factors:

• The benefit of the requirement to stakeholders: critical, important, or useful.
• The architectural impact of the requirement: none, extends, or modifies. There may be critical requirements that have little or no impact on the architecture and low-benefit requirements that have a big impact. Low-benefit requirements with big architectural impacts should be reviewed by the project manager for possible removal from the scope of the project.
• The risks to be mitigated: performance, availability of a product, and suitability of a component.
• The completion of the coverage of the architecture.
• Other tactical objectives or constraints, such as demonstration to the user, and so on.

There may be two requirements that hit the same components and address similar risks. If you implement A first, then B is not architecturally significant. If you implement B first, then A is not architecturally significant. Thus these attributes can depend on the iteration order and should be re-evaluated when the order changes, as well as when the requirements themselves change.

Architecturally significant requirements that are poorly understood or likely to change should be prioritized for clarification and stabilization. In some cases, this means further requirements analysis should be done before implementing the requirement. In other cases, some form of prototyping may be best.