【正文】 系統(tǒng)架構(gòu)和業(yè)務需求說明書評審執(zhí)行 不執(zhí)行 規(guī)模較小的項目可不進行，將其放到系統(tǒng)需求說明規(guī)格說明書中一起評審。執(zhí)行 對系統(tǒng)需求能否實現(xiàn)不清楚執(zhí)行不執(zhí)行 對系統(tǒng)需求能否實現(xiàn)清楚編寫 規(guī)模較大、較復雜的項目上，執(zhí)行了可行性分析活動，要求出此報告?？尚行苑治鑫臋n 不編寫規(guī)模較小、無需執(zhí)行可行性分析活動；或規(guī)模較大、較復雜的項目，執(zhí)行了可行性分析活動，但不要求單獨出此報告，可合并到系統(tǒng)需求規(guī)格說明書中。開發(fā)系統(tǒng)需求執(zhí)行 新項目或需求需要進一步細化的項目細化需求 執(zhí)行不執(zhí)行 針對舊項目，細化的需求已存在　軟件需求分析　元素概述38 / 162軟件需求分析是按照項目定義的軟件開發(fā)過程，根據(jù)系統(tǒng)分配給軟件的需求（見《系統(tǒng)需求規(guī)格說明書》 ） ，進行軟件質(zhì)量特性規(guī)格說明的過程。該過程包括進一步明確軟件運行環(huán)境，明確對軟件的功能、性能和數(shù)據(jù)要求，以及軟件與硬件、軟件與軟件之間的接口要求等，并對軟件需求進行驗證和文檔化，即完成對軟件需求的分析與規(guī)格定義。有關軟件需求的變更管理，請參見《軟件配置管理程序文件》 。本元素在整個過程中的位置如下圖所示：　入口準則和出口準則（1）入口準則要　素 判斷準則客戶需求（《系統(tǒng)需求規(guī)格說明書》 ） ?已由 SCCB 批準為基線?已進入配置庫（2）出口準則要　素 判斷準則軟件需求規(guī)格說明書?已經(jīng)過審查?已批準為開發(fā)基線?已進入配置庫系統(tǒng)測試計劃系統(tǒng)測試案例?已經(jīng)過審查?已獲得批準?已進入配置庫用戶手冊（概要） ?已編寫軟件需求分析 結(jié)構(gòu)設計系統(tǒng)分配給軟件的需求39 / 162　任務各工作階段如下圖所示：（1）準備階段a.　必要時對軟件需求分析員進行相關培訓（包括有關的技術(shù)和業(yè)務知識培訓，以及有關的工具使用培訓） 。b.　審查客戶需求，識別并解決影響軟件需求的問題。c.　選擇適當?shù)男枨蠓治龇椒ǎ▍⒁姼戒?－附錄 －附錄－附錄 －4） ，并準備相應的分析工具。建議采用的需求分析方法包括：結(jié)構(gòu)化分析法、面向?qū)ο蠓治龇ê涂焖僭头ǖ?。如果需要采用上述分析法以外的其它需求分析法，應該得?SEPG 的批準。?結(jié)構(gòu)化分析法采用結(jié)構(gòu)化的分析技術(shù)。后續(xù)過程（設計、實現(xiàn)）通常也應該采用結(jié)構(gòu)化技術(shù)。適用于中、小規(guī)模的軟件項目。?面向?qū)ο蠓治龇ú捎妹嫦驅(qū)ο蟮姆治黾夹g(shù)。后續(xù)過程（設計、實現(xiàn)）通常也應該采用面向?qū)ο蠹夹g(shù)。適用于各種規(guī)模的軟件項目。?快速原型法借助快速開發(fā)工具，以提供原型的方式，迅速掌握客戶對軟件的需求。適用于客戶描述不清楚對軟件的全部或部分需求。建立滿足客戶需求的原型后，根據(jù)所采用的工具和實際需要確定是否重新進行定義收集?分析評審準備系統(tǒng)分配給軟件的需求軟件需求規(guī)格說明書40 / 162軟件需求規(guī)格定義?？焖僭筒荒茏鳛槲┮坏能浖枨笠?guī)格表達方式，必須輔之以適當?shù)能浖枨笠?guī)格說明書?？焖僭头梢耘c結(jié)構(gòu)化分析或面向?qū)ο蠓治黾夹g(shù)結(jié)合使用。（2）收集、分析階段本階段需要與客戶不斷接觸、協(xié)商。通過對收集到的信息進行分析、歸納，界定出對軟件的需求，明確在目標產(chǎn)品中需要什么和以什么形式來表現(xiàn)。與客戶交流的基本形式通常有兩種：客戶訪談調(diào)查（正式的和非正式的） 、書面調(diào)查（書面報告和調(diào)查表） 。此外，通過對客戶使用的表格和所處的情景進行分析，從而獲取需求，也是常用的方法。這些方法對前面推薦的三種需求分析中采用的分析法與后續(xù)過程的設計和實現(xiàn)方法有一定的關聯(lián)關系，通常應該保持所選用的表達方法一致。詳見需求分析方法指南。除了調(diào)查客戶正常業(yè)務處理要求以外，特別需要關注的是異常處理和例外處理要求。這些處理要求往往在軟件需求中占有很大的比例，卻容易被忽視。收集、分析可重用的軟件或功能模塊，確定可用項。本階段的工作步驟如下：?編制工作計劃，特別是與受訪者協(xié)商確定調(diào)查、訪談日程安排。?運用選定的需求分析方法，收集、識別是、導出軟件需求。?收集、篩選、確定可能重用的軟件或功能模塊。（3）定義階段a.　根據(jù)軟件需求分析結(jié)果，選擇適當?shù)膶崿F(xiàn)方案并說明選擇理由，形成軟件系統(tǒng)的初步設計方案（包括對系統(tǒng)體系結(jié)構(gòu)、數(shù)據(jù)體系結(jié)構(gòu)和接口的初步設計） 。b.　描述軟件需求規(guī)格，編制《軟件需求規(guī)格說明書》 （附錄 －5） 。c.　編制用于驗證和確認軟件需求是否得到滿足的方法－《系統(tǒng)測試計劃》和《系統(tǒng)測試案例》 ，測試計劃的編寫規(guī)范見附錄 －6。d.　建立《用戶手冊》 （概要） 。e.　填寫追溯表。參見 《 客戶需求管理程序文件》 。（4）評審階段a.　評審《軟件需求規(guī)格說明書》 ，具體評審過程見《技術(shù)類評審程序文件》，對軟件需求的評審準則包括：41 / 162?系統(tǒng)需求和系統(tǒng)設計的可追溯性；?與系統(tǒng)需求的外部一致性；?內(nèi)部一致性；?可測試性；?軟件設計的可行性；?運作和維護的可行性。b.　對軟件需求中的問題，與系統(tǒng)工程組或客戶一起確定和審查，并對客戶需求和軟件需求做出適當?shù)母?。c.　對軟件需求規(guī)格說明書進行同行評審。d.　審查、批準軟件需求規(guī)格說明書，必要時，對其進行設計評審。e.　將軟件需求規(guī)格說明書置于配置管理之下。當客戶需求變更，需要對軟件需求做相應的更改時，進行變更控制。參見《軟件配置管理程序文件》 ?！」ぷ鳟a(chǎn)品?《軟件需求規(guī)格說明書 》?《系統(tǒng)測試計劃 》?《系統(tǒng)測試案例 》?《用戶手冊 》 （概要）?《追溯表》 （ MTPTM01B） （MTPTM01C ）　職責?項目經(jīng)理：負責選擇合適的軟件需求分析員，組建軟件需求工作組；確定是否需要對有關人員進行培訓；負責軟件需求規(guī)格說明書的審查和批準。?軟件需求分析員：軟件需求階段工作的主要承擔者。負責完成本過程元素產(chǎn)生的所有工作產(chǎn)品。?系統(tǒng)測試負責人：負責組織軟件系統(tǒng)測試組對軟件需求進行分析，審查軟件需求的可測試性；參與軟件需求規(guī)格說明書的審查和批準。?質(zhì)量保證人員：參與工作產(chǎn)品的審查，統(tǒng)計缺陷，并對軟件需求分析過程進行審計。?系統(tǒng)工程人員：配合處理涉及客戶需求的軟件需求問題。?系統(tǒng)工程負責人：負責組織系統(tǒng)工程組對軟件需求進行分析，審查軟件需42 / 162求的可測試性；負責協(xié)調(diào)處理涉及客戶需求的軟件需求問題；參與軟件需求規(guī)格說明書的審查和批準。?客戶：參與軟件需求規(guī)格說明書的審查和批準?！≠Y源和能力要求?必要的培訓資源?支持軟件需求的設備?支持軟件需求的工具　度量?需求狀態(tài)統(tǒng)計?質(zhì)量（同行評審缺陷統(tǒng)計）?完成本元素的工作所花費的工時43 / 162　詳細裁剪指南活 動 可裁剪屬性 選 擇 裁剪指導方針培訓執(zhí)行如果軟件需求分析人員對需求分析方法及有關的工具使用或?qū)浖枨笏槍︻I域的業(yè)務知識缺乏了解，則必須進行相關培訓。培訓 執(zhí)行不執(zhí)行 軟件需求分析人員已經(jīng)具備相關知識。軟件需求分析結(jié)構(gòu)化分析法采用結(jié)構(gòu)化的分析技術(shù)。后續(xù)過程（設計、實現(xiàn)）通常也應該采用結(jié)構(gòu)化技術(shù)。適用于中、小規(guī)模的軟件項目。詳見附錄 －1 需求分析方法指南。面向?qū)ο蠓治龇ú捎妹嫦驅(qū)ο蟮姆治黾夹g(shù)。后續(xù)過程（設計、實現(xiàn)）通常也應該采用面向?qū)ο蠹夹g(shù)。適用于各種規(guī)模的軟件項目。詳見附錄 －1 需求分析方法指南。軟件需求分析 方法快速原型法借助快速開發(fā)工具，以提供原型的方式，迅速掌握客戶對軟件的需求。適用于客戶描述不清楚對軟件的全部或部分需求。詳見附錄 －1 需求分析方法指南。評審執(zhí)行 重要的或技術(shù)難度較高的軟件項目。設計評審 執(zhí)行不執(zhí)行 其它軟件項目。測試系統(tǒng)測試案例 文檔 單獨編寫 規(guī)模較大的項目。44 / 162不單獨編寫 小型項目，可以與系統(tǒng)測試計劃合并?！〗Y(jié)構(gòu)設計　元素概述結(jié)構(gòu)設計是指按照《軟件需求規(guī)格說明書》 ，設計軟件系統(tǒng)的體系結(jié)構(gòu)，即模塊結(jié)構(gòu)，定義每個模塊的主要功能和模板之間的聯(lián)系（即接口） ，并確定軟件系統(tǒng)的數(shù)據(jù)體系結(jié)構(gòu)。本元素在整個過程中的位置如下圖所示：　入口準則和出口準則（1）入口準則：要　素 判斷準則軟件需求規(guī)格說明書?經(jīng)過審查?審查獲得批準?進入配置庫（2）出口準則：要　素 判斷準則結(jié)構(gòu)設計說明書集成測試計劃?經(jīng)過審查?審查獲得批準?進入配置庫　任務結(jié)構(gòu)設計軟件需求分析 詳細設計編制分析?設計評審?批準準備軟件需求規(guī)格說明書結(jié)構(gòu)設計說明書45 / 162（1）準備階段根據(jù)《軟件需求規(guī)格說明書》 ，對軟件需求的分析結(jié)果進行評估。?對軟件需求階段所產(chǎn)生的初步設計方案進行評估；?檢查重用軟件，核實它們與整個系統(tǒng)需求是否相符；?根據(jù)《軟件需求規(guī)格說明書》 ，對未確定需求進行評估，確定對策。（2）分析、設計階段對《軟件需求規(guī)格說明書》進行分析的基礎上，使用結(jié)構(gòu)化或面向?qū)ο蟮姆椒ㄟM行結(jié)構(gòu)設計。主要包括三個方面的工作－系統(tǒng)體系結(jié)構(gòu)、數(shù)據(jù)體系結(jié)構(gòu)以及接口的設計。a.　系統(tǒng)體系結(jié)構(gòu)設計?擴充軟件需求階段所提出的初步的系統(tǒng)體系結(jié)構(gòu)。對擴展后的體系結(jié)構(gòu)進行完善，降低那些使軟件難于實現(xiàn)、測試、維護和重用的因素，形成高內(nèi)聚、低耦合的系統(tǒng)體系結(jié)構(gòu)。b.　數(shù)據(jù)體系結(jié)構(gòu)設計?擴展軟件需求階段所提出的初步的數(shù)據(jù)體系結(jié)構(gòu)，將其變換成實現(xiàn)軟件所需的數(shù)據(jù)結(jié)構(gòu)。c.　接口設計?擴展軟件需求階段所提出的初步的接口，將其變換成實現(xiàn)軟件所需的接口；?設計軟件模塊間的接口；?設計人和計算機間的接口（即人機界面） 。（3）編制階段a.　根據(jù)分析和設計的結(jié)果，編制《軟件結(jié)構(gòu)設計說明書》 （附錄 －1） 。b.　編制結(jié)構(gòu)設計的驗收準則－《集成測試計劃》和《集成測試案例》 ，確定用于驗證和確認結(jié)構(gòu)設計是否得到滿足的方法；包括集成步驟和方法。測試計劃編寫規(guī)范見附錄 －6。46 / 162驗證和確認的方法包括：演示、集成測試、驗證測試、分析和審查等。c.　定義錯誤處理和恢復策略，確定用戶的輸入、顯示，更新軟件需求階段建立的初步的《用戶手冊》 。d.　填寫追溯表。參見《客戶需求管理程序文件》 。（4）評審、批準階段a.　對《結(jié)構(gòu)設計說明書》和《集成測試計劃》進行同行評審。b.　對結(jié)構(gòu)設計中的問題，與軟件需求分析人員一起確定和審查，并對結(jié)構(gòu)設計進行適當?shù)母?。c.　審查、批準 《結(jié)構(gòu)設計說明書 》 ，必要時，對其進行設計評審。d.　將《結(jié)構(gòu)設計說明書》 、 《集成測試計劃》和《集成測試案例》置于配置管理之下。　工作產(chǎn)品?《結(jié)構(gòu)設計說明書 》?《集成測試計劃 》?《集成測試案例 》?《用戶手冊 》 （初步）?《追溯表》 （ MTPTM01B） （MTPTM01C ）　職責?項目經(jīng)理：*負責選擇合適的設計人員，組建結(jié)構(gòu)設計工作組。*負責《結(jié)構(gòu)設計說明書》和《集成測試計劃》的審查和批準。?結(jié)構(gòu)設計人員：結(jié)構(gòu)設計階段工作的主要承擔者，負責完成本過程元素產(chǎn)生的所有工作產(chǎn)品。?系統(tǒng)分析員：配合處理涉及軟件需求的問題。?系統(tǒng)工程負責人：*負責組織系統(tǒng)工程組對結(jié)構(gòu)設計進行分析，審查結(jié)構(gòu)設計的可測試性；*負責協(xié)調(diào)處理涉及軟件需求的問題；*參與《結(jié)構(gòu)設計說明書》和《集成測試計劃》的審查和批準。?軟件測試負責人：*負責組織軟件測試組對結(jié)構(gòu)設計進行分析，審查結(jié)構(gòu)設計的可測試性；47 / 162*參與《結(jié)構(gòu)設計說明書》和《集成測試計劃》的審查和批準?！≠Y源和能力要求?結(jié)構(gòu)設計所需要的人力?結(jié)構(gòu)設計所需要知識的培訓?結(jié)構(gòu)設計所需要的設備?支持結(jié)構(gòu)設計的開發(fā)工具　度量?質(zhì)量（評審發(fā)現(xiàn)的缺陷數(shù)、缺陷的檢出率）?完成本元素的工作所花費的工時　詳細裁剪指南活 動 可裁剪屬性 選 擇 裁剪指導方針組建設計組多個小組 系統(tǒng)規(guī)模大、技術(shù)難度高培訓 規(guī)模單一小組 系統(tǒng)規(guī)模小、技術(shù)難度一般結(jié)構(gòu)設計不執(zhí)行如果軟件需求階段所獲得初步的系統(tǒng)體系結(jié)構(gòu)已經(jīng)足夠滿足需要已由客戶獲得舊系統(tǒng)改造、系統(tǒng)體系結(jié)構(gòu)不需更改系統(tǒng)體系結(jié)構(gòu)的結(jié)構(gòu)設計執(zhí)行執(zhí)行 其它情況不執(zhí)行 系統(tǒng)響應要求不高重用構(gòu)件的性能模擬執(zhí)行執(zhí)行 其它情況評審執(zhí)行 重要的或技術(shù)難度較高的軟件項目設計評審 執(zhí)行不執(zhí)行 其它軟件項目測試單獨編寫 復雜軟件集成集成測試案例 文檔不單獨編寫 簡單軟件集成，可以與集成測試計劃合并48 / 162　詳細設計　元素概述詳細設計是根據(jù)《結(jié)構(gòu)設計說明書》進行模塊設計，將結(jié)構(gòu)設計所獲得的模塊按照單元、程序、規(guī)程的順序逐步細化。詳細定義各個單元的數(shù)據(jù)結(jié)構(gòu)、程序的實現(xiàn)算法以及程序、單元、模塊之間的接口等，作為以后編碼工作的依據(jù)。本元素在整個過程中的位置如下圖所示：　入口準則和出口準則（1）入口準則：要　素 判斷準則結(jié)構(gòu)設計說明書?經(jīng)過審查?審查獲得批準?進入配置庫（2）出口準則：要　素 判斷準則詳細設計說明書單元測試計劃?經(jīng)過審查?審查獲得批準?進入配置庫　任務詳細設計結(jié)構(gòu)設計 編碼編制分析?設計評審?批準準備結(jié)構(gòu)設計說明書詳細設計說明書49 / 162根據(jù)已批準的《結(jié)構(gòu)設計說明書》 ，詳細定義各個模塊的數(shù)據(jù)結(jié)構(gòu)、算法、接口等，編寫《詳細設計說明書》 （附錄 －1）和《單元測試計劃》 ，測試計劃編寫規(guī)范見