ASRs軟件架構(gòu)需求模板V

1、軟件架構(gòu)需求文檔AASRs產(chǎn)品/系統(tǒng)名稱修改歷史記錄日期版本說明修改人2015-10-301.0首次撰寫XXX目 錄1.引言11.1目的11.2范圍21.3定義、縮寫和縮略語21.4引用文件21.5概述32.商業(yè)目標33.功能需求43.1用例一名稱43.2例子：查詢43.3例子：客戶身份驗證53.4例子：提款63.5例子：轉(zhuǎn)賬74.質(zhì)量需求84.1可用性（Availability）84.2可靠性（Reliability）84.3性能（Performance）94.4安全性（Security）104.5可修改性（Modifiability）104.6可移植性（Portability）104.7可

2、測試性（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可管理性（Manageability）124.17可支持性（Supportability）124.18用戶體驗/易用性（User Experience

3、）125.其他需求125.1技術(shù)環(huán)境需求125.2系統(tǒng)集成需求125.3文化與政治需求126.設(shè)計約束137.附錄131. 引言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 signific

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

5、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 explicitly or implicitly architectu

6、rally 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 f

7、unctional 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 drivin

8、g 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.

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

10、her 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 sign

11、ificant. 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:The system must record every modific

12、ation 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 dispense cash on demand to validated account holders with sufficient cleared funds.Architectu

13、rally 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 example, for an on-line book store describing the way th

14、e 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.2 范圍通過名稱識別要生產(chǎn)/開發(fā)的軟件產(chǎn)品；說明軟件產(chǎn)品將做或不做什么；描述規(guī)定的軟件的應(yīng)用，包括相關(guān)的收益、目標和目的；如下面例子：該文檔是，它主要描述了，與之相關(guān)的文檔有。部分內(nèi)容的變更將會影響到相關(guān)兩個文檔更改。1.3 定義、縮寫和縮略語提供

15、對正確解釋ASRs所要求的所有術(shù)語、簡寫和縮略語的定義，可以通過引用ASRs中一個或多個附錄、或者引用其他文件的方式來提供1.4 引用文件提供ASRs引用的所有文件的完整清單；標識出每個文件的名稱、報告編號（適用時）、日期、出版組織；標明可以獲得引用文件的來源?？梢酝ㄟ^引用附錄或引用其他文檔的方式提供。1.5 概述描述ASRs的其余章條包含的內(nèi)容；說明ASRs是如何組織的。2. 商業(yè)目標XXX3. 功能需求3.1 用例一名稱（1）用例圖（用例圖，包括成功場景和失敗場景）（2）用例規(guī)約：用例編號用例名稱用例描述主參與者前置條件后置條件級別基本事件流程：1.候選事件流程：1.特殊需求擴展點備注3.

16、2 例子：查詢（1）用例圖（用例圖，包括成功場景和失敗場景）（2）用例規(guī)約：用例編號UC_1用例名稱查詢用例描述該用例描述銀行客戶如何使用ATM機來查詢信用卡帳號中的余額主參與者客戶前置條件戶已通過身份驗證并選擇“查詢”操作。后置條件無級別基本事件流程：1. 顯示帳號余額、系統(tǒng)從后臺服務(wù)器中查詢該信用卡帳號余額并顯示給客戶看。候選事件流程：A1. 退出在基本流的任何一個步驟中，客戶都可以選擇“取消(Cancel)”退出，系統(tǒng)退出信用卡，用例結(jié)束。特殊需求無擴展點無備注無3.3 例子：客戶身份驗證（1）用例圖（用例圖，包括成功場景和失敗場景）（2）用例規(guī)約：用例編號UC_2用例名稱客戶身份驗證用

17、例描述該用例描述ATM機是如何驗證客戶身份的主參與者客戶前置條件ATM機系統(tǒng)必須已經(jīng)啟動，并且跟后臺服務(wù)器建立連接后置條件無級別基本事件流程：1. 插入信用卡2. 客戶將信用卡插入系統(tǒng)，系統(tǒng)讀取信用卡上的客戶帳號信息，并向后臺服務(wù)器系統(tǒng)確認該信用卡的有效性。3. 輸入密碼4. 系統(tǒng)提示客戶輸入信用卡密碼，客戶輸入6位密碼，系統(tǒng)向后臺服務(wù)器檢查用戶密碼是否正確。5. 選擇服務(wù)6. 客戶通過身份驗證后，系統(tǒng)顯示操作主菜單供客戶選擇查詢、提款、轉(zhuǎn)帳服務(wù)，客戶選擇他所需要的服務(wù)?；臼录鞒蹋?. 插入信用卡客戶將信用卡插入系統(tǒng)，系統(tǒng)讀取信用卡上的客戶帳號信息，并向后臺服務(wù)器系統(tǒng)確認該信用卡的有效性。

18、2. 輸入密碼系統(tǒng)提示客戶輸入信用卡密碼，客戶輸入6位密碼，系統(tǒng)向后臺服務(wù)器檢查用戶密碼是否正確。3. 選擇服務(wù)客戶通過身份驗證后，系統(tǒng)顯示操作主菜單供客戶選擇查詢、提款、轉(zhuǎn)帳服務(wù)，客戶選擇他所需要的服務(wù)。候選事件流程：A1. 無效信用卡在基本流步驟1中，客戶插入的信用卡在后臺服務(wù)器中沒有對應(yīng)的帳號，系統(tǒng)顯示錯誤信息并退出信用卡，用例結(jié)束。A2. 客戶密碼不正確在基本流步驟2中，客戶輸入錯誤的信用卡密碼，系統(tǒng)提示客戶重新輸入密碼，客戶重新輸入正確信用卡密碼后繼續(xù)基本流中的下一個步驟；如客戶輸入密碼錯誤超過次，系統(tǒng)沒收客戶插入的信用卡，用例結(jié)束。A3. 退出在基本流的任何一個步驟中，客戶都可以選

19、擇“取消(Cancel)”退出，系統(tǒng)退出信用卡，用例結(jié)束。特殊需求驗證信用卡和客戶密碼操作必須在秒鐘內(nèi)完成擴展點無備注無3.4 例子：提款（1）用例圖（用例圖，包括成功場景和失敗場景）（2）用例規(guī)約：用例編號UC_3用例名稱提款用例描述該用例描述銀行客戶是如何使用ATM機來進行提款操作的主參與者客戶前置條件客戶已通過身份驗證并選擇“取款”操作后置條件無級別基本事件流程：1. 輸入提款金額2. 系統(tǒng)提示客戶輸入提款金額，客戶輸入提款金額。每個信用卡帳號每日的提款金額不得超過3000元，單次提款金額不得超過1500元。3. 提取現(xiàn)金4. 系統(tǒng)通過后臺服務(wù)器從客戶帳號中扣去取款金額并準備相應(yīng)數(shù)額的現(xiàn)

20、金，客戶提取現(xiàn)金。5. 退出系統(tǒng)，取回信用卡6. 系統(tǒng)退出信用卡，用戶取回信用卡。候選事件流程：A1. 提款金額超過1500元在基本流步驟1中，客戶輸入的提款金額超過1500元，系統(tǒng)顯示提款限額信息并提示客戶重新輸入金額，客戶輸入正確金額后繼續(xù)基本流中的下一個步驟。A2. 當日提款總額已超過3000元限額在基本流步驟1中，客戶輸入的提款金額加上當日已提取金額總數(shù)超過3000元，系統(tǒng)顯示提款限額信息并提示客戶重新輸入金額，客戶輸入正確金額后繼續(xù)基本流中的下一個步驟。A3. 信用卡帳號余額不足在基本流步驟2中，系統(tǒng)發(fā)現(xiàn)用戶提款金額超出該信用卡帳號中的余額，系統(tǒng)顯示錯誤信息并提示客戶重新輸入金額，回

21、到基本流步驟1。A4. ATM機的現(xiàn)金余額不足提款金額在基本流步驟2中，系統(tǒng)發(fā)現(xiàn)用戶提款金額超出ATM系統(tǒng)中的現(xiàn)金余額，系統(tǒng)顯示錯誤信息并提示客戶重新輸入金額，回到基本流步驟1。A5. 退出在基本流的任何一個步驟中，客戶都可以選擇“取消(Cancel)”退出，系統(tǒng)退出信用卡，用例結(jié)束。特殊需求無擴展點無備注3.5 例子：轉(zhuǎn)賬（1）用例圖（用例圖，包括成功場景和失敗場景）（2）用例規(guī)約：用例編號UC_4用例名稱轉(zhuǎn)賬用例描述該用例描述銀行客戶是如何使用ATM機來進行轉(zhuǎn)帳操作的主參與者客戶前置條件客戶已通過身份驗證并選擇“轉(zhuǎn)帳”操作。后置條件無級別基本事件流程：1. 輸入轉(zhuǎn)入帳號系統(tǒng)提示客戶輸入轉(zhuǎn)帳

22、帳號，客戶輸入轉(zhuǎn)帳帳號，該帳號必須是同一銀行內(nèi)的其他帳號。2. 輸入轉(zhuǎn)帳金額系統(tǒng)提示客戶輸入轉(zhuǎn)帳金額，客戶輸入轉(zhuǎn)帳金額。3. 系統(tǒng)進行轉(zhuǎn)帳系統(tǒng)通過后臺服務(wù)器進行轉(zhuǎn)帳操作，轉(zhuǎn)帳成功后顯示確認信息。4. 退出系統(tǒng)，取回信用卡系統(tǒng)退出信用卡，用戶取回信用卡。候選事件流程：A1. 無效轉(zhuǎn)入帳號在基本流步驟1中，客戶輸入的轉(zhuǎn)入帳號無效，系統(tǒng)顯示提示信息，回到步驟1。A2. 轉(zhuǎn)帳金額超過限額在基本流步驟2中，客戶輸入的轉(zhuǎn)帳金額超過限額（該限額由客戶申請該服務(wù)時確定），系統(tǒng)顯示提示信息，回到步驟2。A3. 轉(zhuǎn)帳金額超過信用卡帳號余額在基本流步驟3中，系統(tǒng)發(fā)現(xiàn)轉(zhuǎn)帳金額超過信用卡帳號余額，系統(tǒng)顯示轉(zhuǎn)帳失敗信息，

23、客戶確認后繼續(xù)基本流中的下一個步驟。A4. 退出在基本流的任何一個步驟中，客戶都可以選擇“取消(Cancel)”退出，系統(tǒng)退出信用卡，用例結(jié)束。特殊需求無擴展點無備注4. 質(zhì)量需求4.1 可用性（Availability）記錄所有可用性相關(guān)的需求，如系統(tǒng)的使用者所需要的培訓時間、是否應(yīng)附合一些常見的可用性標準如Windows界面風格等。系統(tǒng)能夠正常運行的時間比例，通常用“平均故障時間”和“故障恢復時間”度量指系統(tǒng)能夠正常運行的時間比例。（經(jīng)常用兩次故障之間時間的長度或者出現(xiàn)故障時系統(tǒng)能夠恢復正常的速度來表示。）4.2 可靠性（Reliability）對系統(tǒng)可靠性的需求應(yīng)在此處說明。建議如下：l

24、 可用性 指出可用時間百分比 ( xx.xx%)、使用小時數(shù)、維護訪問權(quán)、降級模式操作等。l 平均故障間隔時間 (MTBF) 通常表示為小時數(shù)，但也可表示為天數(shù)、月數(shù)或年數(shù)。l 平均修復時間 (MTTR) 系統(tǒng)在發(fā)生故障后可以暫停運行的時間。l 精確度 指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。l 最高錯誤或缺陷率 通常表示為 bugs/KLOC（每千行代碼的錯誤數(shù)目）或 bugs/function-point（每個功能點的錯誤數(shù)目）。l 錯誤或缺陷率 按照小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對“嚴重”錯誤進行界定（例如：數(shù)據(jù)完全丟失或完全不能使用系統(tǒng)的某部分

25、功能）。系統(tǒng)長時間運行的能力，通常用“平均無故障時間”度量指軟件系統(tǒng)在應(yīng)用或錯誤面前，在意外或錯誤面前使用的情況下維持軟件系統(tǒng)功能特性的基本能力。（是重要的軟件特性之一，通常用它衡量在規(guī)定的條件和時間內(nèi)，軟件完成規(guī)定功能的能力。通常是MTBF-平均失效間隔時間和MTTF-、平均失效等待時間來衡量。）對系統(tǒng)可靠性的需求應(yīng)在此處說明。建議如下：l 可用性 指出可用時間百分比 ( xx.xx%)、使用小時數(shù)、維護訪問權(quán)、降級模式操作等。l 平均故障間隔時間 (MTBF) 通常表示為小時數(shù)，但也可表示為天數(shù)、月數(shù)或年數(shù)。l 平均修復時間 (MTTR) 系統(tǒng)在發(fā)生故障后可以暫停運行的時間。l 精確度 指

26、出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。l 最高錯誤或缺陷率 通常表示為 bugs/KLOC（每千行代碼的錯誤數(shù)目）或 bugs/function-point（每個功能點的錯誤數(shù)目）。l 錯誤或缺陷率 按照小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對“嚴重”錯誤進行界定（例如：數(shù)據(jù)完全丟失或完全不能使用系統(tǒng)的某部分功能）。4.3 性能（Performance）記錄系統(tǒng)性能相關(guān)的各種指標，包括： l 對事務(wù)的響應(yīng)時間（平均、最長）； l 吞吐量（例如每秒處理的事務(wù)數(shù)）； l 容量（例如系統(tǒng)可以容納的客戶或事務(wù)數(shù)）； l 降級模式（當系統(tǒng)以某種形式降級時可接受的運行模式

27、）； l 資源利用情況：內(nèi)存、磁盤、通信等。系統(tǒng)響應(yīng)能力，通常用“Benchmarks”度量指系統(tǒng)的響應(yīng)能力，既要經(jīng)過多長時間才能對某個事件做出響應(yīng)，或者在某段時間內(nèi)系統(tǒng)所能處理事件的個數(shù)。（經(jīng)常用單位時間內(nèi)所能處理的事務(wù)的數(shù)量或系統(tǒng)完成某個事務(wù)處理所需要的時間來定量表示。性能測試經(jīng)常要使用基準測試程序。）4.4 安全性（Security）阻止非法入侵或拒絕服務(wù)的能力，通常用系統(tǒng)受到的各種威脅種類加以分類指系統(tǒng)向合法用戶提供服務(wù)的同時阻止非法用戶的使用的企圖或拒絕對其服務(wù)。（根據(jù)系統(tǒng)可能受到的安全威脅可分為機密性、完整性、不可否認性和可控性等特性。）4.5 可修改性（Modifiability

28、）快速、低成本修改系統(tǒng)的能力，通常使用特定的改變作為基準，記錄進行這些改變所需花費的代價指能夠快速地以較高的性能價格比對系統(tǒng)進行變更的能力。（通常以某些具體的變更為基準，通過考察這些變更的代價來衡量。可修改性包含可維護性、可擴展性、結(jié)構(gòu)重組和可移植性等方面。）4.6 可移植性（Portability）不同計算環(huán)境下運行的能力，一個系統(tǒng)可移植的程度局限于：所有關(guān)于任何特定計算環(huán)境的假設(shè)被限制在一個構(gòu)件中（最壞的情況下，少數(shù)幾個易于修改的構(gòu)件）可移植性是度量把一個軟件從一種運行環(huán)境轉(zhuǎn)移到另一種運行環(huán)境中所花費的工作量4.7 可測試性（Testability）指軟件發(fā)生故障并隔離、定位其故障的能力特

29、性，以及在一定的時間和成本前提下，進行測試設(shè)計和測試執(zhí)行能力。（通常，可測試性很好的軟件必然是一個強內(nèi)聚、弱耦合、接口明確、意圖明細的軟件，而不具有可測試性的軟件往往是具有很強的耦合和混亂的邏輯。）4.8 可維護性（Maintainability）在給定條件下使用規(guī)定的程序和資源進行維護時，在規(guī)定使用條件下設(shè)備保持在或恢復到能執(zhí)行要求功能狀態(tài)的能力。4.9 互操作性（Interoperability）指系統(tǒng)與外界或系統(tǒng)與系統(tǒng)之間的相互作用能力。(這就是軟件體系結(jié)構(gòu)必須為外部可視的功能特性和數(shù)據(jù)結(jié)構(gòu)提供精細的軟件入口。程序和用其他編程語言編寫的軟件系統(tǒng)的交互作用就屬于互操作性問題。)4.10 可

30、復用性（Reusability）從軟件開發(fā)的長遠目標上看，可重用性表明了一個軟件組件除了在最初開發(fā)的系統(tǒng)中使用之外，還可以在其它應(yīng)用程序中使用的程度。比起創(chuàng)建一個你打算只在一個應(yīng)用程序中使用的組件，開發(fā)可重用軟件的費用會更大些?？芍赜密浖仨殬藴驶?、資料齊全、不依賴于特定的應(yīng)用程序和運行環(huán)境，并具有一般性（ DeGrace and Stahl 1993）。確定新系統(tǒng)中哪些元素需要用方便于代碼重用的方法設(shè)計，或者規(guī)定作為項目副產(chǎn)品的可重用性組件庫。4.11 可伸縮性（Scalability）指隨著需求變更，系統(tǒng)能夠正常運作的能力，如系統(tǒng)應(yīng)對大小、數(shù)量增長的能力。當負載（同步鏈接、數(shù)據(jù)大小，部署范圍）增加，能夠保證系統(tǒng)的可用性，可靠性、和性能。4.12 可變化性（Variability）體系結(jié)構(gòu)更改或擴充的能力，變化性機制包括run-time、compile-time、build-time or code-time等，當體系結(jié)構(gòu)是整個產(chǎn)品家族的基礎(chǔ)時，變化性顯得尤為重要指體系結(jié)構(gòu)經(jīng)擴充