ASRs软件架构需求模板

软件架构需求文档

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: