ASRs软件架构需求模板.doc
《ASRs软件架构需求模板.doc》由会员分享,可在线阅读,更多相关《ASRs软件架构需求模板.doc(13页珍藏版)》请在课桌文档上搜索。
1、-. 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 可移植性PO
2、RTABILITY104.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*PERI
3、ENCE125.其他需求 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 requi
4、rements 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 const
5、raining, 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*plicit
6、ly 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
7、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 d
8、riven 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 requiremen
9、ts 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 cove
10、rage 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
11、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 syste
12、m 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 suf
13、ficient 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
14、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 围围通过名称识别要生产/开发的软件产品;说明软件产品将做或不做什么;描述规定的软件的应用,包括相关的收益、目标和目的;如下面例子:该文档是,它主要描述了,与之相关的文
15、档有。局部容的变更将会影响到相关两个文档更改。1.31.3 定义、缩写和缩略语定义、缩写和缩略语提供对正确解释 ASRs 所要求的所有术语、简写和缩略语的定义,可以通过引用 ASRs 中一个或多个附录、或者引用其他文件的方式来提供1.41.4 引用文件引用文件提供 ASRs 引用的所有文件的完整清单;标识出每个文件的名称、报告编号适用时、日期、出版组织;标明可以获得引用文件的来源。可以通过引用附录或引用其他文档的方式提供。1.51.5 概述概述描述 ASRs 的其余章条包含的容;说明 ASRs 是如何组织的。2. 2. 商业目标商业目标*-. z.3. 3. 功能功能需求需求3.13.1 用例
16、一名称用例一名称11用例图用例图用例图,包括成功场景和失败场景22用例规约:用例规约:用例编号用例名称用例描述主参与者前置条件后置条件级别根本领件流程:1.候选事件流程:1.特殊需求扩展点备注3.23.2 例子:查询例子:查询1用例图用例图,包括成功场景和失败场景2用例规约:用例编号UC_1用例名称查询用例描述该用例描述银行客户如何使用 ATM 机来查询信用卡中的余额主参与者客户前置条件户已通过身份验证并选择“查询操作。后置条件无级别根本领件流程:1.显示余额、系统从后台效劳器中查询该信用卡余额并显示给客户看。候选事件流程:A1. 退出在根本流的任何一个步骤中,客户都可以选择“取消(Cance
17、l)退出,系统退出信用卡,用例完毕。特殊需求无扩展点无-. z.备注无3.33.3 例子:客户身份验证例子:客户身份验证1用例图用例图,包括成功场景和失败场景2用例规约:用例编号UC_2用例名称客户身份验证用例描述该用例描述 ATM 机是如何验证客户身份的主参与者客户前置条件ATM 机系统必须已经启动,并且跟后台效劳器建立连接后置条件无级别根本领件流程:1.插入信用卡2.客户将信用卡插入系统,系统读取信用卡上的客户信息,并向后台效劳器系统确认该信用卡的有效性。3.输入密码4.系统提示客户输入信用卡密码,客户输入 6 位密码,系统向后台效劳器检查用户密码是否正确。5.选择效劳6.客户通过身份验证
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ASRs 软件 架构 需求 模板
链接地址:https://www.desk33.com/p-21182.html