ASRs软件架构需求模板.doc

-. z.软件架构需求文档软件架构需求文档AASRsAASRs产品产品/ /系统名称系统名称-. z.目目 录录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 可用性AVAILABILITY84.2 可靠性RELIABILITY84.3 性能PERFORMANCE94.4 平安性SECURITY104.5 可修改性MODIFIABILITY104.6 可移植性PORTABILITY104.7 可测试性TESTABILITY104.8 可维护性MAINTAINABILITY114.9 互操作性INTEROPERABILITY114.10 可复用性REUSABILITY114.11 可伸缩性SCALABILITY114.12 可变化性VARIABILITY114.13 可分解性SUBSETABILITY114.14 概念完整性CONCEPTUAL INTEGRITY114.15 可集成性INTEGRATION114.16 可管理性MANAGEABILITY124.17 可支持性SUPPORTABILITY124.18 用户体验/易用性USER E*PERIENCE125.其他需求 125.1 技术环境需求 125.2 系统集成需求 125.3 文化与政治需求 126.设计约束 137.附录 13-. z.1. 1. 引言引言1.11.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 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 potential implications of change.Requirements can be e*plicitly or implicitly architecturally significant. E*plicitly 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 e*ample, 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, e*tends, 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 e*amples 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 *P and Linu*.-. z.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 e*ample, 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.21.2 围围通过名称识别要生产/开发的软件产品；说明软件产品将做或不做什么；描述规定的软件的应用，包括相关的收益、目标和目的；如下面例子：该文档是，它主要描述了，与之相关的文档有。局部容的变更将会影响到相关两个文档更改。1.31.3 定义、缩写和缩略语定义、缩写和缩略语提供对正确解释 ASRs 所要求的所有术语、简写和缩略语的定义，可以通过引用 ASRs 中一个或多个附录、或者引用其他文件的方式来提供1.41.4 引用文件引用文件提供 ASRs 引用的所有文件的完整清单；标识出每个文件的名称、报告编号适用时、日期、出版组织；标明可以获得引用文件的来源。可以通过引用附录或引用其他文档的方式提供。1.51.5 概述概述描述 ASRs 的其余章条包含的容；说明 ASRs 是如何组织的。2. 2. 商业目标商业目标*-. z.3. 3. 功能功能需求需求3.13.1 用例一名称用例一名称11用例图用例图用例图，包括成功场景和失败场景22用例规约：用例规约：用例编号用例名称用例描述主参与者前置条件后置条件级别根本领件流程：1.候选事件流程：1.特殊需求扩展点备注3.23.2 例子：查询例子：查询1用例图用例图，包括成功场景和失败场景2用例规约：用例编号UC_1用例名称查询用例描述该用例描述银行客户如何使用 ATM 机来查询信用卡中的余额主参与者客户前置条件户已通过身份验证并选择“查询操作。后置条件无级别根本领件流程：1.显示余额、系统从后台效劳器中查询该信用卡余额并显示给客户看。候选事件流程：A1. 退出在根本流的任何一个步骤中，客户都可以选择“取消(Cancel)退出，系统退出信用卡，用例完毕。特殊需求无扩展点无-. z.备注无3.33.3 例子：客户身份验证例子：客户身份验证1用例图用例图，包括成功场景和失败场景2用例规约：用例编号UC_2用例名称客户身份验证用例描述该用例描述 ATM 机是如何验证客户身份的主参与者客户前置条件ATM 机系统必须已经启动，并且跟后台效劳器建立连接后置条件无级别根本领件流程：1.插入信用卡2.客户将信用卡插入系统，系统读取信用卡上的客户信息，并向后台效劳器系统确认该信用卡的有效性。3.输入密码4.系统提示客户输入信用卡密码，客户输入 6 位密码，系统向后台效劳器检查用户密码是否正确。5.选择效劳6.客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐效劳，客户选择他所需要的效劳。根本领件流程：1.插入信用卡客户将信用卡插入系统，系统读取信用卡上的客户信息，并向后台效劳器系统确认该信用卡的有效性。2.输入密码系统提示客户输入信用卡密码，客户输入 6 位密码，系统向后台效劳器检查用户密码是否正确。3.选择效劳客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐效劳，客户选择他所需要的效劳。候选事件流程：A1. 无效信用卡在根本流步骤 1 中，客户插入的信用卡在后台效劳器中没有对应的，系统显示错误信息并退出信用卡，用例完毕。A2. 客户密码不正确在根本流步骤 2 中，客户输入错误的信用卡密码，系统提示客户重新输入密码，客户重新输入正确信用卡密码后继续根本流中的下一个步骤；如客户输入密码错误超过次，系统没收客户插入的信用卡，用例完毕。A3. 退出在根本流的任何一个步骤中，客户都可以选择“取消(Cancel)退出，系统退出信用卡，用例-. z.完毕。特殊需求验证信用卡和客户密码操作必须在秒钟完成扩展点无备注无3.43.4 例子：提款例子：提款1用例图用例图，包括成功场景和失败场景2用例规约：用例编号UC_3用例名称提款用例描述该用例描述银行客户是如何使用 ATM 机来进展提款操作的主参与者客户前置条件客户已通过身份验证并选择“取款操作后置条件无级别根本领件流程：1.输入提款金额2.系统提示客户输入提款金额，客户输入提款金额。每个信用卡每日的提款金额不得超过3000 元，单次提款金额不得超过 1500 元。3.提取现金4.系统通过后台效劳器从客户中扣去取款金额并准备相应数额的现金，客户提取现金。5.退出系统，取回信用卡6.系统退出信用卡，用户取回信用卡。候选事件流程：A1. 提款金额超过 1500 元在根本流步骤 1 中，客户输入的提款金额超过 1500 元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续根本流中的下一个步骤。A2. 当日提款总额已超过 3000 元限额在根本流步骤 1 中，客户输入的提款金额加上当日已提取金额总数超过 3000 元，系统显示提款限额信息并提示客户重新输入金额，客户输入正确金额后继续根本流中的下一个步骤。A3. 信用卡余额缺乏在根本流步骤 2 中，系统发现用户提款金额超出该信用卡中的余额，系统显示错误信息并提示客户重新输入金额，回到根本流步骤 1。A4. ATM 机的现金余额缺乏提款金额在根本流步骤 2 中，系统发现用户提款金额超出 ATM 系统中的现金余额，系统显示错误信息并提示客户重新输入金额，回到根本流步骤 1。A5. 退出在根本流的任何一个步骤中，客户都可以选择“取消(Cancel)退出，系统退出信用卡，用例完毕。-. z.特殊需求无扩展点无备注3.53.5 例子：转账例子：转账1用例图用例图，包括成功场景和失败场景2用例规约：用例编号UC_4用例名称转账用例描述该用例描述银行客户是如何使用 ATM 机来进展转帐操作的主参与者客户前置条件客户已通过身份验证并选择“转帐操作。后置条件无级别根本领件流程：1.输入转入系统提示客户输入转帐，客户输入转帐，该必须是同一银行的其他。2.输入转帐金额系统提示客户输入转帐金额，客户输入转帐金额。3.系统进展转帐系统通过后台效劳器进展转帐操作，转帐成功后显示确认信息。4.退出系统，取回信用卡系统退出信用卡，用户取回信用卡。候选事件流程：A1. 无效转入在根本流步骤 1 中，客户输入的转入无效，系统显示提示信息，回到步骤 1。A2. 转帐金额超过限额在根本流步骤 2 中，客户输入的转帐金额超过限额该限额由客户申请该效劳时确定，系统显示提示信息，回到步骤 2。A3. 转帐金额超过信用卡余额在根本流步骤 3 中，系统发现转帐金额超过信用卡余额，系统显示转帐失败信息，客户确认后继续根本流中的下一个步骤。A4. 退出在根本流的任何一个步骤中，客户都可以选择“取消(Cancel)退出，系统退出信用卡，用例完毕。特殊需求无扩展点无备注-. z.4. 4. 质量需求质量需求4.14.1 可用性可用性AvailabilityAvailability记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如 Windows 界面风格等。系统能够正常运行的时间比例，通常用“平均故障时间和“故障恢复时间度量指系统能够正常运行的时间比例。经常用两次故障之间时间的长度或者出现故障时系统能够恢复正常的速度来表示。4.24.2 可靠性可靠性ReliabilityReliability对系统可靠性的需求应在此处说明。建议如下：可用性 指出可用时间百分比 ( *.*%)、使用小时数、维护访问权、降级模式操作等。平均故障间隔时间 (MTBF) 通常表示为小时数，但也可表示为天数、月数或年数。平均修复时间 (MTTR) 系统在发生故障后可以暂停运行的时间。准确度 指出系统输出要求具备的精细度分辨率和准确度按照*一的标准。最高错误或缺陷率 通常表示为 bugs/KLOC每千行代码的错误数目或 bugs/function-point每个功能点的错误数目。错误或缺陷率 按照小错误、大错误和严重错误来分类：需求中必须对“严重错误进展界定例如：数据完全丧失或完全不能使用系统的*局部功能。系统长时间运行的能力，通常用“平均无故障时间度量指软件系统在应用或错误面前，在意外或错误面前使用的情况下维持软件系统功能特性的根本能力。是重要的软件特性之一，通常用它衡量在规定的条件和时间，软件完成规定功能的能力。通常是 MTBF-平均失效间隔时间和 MTTF-、平均失效等待时间来衡量。对系统可靠性的需求应在此处说明。建议如下：可用性 指出可用时间百分比 ( *.*%)、使用小时数、维护访问权、降级模式操作等。平均故障间隔时间 (MTBF) 通常表示为小时数，但也可表示为天数、月数或年数。平均修复时间 (MTTR) 系统在发生故障后可以暂停运行的时间。准确度 指出系统输出要求具备的精细度分辨率和准确度按照*一的标准。最高错误或缺陷率 通常表示为 bugs/KLOC每千行代码的错误数目或 bugs/function-point每个功能点的错误数目。错误或缺陷率 按照小错误、大错误和严重错误来分类：需求中必须对“严重错误进展界定例如：数据完全丧失或完全不能使用系统的*局部功能。-. z.4.34.3 性能性能PerformancePerformance记录系统性能相关的各种指标，包括： 对事务的响应时间平均、最长； 吞吐量例如每秒处理的事务数； 容量例如系统可以容纳的客户或事务数； 降级模式当系统以*种形式降级时可承受的运行模式； 资源利用情况：存、磁盘、通信等。系统响应能力，通常用“Benchmarks度量指系统的响应能力，既要经过多长时间才能对*个事件做出响应，或者在*段时间系统所能处理事件的个数。经常用单位时间所能处理的事务的数量或系统完成*个事务处理所需要的时间来定量表示。性能测试经常要使用基准测试程序。4.44.4 平安性平安性SecuritySecurity阻止非法入侵或拒绝效劳的能力，通常用系统受到的各种威胁种类加以分类指系统向合法用户提供效劳的同时阻止非法用户的使用的企图或拒绝对其效劳。根据系统可能受到的平安威胁可分为性、完整性、不可否认性和可控性等特性。4.54.5 可修改性可修改性ModifiabilityModifiability快速、低本钱修改系统的能力，通常使用特定的改变作为基准，记录进展这些改变所需花费的代价指能够快速地以较高的性能价格比对系统进展变更的能力。通常以*些具体的变更为基准，通过考察这些变更的代价来衡量。可修改性包含可维护性、可扩展性、构造重组和可移植性等方面。4.64.6 可移植性可移植性PortabilityPortability不同计算环境下运行的能力，一个系统可移植的程度局限于：所有关于任何特定计算环境的假设被限制在一个构件中最坏的情况下，少数几个易于修改的构件可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量4.74.7 可测试性可测试性TestabilityTestability指软件发生故障并隔离、定位其故障的能力特性，以及在一定的时间和本钱前提下，进展测试设计和测试执行能力。通常，可测试性很好的软件必然是一个强聚、弱耦合、接口明确、意图明细的软件，而不具有可测试性的软件往往是具有很强的耦合和混乱的逻辑。-. z.4.84.8 可维护性可维护性MaintainabilityMaintainability在给定条件下使用规定的程序和资源进展维护时，在规定使用条件下设备保持在或恢复到能执行要求功能状态的能力。4.94.9 互操作性互操作性InteroperabilityInteroperability指系统与外界或系统与系统之间的相互作用能力。(这就是软件体系构造必须为外部可视的功能特性和数据构造提供精细的软件入口。程序和用其他编程语言编写的软件系统的交互作用就属于互操作性问题。)4.104.10可复用性可复用性ReusabilityReusability从软件开发的长远目标上看，可重用性说明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。比起创立一个你打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性 DeGrace and Stahl 1993。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为工程副产品的可重用性组件库。4.114.11可伸缩性可伸缩性ScalabilityScalability指随着需求变更，系统能够正常运作的能力，如系统应对大小、数量增长的能力。当负载同步、数据大小，部署围增加，能够保证系统的可用性，可靠性、和性能。4.124.12可变化性可变化性VariabilityVariability体系构造更改或扩大的能力，变化性机制包括 run-time、compile-time、build-time or code-time 等，当体系构造是整个产品家族的根底时，变化性显得尤为重要指体系构造经扩大或变更为新体系构造的能力。这种新体系构造应该符合预先定义的规则，在*些具体方面不同于原有的体系构造。当要将*个体系构造作为一系列相关产品的根底时，可变性尤为重要。4.134.13可分解性可分解性SubsetabilitySubsetability支持系统生成子集的能力，即子集独立交付的能力，支持增量开发。是一种特殊的变化性。4.144.14概念完整性概念完整性ConceptualConceptual integrityintegrity在各个层次上统一系统设计能力，例如一致性。-. z.4.154.15可集成性可集成性IntegrationIntegration指系统能够集成更广泛应用的能力4.164.16可管理性可管理性ManageabilityManageability易于管理的能力，通过监控手段，使系统能够进展有效的测试和调试4.174.17可支持性可支持性SupportabilitySupportability定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进展维护操作和相应的维护实用工具等。4.184.18用户体验用户体验/ /易用性易用性UserUser E*perienceE*perience衡量用户使用一个软件完成指定任务的难易程度。用户对软件的易使用性、质量、效率以及效果的感觉，是交互的适应性、功能性和有效性的集中表达。5. 5. 其他需求其他需求所有可能的其他非功能性需求。5.15.1技术环境需求技术环境需求*。5.25.2 系统集成需求系统集成需求*。5.35.3 文化与政治需求文化与政治需求*。6. 6. 设计约束设计约束A constraint is a design decision with zero degrees of freedom. That is, its a design decision thats already been made. E*amples include the requirement to use a certain programming language or to reuse a certain e*isting module, or a management fiat to make your system service oriented.此节应列出所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购置的构件、类库等。-. z.7. 7. 附录附录输入/输出格式实例，本钱分析研究，或者用户调查的结果；有助于读者理解 ASRs 的支持或背景信息；软件所解决的问题描述对代码和媒体的特殊包装说明，以满足平安、出口、初始装入、或其他需求