ASRs软件架构需求模板.docx

ASRs软件架构需求模板.docx

《ASRs软件架构需求模板.docx》由会员分享，可在线阅读，更多相关《ASRs软件架构需求模板.docx（18页珍藏版）》请在冰豆网上搜索。

ASRs软件架构需求模板

软件架构需求文档

AASRs

产品/系统名称

修改历史记录

日期

版本

说明

修改人

2015-10-30

1.0

首次撰写

XXX

引言

目的

Architecturallysignificantrequirements（ASRs）arethoserequirementsthatplayanimportantroleindeterminingthearchitectureofthesystem.Suchrequirementsrequirespecialattention.Notallrequirementshaveequalsignificancewithregardstothearchitecture.

Architecturallysignificantrequirementsareasubsetoftherequirementsthatneedtobesatisfiedbeforethearchitecturecanbeconsidered"stable".Typically,thesearerequirementsthataretechnicallychallenging,technicallyconstraining,orcentraltothesystem'spurpose.Furthermore,thesystemwillgenerallybemoresensitivetochangesagainstarchitecturallysignificantrequirements,soidentifyingandcommunicatingthissubsetwillhelpothersunderstandthepotentialimplicationsofchange.

Requirementscanbeexplicitlyorimplicitlyarchitecturallysignificant.Explicitlysignificantrequirementsareoftenovertlytechnicalinnature,suchasperformancetargets;theneedtointerfacetoothersystems;thenumberofusersthatmustbesupported;orsecurityrequirements.Implicitlysignificantrequirementsmaydefinetheessenceofthefunctionalbehaviourofthesystem（forexample,makingapurchasefromanon-linestore）.

Decidingwhetheraspecificrequirementisarchitecturallysignificantisoftenamatterofjudgment.Theselectionofrequirementsthatareconsidered"architecturallysignificant"isdrivenbyseveralkeydrivingfactors:

Thebenefitoftherequirementtostakeholders:

critical,important,oruseful.

Thearchitecturalimpactoftherequirement:

none,extends,ormodifies.Theremaybecriticalrequirementsthathavelittleornoimpactonthearchitectureandlow-benefitrequirementsthathaveabigimpact.Low-benefitrequirementswithbigarchitecturalimpactsshouldbereviewedbytheprojectmanagerforpossibleremovalfromthescopeoftheproject.

Theriskstobemitigated:

performance,availabilityofaproduct,andsuitabilityofacomponent.

Thecompletionofthecoverageofthearchitecture.

Othertacticalobjectivesorconstraints,suchasdemonstrationtotheuser,andsoon.

Theremaybetworequirementsthathitthesamecomponentsandaddresssimilarrisks.IfyouimplementAfirst,thenBisnotarchitecturallysignificant.IfyouimplementBfirst,thenAisnotarchitecturallysignificant.Thustheseattributescandependontheordertherequirementsarerealized,andshouldbere-evaluatedwhentheorderchanges,aswellaswhentherequirementsthemselveschange.

ThefollowingaregoodexamplesofArchitecturallySignificantRequirements:

Thesystemmustrecordeverymodificationtocustomerrecordsforauditpurposes.

Thesystemmustrespondwithin5seconds.

ThesystemmustdeployonMicrosoftWindowsXPandLinux.

Thesystemmustencryptallnetworktraffic.

TheATMsystemmustdispensecashondemandtovalidatedaccountholderswithsufficientclearedfunds.

Architecturallysignificantrequirementsalsodescribekeybehaviorsthatthesystemneedstoperform.Suchscenariosrepresenttheimportantinteractionsbetweenkeyabstractions.andshouldbeidentifiedasarchitecturallysignificantrequirements.Forexample,foranon-linebookstoredescribingthewaythesoftwarehandlesthescenariosfororderingabookandcheckingouttheshoppingcartareoftenenoughtocommunicatetheessenceofthearchitecture.

[描述ASRs的目的；

说明ASRs的预期读者。

]

范围

[通过名称识别要生产/开发的软件产品；

说明软件产品将做或不做什么；

描述规定的软件的应用，包括相关的收益、目标和目的；

如下面例子：

该文档是…，它主要描述了…，与之相关的文档有…。

部分内容的变更将会影响到相关两个文档更改。

]

定义、缩写和缩略语

[提供对正确解释ASRs所要求的所有术语、简写和缩略语的定义，可以通过引用ASRs中一个或多个附录、或者引用其他文件的方式来提供]

引用文件

[提供ASRs引用的所有文件的完整清单；

标识出每个文件的名称、报告编号（适用时）、日期、出版组织；

标明可以获得引用文件的来源。

可以通过引用附录或引用其他文档的方式提供。

]

概述

[描述ASRs的其余章条包含的内容；

说明ASRs是如何组织的。

]

商业目标

[XXX]

功能需求

用例一名称

（1）用例图

[（用例图，包括成功场景和失败场景）]

（2）用例规约：

用例编号

用例名称

用例描述

主参与者

前置条件

后置条件

级别

基本事件流程：

1.

候选事件流程：

1.

特殊需求

扩展点

备注

例子：

查询

（1）用例图

[（用例图，包括成功场景和失败场景）]

（2）用例规约：

用例编号

UC_1

用例名称

查询

用例描述

该用例描述银行客户如何使用ATM机来查询信用卡帐号中的余额

主参与者

客户

前置条件

户已通过身份验证并选择“查询”操作。

后置条件

无

级别

基本事件流程：

1.显示帐号余额、

系统从后台服务器中查询该信用卡帐号余额并显示给客户看。

候选事件流程：

A1.退出

在基本流的任何一个步骤中，客户都可以选择“取消（Cancel）”退出，系统退出信用卡，用例结束。

特殊需求

无

扩展点

无

备注

无

例子：

客户身份验证

（1）用例图

[（用例图，包括成功场景和失败场景）]

（2）用例规约：

用例编号

UC_2

用例名称

客户身份验证

用例描述

该用例描述ATM机是如何验证客户身份的

主参与者

客户

前置条件

ATM机系统必须已经启动，并且跟后台服务器建立连接

后置条件

无

级别

基本事件流程：

1.插入信用卡

2.客户将信用卡插入系统，系统读取信用卡上的客户帐号信息，并向后台服务器系统确认该信用卡的有效性。

3.输入密码

4.系统提示客户输入信用卡密码，客户输入6位密码，系统向后台服务器检查用户密码是否正确。

5.选择服务

6.客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐服务，客户选择他所需要的服务。

基本事件流程：

1.插入信用卡

客户将信用卡插入系统，系统读取信用卡上的客户帐号信息，并向后台服务器系统确认该信用卡的有效性。

2.输入密码

系统提示客户输入信用卡密码，客户输入6位密码，系统向后台服务器检查用户密码是否正确。

3.选择服务

客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐服务，客户选择他所需要的服务。

候选事件流程：

A1.无效信用卡

在基本流步骤1中，客户插入的信用卡在后台服务器中没有对应的帐号，系统显示错误信息并退出信用卡，用例结束。

A2.客户密码不正确

在基本流步骤2中，客户输入错误的信用卡密码，系统提示客户重新输入密码，客户重新输入正确信用卡密码后继续基本流中的下一个步骤；如客户输入密码错误超过３次，系统没收客户插入的信用卡，用例结束。

A3.退出

在基本流的任何一个步骤中，客户都可以选择“取消（Cancel）”退出，系统退出信用卡，用例结束。

特殊需求

验证信用卡和客户密码操作必须在５秒钟内完成

扩展点

无

备注

无

例子：

提款

（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）”退出，系统退出信用卡，用例结束。

特殊需求

无

扩展点

无

备注

例子：

转账

（1）用例图

[（用例图，包括成功场景和失败场景）]

（2）用例规约：

用例编号

UC_4

用例名称

转账

用例描述

该用例描述银行客户是如何使用ATM机来进行转帐操作的

主参与者

客户

前置条件

客户已通过身份验证并选择“转帐”操作。

后置条件

无

级别

基本事件流程：

1.输入转入帐号

系统提示客户输入转帐帐号，客户输入转帐帐号，该帐号必须是同一银行内的其他帐号。

2.输入转帐金额

系统提示客户输入转帐金额，客户输入转帐金额。

3.系统进行转帐

系统通过后台服务器进行转帐操作，转帐成功后显示确认信息。

4.退出系统，取回信用卡

系统退出信用卡，用户取回信用卡。

候选事件流程：

A1.无效转入帐号

在基本流步骤1中，客户输入的转入帐号无效，系统显示提示信息，回到步骤1。

A2.转帐金额超过限额

在基本流步骤2中，客户输入的转帐金额超过限额（该限额由客户申请该服务时确定），系统显示提示信息，回到步骤2。

A3.转帐金额超过信用卡帐号余额

在基本流步骤3中，系统发现转帐金额超过信用卡帐号余额，系统显示转帐失败信息，客户确认后继续基本流中的下一个步骤。

A4.退出

在基本流的任何一个步骤中，客户都可以选择“取消（Cancel）”退出，系统退出信用卡，用例结束。

特殊需求

无

扩展点

无

备注

质量需求

可用性（Availability）

[记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。

系统能够正常运行的时间比例，通常用“平均故障时间”和“故障恢复时间”度量

指系统能够正常运行的时间比例。

（经常用两次故障之间时间的长度或者出现故障时系统能够恢复正常的速度来表示。

）]

可靠性（Reliability）

[对系统可靠性的需求应在此处说明。

建议如下：

●可用性–指出可用时间百分比（xx.xx%）、使用小时数、维护访问权、降级模式操作等。

●平均故障间隔时间（MTBF）–通常表示为小时数，但也可表示为天数、月数或年数。

●平均修复时间（MTTR）–系统在发生故障后可以暂停运行的时间。

●精确度–指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。

●最高错误或缺陷率–通常表示为bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。

●错误或缺陷率–按照小错误、大错误和严重错误来分类：

需求中必须对“严重”错误进行界定（例如：

数据完全丢失或完全不能使用系统的某部分功能）。

]

系统长时间运行的能力，通常用“平均无故障时间”度量

指软件系统在应用或错误面前，在意外或错误面前使用的情况下维持软件系统功能特性的基本能力。

（是重要的软件特性之一，通常用它衡量在规定的条件和时间内，软件完成规定功能的能力。

通常是MTBF-平均失效间隔时间和MTTF-

、平均失效等待时间来衡量。

）

[对系统可靠性的需求应在此处说明。

建议如下：

●可用性–指出可用时间百分比（xx.xx%）、使用小时数、维护访问权、降级模式操作等。

●平均故障间隔时间（MTBF）–通常表示为小时数，但也可表示为天数、月数或年数。

●平均修复时间（MTTR）–系统在发生故障后可以暂停运行的时间。

●精确度–指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。

●最高错误或缺陷率–通常表示为bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。

●错误或缺陷率–按照小错误、大错误和严重错误来分类：

需求中必须对“严重”错误进行界定（例如：

数据完全丢失或完全不能使用系统的某部分功能）。

]

性能（Performance）

[记录系统性能相关的各种指标，包括：

●对事务的响应时间（平均、最长）；

●吞吐量（例如每秒处理的事务数）；

●容量（例如系统可以容纳的客户或事务数）；

●降级模式（当系统以某种形式降级时可接受的运行模式）；

●资源利用情况：

内存、磁盘、通信等。

系统响应能力，通常用“Benchmarks”度量

指系统的响应能力，既要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。

（经常用单位时间内所能处理的事务的数量或系统完成某个事务处理所需要的时间来定量表示。

性能测试经常要使用基准测试程序。

）]

安全性（Security）

[阻止非法入侵或拒绝服务的能力，通常用系统受到的各种威胁种类加以分类

指系统向合法用户提供服务的同时阻止非法用户的使用的企图或拒绝对其服务。

（根据系统可能受到的安全威胁可分为机密性、完整性、不可否认性和可控性等特性。

）]

可修改性（Modifiability）

[快速、低成本修改系统的能力，通常使用特定的改变作为基准，记录进行这些改变所需花费的代价

指能够快速地以较高的性能价格比对系统进行变更的能力。

（通常以某些具体的变更为基准，通过考察这些变更的代价来衡量。

可修改性包含可维护性、可扩展性、结构重组和可移植性等方面。

）]

可移植性（Portability）

[不同计算环境下运行的能力，一个系统可移植的程度局限于：

所有关于任何特定计算环境的假设被限制在一个构件中（最坏的情况下，少数几个易于修改的构件）

可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量]

可测试性（Testability）

[指软件发生故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计和测试执行能力。

（通常，可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明细的软件，而不具有可测试性的软件往往是具有很强的耦合和混乱的逻辑。

）]

可维护性（Maintainability）

[在给定条件下使用规定的程序和资源进行维护时，在规定使用条件下设备保持在或恢复到能执行要求功能状态的能力。

]

互操作性（Interoperability）

[指系统与外界或系统与系统之间的相互作用能力。

（这就是软件体系结构必须为外部可视的功能特性和数据结构提供精细的软件入口。

程序和用其他编程语言编写的软件系统

的交互作用就属于互操作性问题。

）]

可复用性（Reusability）

[从软件开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。

比起创建一个你打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。

可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性（DeGraceandStahl1993）。

确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。

]

可伸缩性（Scalability）

[指随着需求变更，系统能够正常运作的能力，如系统应对大小、数量增长的能力。

当负载（同步链接、数据大小，部署范围）增加，能够保证系统的可用性，可靠性、和性能。

]

可变化性（Variability）

[体系结构更改或扩充的能力，变化性机制包括run-time、compile-time、build-timeorcode-time等，当体系结构是整个产品家族的基础时，变化性显得尤为重要

指体系结构经扩充或变更为新体系结构的能力。

（这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。

当要将某个体系结构作为一系列相关产品的基础

时，可变性尤为重要。

）]

可分解性（Subsetability）

[支持系统生成子集的能力，即子集独立交付的能力，支持增量开发。

是一种特殊的变化性。

]

概念完整性（Conceptualintegrity）

[在各个层次上统一系统设计能力，例如一致性。

]

可集成性（Integration）

[指系统能够集成更广泛应用的能力]

可管理性（Manageability）

[易于管理的能力，通过监控手段，使系统能够进行有效的测试和调试]

可支持性（Supportability）

[定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。

]

用户体验/易用性（UserExperience）

[衡量用户使用一个软件完成指定任务的难易程度。

（用户对软件的易使用性、质量、效率以及效果的感觉，是交互的适应性、功能性和有效性的集中体现。

）]

其他需求

[所有可能的其他非功能性需求。

]

技术环境需求

[XXX。

]

系统集成需求

[XXX。

]

文化与政治需求

[XXX。

]

设计约束

Aconstraintisadesigndecisionwithzerodegreesoffreedom.Thatis,it'sadesigndecisionthat'salreadybeenmade.

Examplesincludetherequirementtouseac