ASRs软件架构需求模板V10.docx

1、ASRs软件架构需求模板V10软件架构需求文档AASRs产品/系统名称修改历史记录日期版本说明修改人2015-10-301.0首次撰写XXX 目 录1. 引言 11.1 目的 11.2 范围 21.3 定义、缩写和缩略语 21.4 引用文件 21.5 概述 32. 商业目标 33. 功能需求 43.1 用例一名称 43.2 例子：查询 43.3 例子：客户身份验证 53.4 例子：提款 63.5 例子：转账 74. 质量需求 84.1 可用性（Availability） 84.2 可靠性（Reliability） 84.3 性能（Performance） 94.4 安全性（Security）

2、104.5 可修改性（Modifiability） 104.6 可移植性（Portability） 104.7 可测试性（Testability） 104.8 可维护性（Maintainability） 114.9 互操作性（Interoperability） 114.10 可复用性（Reusability） 114.11 可伸缩性（Scalability） 114.12 可变化性（Variability） 114.13 可分解性（Subsetability） 114.14 概念完整性（Conceptual integrity） 114.15 可集成性（Integration） 114.16

3、可管理性（Manageability） 124.17 可支持性（Supportability） 124.18 用户体验/易用性（User Experience） 125. 其他需求 125.1 技术环境需求 125.2 系统集成需求 125.3 文化与政治需求 126. 设计约束 137. 附录 13 引言目的Architecturally significant requirements(ASRs) are those requirements that play an important role in determining the architecture of the system.

4、 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 requi

5、rements that are technically challenging, technically constraining, or central to the systems 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 po

6、tential 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 secu

7、rity 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 requir

8、ements 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

9、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

10、, 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 arc

11、hitecturally 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 exa

12、mples 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 dispens

13、e 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

14、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的预期读者。范围通过名称识别要生产/开发的软件产品；说明软件产品将做或不做什么；描述规定的软

15、件的应用，包括相关的收益、目标和目的；如下面例子：该文档是，它主要描述了，与之相关的文档有。部分内容的变更将会影响到相关两个文档更改。定义、缩写和缩略语提供对正确解释ASRs所要求的所有术语、简写和缩略语的定义，可以通过引用ASRs中一个或多个附录、或者引用其他文件的方式来提供引用文件提供ASRs引用的所有文件的完整清单；标识出每个文件的名称、报告编号（适用时）、日期、出版组织；标明可以获得引用文件的来源。可以通过引用附录或引用其他文档的方式提供。概述描述ASRs的其余章条包含的内容；说明ASRs是如何组织的。商业目标XXX功能需求用例一名称（1）用例图（用例图，包括成功场景和失败场景）（2）

16、用例规约：用例编号用例名称用例描述主参与者前置条件后置条件级别基本事件流程：1. 候选事件流程：1. 特殊需求扩展点备注例子：查询（1）用例图（用例图，包括成功场景和失败场景）（2）用例规约：用例编号UC_1用例名称查询用例描述该用例描述银行客户如何使用ATM机来查询信用卡帐号中的余额主参与者客户前置条件户已通过身份验证并选择“查询”操作。后置条件无级别基本事件流程：1. 显示帐号余额、系统从后台服务器中查询该信用卡帐号余额并显示给客户看。候选事件流程：A1. 退出在基本流的任何一个步骤中，客户都可以选择“取消(Cancel)”退出，系统退出信用卡，用例结束。特殊需求无扩展点无备注无例子：客户

17、身份验证（1）用例图（用例图，包括成功场景和失败场景）（2）用例规约：用例编号UC_2用例名称客户身份验证用例描述该用例描述ATM机是如何验证客户身份的主参与者客户前置条件ATM机系统必须已经启动，并且跟后台服务器建立连接后置条件无级别基本事件流程：1. 插入信用卡2. 客户将信用卡插入系统，系统读取信用卡上的客户帐号信息，并向后台服务器系统确认该信用卡的有效性。3. 输入密码4. 系统提示客户输入信用卡密码，客户输入6位密码，系统向后台服务器检查用户密码是否正确。5. 选择服务6. 客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐服务，客户选择他所需要的服务。基本事件流程：1

18、. 插入信用卡客户将信用卡插入系统，系统读取信用卡上的客户帐号信息，并向后台服务器系统确认该信用卡的有效性。2. 输入密码系统提示客户输入信用卡密码，客户输入6位密码，系统向后台服务器检查用户密码是否正确。3. 选择服务客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐服务，客户选择他所需要的服务。候选事件流程：A1. 无效信用卡在基本流步骤1中，客户插入的信用卡在后台服务器中没有对应的帐号，系统显示错误信息并退出信用卡，用例结束。A2. 客户密码不正确在基本流步骤2中，客户输入错误的信用卡密码，系统提示客户重新输入密码，客户重新输入正确信用卡密码后继续基本流中的下一个步骤；如客

19、户输入密码错误超过次，系统没收客户插入的信用卡，用例结束。A3. 退出在基本流的任何一个步骤中，客户都可以选择“取消(Cancel)”退出，系统退出信用卡，用例结束。特殊需求验证信用卡和客户密码操作必须在秒钟内完成扩展点无备注无例子：提款（1）用例图（用例图，包括成功场景和失败场景）（2）用例规约：用例编号UC_3用例名称提款用例描述该用例描述银行客户是如何使用ATM机来进行提款操作的主参与者客户前置条件客户已通过身份验证并选择“取款”操作后置条件无级别基本事件流程：1. 输入提款金额2. 系统提示客户输入提款金额，客户输入提款金额。每个信用卡帐号每日的提款金额不得超过3000元，单次提款金额

20、不得超过1500元。3. 提取现金4. 系统通过后台服务器从客户帐号中扣去取款金额并准备相应数额的现金，客户提取现金。5. 退出系统，取回信用卡6. 系统退出信用卡，用户取回信用卡。候选事件流程：A1. 提款金额超过1500元在基本流步骤1中，客户输入的提款金额超过1500元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续基本流中的下一个步骤。A2. 当日提款总额已超过3000元限额在基本流步骤1中，客户输入的提款金额加上当日已提取金额总数超过3000元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续基本流中的下一个步骤。A3. 信用卡帐号余额不足在基本

21、流步骤2中，系统发现用户提款金额超出该信用卡帐号中的余额，系统显示错误信息并提示客户重新输入金额，回到基本流步骤1。A4. ATM机的现金余额不足提款金额在基本流步骤2中，系统发现用户提款金额超出ATM系统中的现金余额，系统显示错误信息并提示客户重新输入金额，回到基本流步骤1。A5. 退出在基本流的任何一个步骤中，客户都可以选择“取消(Cancel)”退出，系统退出信用卡，用例结束。特殊需求无扩展点无备注例子：转账（1）用例图（用例图，包括成功场景和失败场景）（2）用例规约：用例编号UC_4用例名称转账用例描述该用例描述银行客户是如何使用ATM机来进行转帐操作的主参与者客户前置条件客户已通过身

22、份验证并选择“转帐”操作。后置条件无级别基本事件流程：1. 输入转入帐号系统提示客户输入转帐帐号，客户输入转帐帐号，该帐号必须是同一银行内的其他帐号。2. 输入转帐金额系统提示客户输入转帐金额，客户输入转帐金额。3. 系统进行转帐系统通过后台服务器进行转帐操作，转帐成功后显示确认信息。4. 退出系统，取回信用卡系统退出信用卡，用户取回信用卡。候选事件流程：A1. 无效转入帐号在基本流步骤1中，客户输入的转入帐号无效，系统显示提示信息，回到步骤1。A2. 转帐金额超过限额在基本流步骤2中，客户输入的转帐金额超过限额（该限额由客户申请该服务时确定），系统显示提示信息，回到步骤2。A3. 转帐金额超

23、过信用卡帐号余额在基本流步骤3中，系统发现转帐金额超过信用卡帐号余额，系统显示转帐失败信息，客户确认后继续基本流中的下一个步骤。A4. 退出在基本流的任何一个步骤中，客户都可以选择“取消(Cancel)”退出，系统退出信用卡，用例结束。特殊需求无扩展点无备注质量需求可用性（Availability）记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。系统能够正常运行的时间比例，通常用“平均故障时间”和“故障恢复时间”度量指系统能够正常运行的时间比例。（经常用两次故障之间时间的长度或者出现故障时系统能够恢复正常的速度来表示。）可靠性

24、（Reliability）对系统可靠性的需求应在此处说明。建议如下： 可用性 指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。 平均故障间隔时间 (MTBF) 通常表示为小时数，但也可表示为天数、月数或年数。 平均修复时间 (MTTR) 系统在发生故障后可以暂停运行的时间。 精确度 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 最高错误或缺陷率 通常表示为 bugs/KLOC（每千行代码的错误数目）或 bugs/function-point（每个功能点的错误数目）。 错误或缺陷率 按照小错误、大错误和严重错误来分类：需求中必须对“严重”

25、错误进行界定（例如：数据完全丢失或完全不能使用系统的某部分功能）。系统长时间运行的能力，通常用“平均无故障时间”度量指软件系统在应用或错误面前，在意外或错误面前使用的情况下维持软件系统功能特性的基本能力。（是重要的软件特性之一，通常用它衡量在规定的条件和时间内，软件完成规定功能的能力。通常是MTBF-平均失效间隔时间和MTTF-、平均失效等待时间来衡量。） 对系统可靠性的需求应在此处说明。建议如下： 可用性 指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。 平均故障间隔时间 (MTBF) 通常表示为小时数，但也可表示为天数、月数或年数。 平均修复时间 (MTTR

26、) 系统在发生故障后可以暂停运行的时间。 精确度 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 最高错误或缺陷率 通常表示为 bugs/KLOC（每千行代码的错误数目）或 bugs/function-point（每个功能点的错误数目）。 错误或缺陷率 按照小错误、大错误和严重错误来分类：需求中必须对“严重”错误进行界定（例如：数据完全丢失或完全不能使用系统的某部分功能）。性能（Performance）记录系统性能相关的各种指标，包括： 对事务的响应时间（平均、最长）； 吞吐量（例如每秒处理的事务数）； 容量（例如系统可以容纳的客户或事务数）； 降级模式（当系统以某种形

27、式降级时可接受的运行模式）； 资源利用情况：内存、磁盘、通信等。系统响应能力，通常用“Benchmarks”度量指系统的响应能力，既要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。（经常用单位时间内所能处理的事务的数量或系统完成某个事务处理所需要的时间来定量表示。性能测试经常要使用基准测试程序。）安全性（Security）阻止非法入侵或拒绝服务的能力，通常用系统受到的各种威胁种类加以分类指系统向合法用户提供服务的同时阻止非法用户的使用的企图或拒绝对其服务。（根据系统可能受到的安全威胁可分为机密性、完整性、不可否认性和可控性等特性。）可修改性（Modifiabili

28、ty）快速、低成本修改系统的能力，通常使用特定的改变作为基准，记录进行这些改变所需花费的代价指能够快速地以较高的性能价格比对系统进行变更的能力。（通常以某些具体的变更为基准，通过考察这些变更的代价来衡量。可修改性包含可维护性、可扩展性、结构重组和可移植性等方面。）可移植性（Portability）不同计算环境下运行的能力，一个系统可移植的程度局限于：所有关于任何特定计算环境的假设被限制在一个构件中（最坏的情况下，少数几个易于修改的构件）可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量可测试性（Testability）指软件发生故障并隔离、定位其故障的能力特性，以及在一

29、定的时间和成本前提下，进行测试设计和测试执行能力。（通常，可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明细的软件，而不具有可测试性的软件往往是具有很强的耦合和混乱的逻辑。）可维护性（Maintainability）在给定条件下使用规定的程序和资源进行维护时，在规定使用条件下设备保持在或恢复到能执行要求功能状态的能力。互操作性（Interoperability）指系统与外界或系统与系统之间的相互作用能力。(这就是软件体系结构必须为外部可视的功能特性和数据结构提供精细的软件入口。程序和用其他编程语言编写的软件系统的交互作用就属于互操作性问题。)可复用性（Reusability）从软件

30、开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。比起创建一个你打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性（ DeGrace and Stahl 1993）。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。可伸缩性（Scalability）指随着需求变更，系统能够正常运作的能力，如系统应对大小、数量增长的能力。当负载（同步链接、数据大小，部署范围）增加，能够保证系统的可用性，可靠性、和性能。可变化性（Variability）体系结构更改或扩充的能力，变化性机制包括run-time、compile-time、build-time or code-time等，当体系结构是整个产品家族的基础时，变化性显得尤为重要