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

1、錯誤!未指定書簽.產(chǎn)品/系統(tǒng)名稱修改歷史記錄日期版本說明修改人2022-10-301.0首次撰寫XXX軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,2022I1 .弓I言11.1 目的 11.2 范圍 21.3 定義、縮寫和縮略語 21.4 引用文件31.5 概述 32 .商業(yè)目標33 .功能需求43.1 用例一名稱 43.2 例子：查詢 53.3 例子：客戶身份驗證 53.4 例子：提款 63.5 例子：轉(zhuǎn)賬 74 .質(zhì)量需求84.1 可用,卜生AVAILABILITY 84.2 可靠性RELIABILITY 84.3 性能PERFORMANCE 104.4 平安性SECURITY

2、114.5 可修改性MODIFIABILITY 114.6 可移植性PORTABILITY 114.7 可測試性TESTABILITY 114.8 可維護性MAINTAINABILITY 124.9 互操作性INTEROPERABILITY 124.10 可復用性REUSABILITY 124.11 可伸縮性SCALABILITY 124.12 可變化性VARIABILITY 124.13 可分解性SUBSETABILITY 124.14 概念完整性Conceptual integrty 124.15 可集成性INTEGRATION 124.16 可治理性MANAGEABILITY 134.1

3、7 可支持性SUPPORTABILITY 134.18 用戶體驗/易用性USEREXPERIENCE 135 .其他需求135.1 技術(shù)環(huán)境需求 135.2 系統(tǒng)集成需求 135.3 文化與政治需求 136 .設(shè)計約束147 .附錄14軟件架構(gòu)需求II中國地質(zhì)大學武漢信息 工程學院軟件工程系,2022軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,2022III1.引言1.1 目的Architecturally significant requirements(ASRs) are those requirements that play an important role in dete

4、rmining 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 consid

5、ered 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 su

6、bset will help others understand the potential 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 o

7、f users that must be supported; or security 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 matt

8、er 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, extends, or modifies. There may be

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

10、 performance, availability of a product, and suitability of a component.The completion of the coverage of the architecture.軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,20221 / 14Other tactical objectives or constraints, such as demonstration to the user, and soon.There may be two requirements that hit the same compon

11、ents 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

12、 well as when the requirements themselves change.The following are good examples 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 Li

13、nux.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 interac

14、tions between key abstractions.and should be identified as architecturally 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

15、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 定義、縮寫和縮略語提供對正確解釋 ASRs所要求的所有術(shù)語、簡寫和縮略語的定義,可以通過引用ASRs中一個或多軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,20222 / 14個附錄、或者引用其他文件的方式來提供1.4 引用文件提供ASRs引用的所有文件的完整清單；標識出每個文件的名稱、

16、報告編號適用時、日期、出版組織;標明可以獲得引用文件的來源.可以通過引用附錄或引用其他文檔的方式提供.1.5 概述描述ASRs的其余章條包含的內(nèi)容;說明ASRs是如何組織的.2.商業(yè)目標XXXThere are three possible relationships between business goals and un archilccture;1. ffoals ofren lead to quality at tribute Kequiteems Or id pur it Hnnther way. eveiquality attribute requirement such lk

17、uer-visible respond time oi plulfbrm flexibiliiy or ironcldd security stem without a database until the manager infbirncd him th a: the database Kam nuudud work The archiieciure was itnponantly ailcctcd without any relcvam quality anributc requircmenr3. influence ut alL Not all bLisincss gujls Eead

18、tu quulity jnribuces. For example.江 busine晶 goal to *reduce cosf may be realized by Lowering the facilitys thermostats in the winter Of reducing employees11 salaries or i)eiision.軟件架構(gòu)需求3 / 14中國地質(zhì)大學武漢信息 工程學院軟件工程系,2022Table 162 A List of Standard Business Goal Categoriesi, Contnbuling to the growth an

19、d continuity of the organization2t Meeting financial objectives3. Meeting personal objectives4. Meeting responsibility to 日mployEes5. Meeting responsibility to society6. Meeting responsltiihty to statez Meeting resporsibility to shareholders8. Managing market position9. Improving business processes1

20、0. Managing the quality and reputation of products11. Managing change In environmental factors3 .功能需求3.1 用例一名稱(1)用例圖(用例圖,包括成功場景和失敗場景)(2)用例規(guī)約:用例編號用例名稱用例描述主參與者前置條件后置條件級別根本領(lǐng)件流程：1.候選事件流程：1.特殊需求擴展點備注軟件架構(gòu)需求中國地質(zhì)大學(武漢)信息 工程學院軟件工程系,20224 / 143.2 例子：查詢(1)用例圖(用例圖,包括成功場景和失敗場景)(2)用例規(guī)約：用例編號UC_1用例名稱查詢用例描述該用例描述銀行客戶

21、如何使用ATM機來查詢信用卡帳號中的余額主參與者客戶前置條件戶已通過身份驗證并選擇“查詢操作.后置條件無級別根本領(lǐng)件流程：1. 顯木帳號余額、系統(tǒng)從后臺效勞器中查詢該信用卡帳號余額并顯示給客戶看.候選事件流程：A1.退出在根本流的任何一個步驟中,客戶都可以選擇“取消(Cancel)退出,系統(tǒng)退出信用卡,用例結(jié)束.特殊需求無擴展點無備注無3.3 例子：客戶身份驗證(1)用例圖(用例圖,包括成功場景和失敗場景)(2)用例規(guī)約：用例編號UC_2用例名稱客戶身份驗證用例描述該用例描述ATM機是如何驗證客戶身份的主參與者客戶前置條件ATM機系統(tǒng)必須已經(jīng)啟動,并且跟后臺效勞器建立連接后置條件無級別根本領(lǐng)件

22、流程：1 .插入信用卡2 .客戶將信用卡插入系統(tǒng),系統(tǒng)讀取信用卡上的客戶帳號信息,并向后臺效勞器系統(tǒng)確認該 信用卡的有效性.3 . 輸入密碼軟件架構(gòu)需求中國地質(zhì)大學(武漢)信息 工程學院軟件工程系,20225 / 144 .系統(tǒng)提示客戶輸入信用卡密碼,客戶輸入6位密碼,系統(tǒng)向后臺效勞器檢查用戶密碼是否正確.5 .選擇效勞6 .客戶通過身份驗證后,系統(tǒng)顯示操作主菜單供客戶選擇查詢、提款、轉(zhuǎn)帳效勞,客戶選擇 他所需要的效勞.根本領(lǐng)件流程：1 .插入信用卡客戶將信用卡插入系統(tǒng),系統(tǒng)讀取信用卡上的客戶帳號信息,并向后臺效勞器系統(tǒng)確認該信用卡的有效性.2 . 輸入密碼系統(tǒng)提示客戶輸入信用卡密碼,客戶輸入

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

24、結(jié)束.特殊需求驗證信用卡和客戶密碼操作必須在5秒鐘內(nèi)完成擴展點無備注無3.4 例子：提款1用例圖用例圖,包括成功場景和失敗場景2用例規(guī)約:用例編號UC_3用例名稱提款用例描述該用例描述銀行客戶是如何使用ATM機來進行提款操作的主參與者客戶前置條件客戶已通過身份驗證并選擇“取款操作后置條件無軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,20226 / 14級別根本領(lǐng)件流程：1 .輸入提款金額2 .系統(tǒng)提示客戶輸入提款金額,客戶輸入提款金額.每個信用卡帳號每日的提款金額不得超 過3000元,單次提款金額不得超過1500元.3 . 提取現(xiàn)金4 .系統(tǒng)通過后臺效勞器從客戶帳號中扣去取款金額并準

25、備相應(yīng)數(shù)額的現(xiàn)金,客戶提取現(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)顯示錯誤信息并提示客戶重新

26、輸入金額,回到根本流步驟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)帳操作.后置條件無級別根本領(lǐng)件流程：軟件架構(gòu)需求中國地質(zhì)大學武漢信息7 / 14工

27、程學院軟件工程系,20221 .輸入轉(zhuǎn)入帳號系統(tǒng)提示客戶輸入轉(zhuǎn)帳帳號,客戶輸入轉(zhuǎn)帳帳號,該帳號必須是同一銀行內(nèi)的其他帳號.2 .輸入轉(zhuǎn)帳金額系統(tǒng)提示客戶輸入轉(zhuǎn)帳金額,客戶輸入轉(zhuǎn)帳金額.3 .系統(tǒng)進行轉(zhuǎn)帳系統(tǒng)通過后臺效勞器進行轉(zhuǎn)帳操作,轉(zhuǎn)帳成功后顯示確認信息.4 .退出系統(tǒng),取回信用卡系統(tǒng)退出信用卡,用戶取回信用卡.候選事件流程：A1.無效轉(zhuǎn)入帳號在根本流步驟1中,客戶輸入的轉(zhuǎn)入帳號無效,系統(tǒng)顯示提示信息,回到步驟1.A2.轉(zhuǎn)帳金額超過限額在根本流步驟2中,客戶輸入的轉(zhuǎn)帳金額超過限額該限額由客戶申請該效勞時確定,系統(tǒng)顯示提示信息,回到步驟2.A3.轉(zhuǎn)帳金額超過信用卡帳號余額在根本流步驟3中,系統(tǒng)

28、發(fā)現(xiàn)轉(zhuǎn)帳金額超過信用卡帳號余額,系統(tǒng)顯示轉(zhuǎn)帳失敗信息,客戶確 認后繼續(xù)根本流中的下一個步驟.A4.退出在根本流的任何一個步驟中,客戶都可以選擇“取消Cancel退出,系統(tǒng)退出信用卡,用例結(jié)束.特殊需求無擴展點無備注4 .質(zhì)量需求4.1 可用性Availably記錄所有可用性相關(guān)的需求,如系統(tǒng)的使用者所需要的培訓時間、是否應(yīng)附合一些常見的可用性 標準如Windows界面風格等.系統(tǒng)能夠正常運行的時間比例,通常用“平均故障時間和“故障恢復時間度量指系統(tǒng)能夠正常運行的時間比例.經(jīng)常用兩次故障之間時間的長度或者出現(xiàn)故障時系統(tǒng)能夠恢復正常的速度來表示.4.2 可靠性Reliability 對系統(tǒng)可靠性的

29、需求應(yīng)在此處說明.建議如下：可用性-指出可用時間百分比xx.xx%、使用小時數(shù)、維護訪問權(quán)、降級模式操作等. 平均故障間隔時間MTBF-通常表示為小時數(shù),但也可表示為天數(shù)、月數(shù)或年數(shù).平均修復時間MTTR-系統(tǒng)在發(fā)生故障后可以暫停運行的時間.精確度-指出系統(tǒng)輸出要求具備的精密度分辨率和精確度根據(jù)某一的標準.軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,20228 / 14最高錯誤或缺陷率 -通常表示為bugs/KLOC 每千行代碼的錯誤數(shù)目或 bugs/function- point 每個功能點的錯誤數(shù)目.錯誤或缺陷率-根據(jù)小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對“嚴重錯誤進行界定

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

31、出系統(tǒng)輸出要求具備的精密度分辨率和精確度根據(jù)某一的標準.最高錯誤或缺陷率 -通常表示為bugs/KLOC 每千行代碼的錯誤數(shù)目或 bugs/function- point 每個功能點的錯誤數(shù)目.錯誤或缺陷率-根據(jù)小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對“嚴重錯誤進行界 定例如：數(shù)據(jù)完全喪失或完全不能使用系統(tǒng)的某局部功能.軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,20229 / 144.3 性能(Performance )Type of ReuiramentDefinitionExamplesRequireThe tms Wiin which rhe astern mu才 per

32、form Is Lndrais.叩口耳 ReuirBmenhTrie Idd drd peak number & uwisend vouma of data eopectedAvailability and 的1,6|即 Rq uirvmentiThe ftdert la whldi 丸 system will be Qgi qH w 田力已 uses and the pennlttiblu hre rale due Ic efrar; Fypm* lire ruir g jss than 7 時cctih Fa 加, 二口門sudi口n 口 ihe 門科川口( he 巧Eor 面1 心,id

33、 be 行二寸欄d n gl lime, Orders wil be tqiisit 化d to the faday Hocr ever/ 30 ninules. p Viil : 一 q nmximUHi cf 200 SiFnultnr -ri -I peak u* times. A lypknl fronsadipn will require ifielrvisniis&iQn d1C hj u total d obuul 2 MB of ddo The syden rm 惱 be available 24 x 7t with le xrepticr O HhedUw Tunreiicx

34、*?. Scheduled mcirtenance shall nd exceed m akxi per-oc ecch moph The system Ml hwe 9畀 uptime perFoini arm.記錄系統(tǒng)性能相關(guān)的各種指標,包括：對事務(wù)的響應(yīng)時間平均、最長；吞吐量例如每秒處理的事務(wù)數(shù)；容量例如系統(tǒng)可以容納的客戶或事務(wù)數(shù)；降級模式當系統(tǒng)以某種形式降級時可接受的運行模式； 資源利用情況：內(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ù)的

35、數(shù)量或系統(tǒng)完成某個事務(wù)處理所需要的時間來 定量表示.性能測試經(jīng)常要使用基準測試程序. 軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,202210 / 144.4 平安性(Security )Type ci RequirementdefinitionExamplescrjcActew ConfrfrlRequirementEnarpkn andAulhecilkationRu tenantsViruj ConholE炯 ated b麻i喊ie cIK data融 即sieir andlrr：irc(ri0n s a+c car 芯*維 內(nèi)卜dc：cDefines what data wi

36、l be encrypted wheiB end whei+iw adhenlicofiofl 曲W be needed ；誓 的 accessF?q. renail5 fc ccriro ihe rprac cf出/The sysiwr E nd mislon alied bul a sy&leni odagt匚(jdirraied to cos $50,000 o0r houi i 心目 rev A oomplere loss of dl system data is estkna4d to oasl 120 million. Oily depciTmsri Tianiqers be ob

37、is -o zhn二三 寸enky ters冒也打heir cn d平十不歸印 Tdqicne apefarars 的 ill be oHe ho recid and create tfems in the cu5tBnebu canr J Carige ar delesteHeni 上* d.MM -j pLVii.?.- Itf LMCl *：iJu%r： wpj把 Io ihctot 8由d 中 df儂 will be1 equ red 1c a fherlka Al uploaded files ill oe checked ter viruses tefae阻止非法入侵或拒絕效勞的水

38、平,通常用系統(tǒng)受到的各種威脅種類加以分類指系統(tǒng)向合法用戶提供效勞的同時阻止非法用戶的使用的企圖或拒絕對其效勞.根據(jù)系統(tǒng)可能受到的平安威脅可分為機密性、完整性、不可否認性和可控性等特性.4.5 可修改性Modifiability 快速、低本錢修改系統(tǒng)的水平,通常使用特定的改變作為基準,記錄進行這些改變所需花費的代 價指能夠快速地以較高的性能價格比對系統(tǒng)進行變更的水平.通常以某些具體的變更為基準,通過考察這些變更的代價來衡量.可修改性包含可維護性、可擴展性、結(jié)構(gòu)重組和可移植性等方面.4.6 可移植性Portability 不同計算環(huán)境下運行的水平,一個系統(tǒng)可移植的程度局限于：所有關(guān)于任何特定計算環(huán)

39、境的假設(shè) 被限制在一個構(gòu)件中最壞的情況下,少數(shù)幾個易于修改的構(gòu)件可移植性是度量把一個軟件從一種運行環(huán)境轉(zhuǎn)移到另一種運行環(huán)境中所花費的工作量4.7 可測試性Testability 指軟件發(fā)生故障并隔離、定位其故障的水平特性,以及在一定的時間和本錢前提下,進行測試設(shè) 計和測試執(zhí)行水平.通常,可測試性很好的軟件必然是一個強內(nèi)聚、弱耦合、接口明確、意圖明細的軟件,而不具 有可測試性的軟件往往是具有很強的耦合和混亂的邏輯.軟件架構(gòu)需求中國地質(zhì)大學武漢信息 工程學院軟件工程系,202211 / 144.8 可維護性(Maintainability )在給定條件下使用規(guī)定的程序和資源進行維護時,在規(guī)定使用條

40、件下設(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 可復用性(Reusability )從軟件開發(fā)的長遠目標上看,可重用性說明了一個軟件組件除了在最初開發(fā)的系統(tǒng)中使用之外, 還可以在其它應(yīng)用程序中使用的程度.比起創(chuàng)立一個你打算只在一個應(yīng)用程序中使用的組件,開發(fā)可 重用軟件的費用會更大些.可重用軟件必須標準化、資料齊全、不依賴于特定的應(yīng)用程序和運行環(huán)

41、境,并具有一般性(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 codetime 等,當體系結(jié)構(gòu)是整個產(chǎn)品家族的根底時,變化性顯得尤為重要指體系

42、結(jié)構(gòu)經(jīng)擴充或變更為新體系結(jié)構(gòu)的水平.(這種新體系結(jié)構(gòu)應(yīng)該符合預先定義的規(guī)那么,在某些具體方面不同于原有的體系結(jié)構(gòu).當要將某 個體系結(jié)構(gòu)作為一系列相關(guān)產(chǎn)品的根底時,可變性尤為重要.)4.13 可分解性(Subsetability )支持系統(tǒng)生成子集的水平,即子集獨立交付的水平,支持增量開發(fā).是一種特殊的變化性.4.14 概念完整性(Conceptual integrity )在各個層次上統(tǒng)一系統(tǒng)設(shè)計水平,例如一致性.4.15 可集成性(Integration )指系統(tǒng)能夠集成更廣泛應(yīng)用的水平軟件架構(gòu)需求中國地質(zhì)大學(武漢)信息 工程學院軟件工程系,202212 / 144.16 可治理性(Man

43、ageability )易于治理的水平,通過監(jiān)控手段,使系統(tǒng)能夠進行有效的測試和調(diào)試4.17 可支持性(Supportability )定義所有與系統(tǒng)的可支持性或可維護性相關(guān)的需求,其中包括編碼標準、命名約定、類庫、如何 來對系統(tǒng)進行維護操作和相應(yīng)的維護實用工具等.4.18 用戶體驗/易用性(User Experience )衡量用戶使用一個軟件完成指定任務(wù)的難易程度.(用戶對軟件的易使用性、質(zhì)量、效率以及效果的感覺,是交互的適應(yīng)性、功能性和有效性的集 中表達.)5 .其他需求所有可能的其他非功能性需求.5.1 技術(shù)環(huán)境需求XXX.5.2 系統(tǒng)集成需求XXX.5.3 文化與政治需求XXX.軟件架構(gòu)需求13 / 14