软件架构需求文档AASRs产品/系统名称修改历史记录目录1.引言 (1)1.1目的 (1)1.2范围 (2)1.3定义、缩写和缩略语 (2)1.4引用文件 (2)1.5概述 (2)2.商业目标 (2)3.功能需求 (3)3.1用例一名称 (3)3.2例子：查询 (4)3.3例子：客户身份验证 (4)3.4例子：提款 (5)3.5例子：转账 (6)4.质量需求 (7)4.1可用性（A VAILABILITY） (7)4.2可靠性（R ELIABILITY） (7)4.3性能（P ERFORMANCE） (9)4.4安全性（S ECURITY） (10)4.5可修改性（M ODIFIABILITY） (10)4.6可移植性（P ORTABILITY） (10)4.7可测试性（T ESTABILITY） (10)4.8可维护性（M AINTAINABILITY） (11)4.9互操作性（I NTEROPERABILITY） (11)4.10可复用性（R EUSABILITY） (11)4.11可伸缩性（S CALABILITY） (11)4.12可变化性（V ARIABILITY） (11)4.13可分解性（S UBSETABILITY） (11)4.14概念完整性（C ONCEPTUAL INTEGRITY） (11)4.15可集成性（I NTEGRATION） (11)4.16可管理性（M ANAGEABILITY） (11)4.17可支持性（S UPPORTABILITY） (12)4.18用户体验/易用性（U SER E XPERIENCE） (12)5.其他需求 (12)5.1技术环境需求 (12)5.2系统集成需求 (12)5.3文化与政治需求 (12)6.设计约束 (13)7.附录 (13)1.引言1.1目的Architecturally significant requirements(ASRs) are those requirements that play an important role in determining the architecture of the system. Such requirements require special attention. Not all requirements have equal significance with regards to the architecture.Architecturally significant requirements are a subset of the requirements that need to be satisfied before the architecture can be considered "stable". Typically, these are requirements that are technically challenging, technically constraining, or central to the system's purpose. Furthermore, the system will generally be more sensitive to changes against architecturally significant requirements, so identifying and communicating this subset will help others understand the potential implications of change.Requirements can be explicitly or implicitly architecturally significant. Explicitly significant requirements are often overtly technical in nature, such as performance targets; the need to interface to other systems; the number of users that must be supported; or security requirements. Implicitly significant requirements may define the essence of the functional behaviour of the system (for example, making a purchase from an on-line store).Deciding whether a specific requirement is architecturally significant is often a matter of judgment. 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 order the requirements are realized, and should be re-evaluated when the order changes, as well as when the requirements themselves change.The following are good examples of Architecturally Significant Requirements:The system must record every modification to customer records for audit purposes.The system must respond within 5 seconds.The system must deploy on Microsoft Windows XP and Linux.The system must encrypt all network traffic.The ATM system must dispense cash on demand to validated account holders with sufficient cleared funds.Architecturally significant requirements also describe key behaviors that the system needs to perform. Such scenarios represent the important interactions between key abstractions.and should be identified as architecturally significant requirements. For example, for an on-line book store describing the way the software handles the scenarios for ordering a book and checking out the shopping cart are often enough to communicate the essence of the architecture.[描述ASRs的目的；说明ASRs的预期读者。
]1.2范围[通过名称识别要生产/开发的软件产品；说明软件产品将做或不做什么；描述规定的软件的应用，包括相关的收益、目标和目的；如下面例子：该文档是…，它主要描述了…，与之相关的文档有…。
部分内容的变更将会影响到相关两个文档更改。
]1.3定义、缩写和缩略语[提供对正确解释ASRs所要求的所有术语、简写和缩略语的定义，可以通过引用ASRs中一个或多个附录、或者引用其他文件的方式来提供]1.4引用文件[提供ASRs引用的所有文件的完整清单；标识出每个文件的名称、报告编号（适用时）、日期、出版组织；标明可以获得引用文件的来源。