【正文】 用戶文檔 F 其他需求 G 附件 詞匯表 分析模型 待確定問題清單 軟件需求規(guī)格說明書闡述一個(gè)軟件系統(tǒng)必須提供的功能和性能 ， 以及他們必須考慮的限制條件 。 IBM公司對(duì)需求描述的形式化研究 ， 已經(jīng)提出了一種保證需求文檔更一致的需求描述方法學(xué) ， 使通過使用這種規(guī)定的方法建立的需求 ， 不同人寫的需求之間的差異 ， 已經(jīng)降到最小 。 分解： 對(duì)需求進(jìn)行分解 ， 在分解過程中 ， 找到不合理和不符合邏輯的錯(cuò)誤 。 在追求需求形式化的道路上 ， 軟件人做了長期的努力 ， 但結(jié)果并不盡人意 。 ?通過需求數(shù)據(jù)庫 ， 我們可以方便地對(duì)需求的變化 ， 增加 、修改 、 變化記錄 、 狀態(tài)變化等 ， 做出完善的記錄 。 在項(xiàng)目管理中 ， 有了分層次的需求分解 ， 很快 ， 就可以建立根據(jù) “ 需求項(xiàng) ” 的任務(wù)分解和任務(wù)分配 ， 這就是需求分配 。 ?需求基線的條件是需求形式化 。 建立基于軟件架構(gòu)的需求基線 需求驗(yàn)證階段 編寫測試計(jì)劃與測試用例 編寫用戶使用手冊(cè) 編寫系統(tǒng)驗(yàn)收標(biāo)準(zhǔn) 通過需求評(píng)審 需求驗(yàn)證階段 —— 需求評(píng)審對(duì)象 CMM2就需求評(píng)審的對(duì)象 ——“給定需求 ” 的文檔依據(jù)規(guī)定為： （ 1） 影響和決定軟件項(xiàng)目活動(dòng)的非技術(shù)需求 （ 例如：協(xié)議 、 條件和 /或合同條款 ） 。 需求實(shí)現(xiàn)管理 ? 系統(tǒng)架構(gòu)與需求實(shí)現(xiàn)的關(guān)系 ? 需求狀態(tài)的變化 ? 需求狀態(tài)變化的追蹤 軟件架構(gòu)與實(shí)際業(yè)務(wù)模型聯(lián)系的密切程度 A p p l i c a t i o n L a y e rB u s i n e s s L o g i c a l L a y e rB u s i n e s s E n t i t i e s L a y e rD a t a A c c e s s L a y e rD a t a B a s e L a y e rF o u n d a t i o n L a y e r應(yīng)用層業(yè)務(wù)邏輯層業(yè)務(wù)實(shí)體層數(shù)據(jù)訪問層數(shù)據(jù)庫層基礎(chǔ)支持層非常緊密 較緊密 不太緊密 不緊密 最不緊密 系統(tǒng)架構(gòu)與需求實(shí)現(xiàn)的關(guān)系 把握需求實(shí)現(xiàn)的關(guān)鍵是設(shè)計(jì)良好的軟件構(gòu)架 實(shí)際上，對(duì)于像電信軟件等企業(yè)級(jí)核心應(yīng)用軟件而言，其構(gòu)架在更大的程度上會(huì)決定于其質(zhì)量、性能、操作環(huán)境等非功能特性。 被驗(yàn)證 根據(jù)驗(yàn)收標(biāo)準(zhǔn) ， 已經(jīng)通過集成以上的測試 ， 被驗(yàn)證實(shí)現(xiàn)了需求的要求 ，被放置進(jìn)配置基線庫 。 （ 其他的交付物還有：文檔 、 培訓(xùn) 、 服務(wù)等 ） 。 FAX 接受傳真訪問 自動(dòng)為授權(quán)用戶回復(fù)傳真 E_mail 接受 mail 根據(jù)用戶填寫的信息要求 ，自動(dòng)回復(fù)相應(yīng)的 mail。 功能需求特性 用例 增加用戶 修改用戶 終止用戶 注銷用戶 用戶單位屬性采用選擇系統(tǒng)屬性定義表中屬性 〆 〆 用戶屬性可批量修改 〆 〆 〆 用戶屬性檢查范圍可采用剔除法 〆 〆 用戶屬性統(tǒng)計(jì)可按指定方法 〆 〆 需求追蹤鏈（ 3）：從用例到實(shí)現(xiàn)用例、測試用例 這張表表明 ， 每一個(gè)用例 ， 最終將對(duì)應(yīng)一個(gè)和多個(gè)測試用例 。 ?現(xiàn)在 ， 有一些需求管理工具 ， 可以幫助進(jìn)行需求追蹤 。波及分析還可以幫助項(xiàng)目組對(duì)現(xiàn)有系統(tǒng)做出合理的、有前瞻性的調(diào)整，使面對(duì)日后新的需求變更，有充足的技術(shù)準(zhǔn)備。 在需求變更評(píng)估分析中，也要做需求穩(wěn)定性評(píng)估。 因?yàn)樾枨笞兏?，需求狀態(tài)記錄應(yīng)相應(yīng)地發(fā)生變化。是基線變化，還是個(gè)別版本變化。項(xiàng)目經(jīng)理往往受市場人員的壓力，對(duì)用戶宣稱“免費(fèi)維護(hù)”，但在項(xiàng)目組內(nèi)部，對(duì)于需求變更的成本，甚至可能是“巨大”的。評(píng)估的基本過程是： （ 1）統(tǒng)計(jì)基線需求的數(shù)量：通過需求數(shù)據(jù)庫，可以按最底層的需求項(xiàng)為單位，統(tǒng)計(jì)需求的數(shù)量。 對(duì)需求穩(wěn)定性的關(guān)注，是軟件項(xiàng)目經(jīng)理經(jīng)常需要做的工作。對(duì)需求不穩(wěn)定的因素和來源進(jìn)行分析，做出的評(píng)估，是獲得需求穩(wěn)定的好辦法。 需求變更 —— 變更波及的內(nèi)部分析 系統(tǒng)元素波及分析包括： （ 1） 所有涉及到的輸入界面有關(guān)部分； （ 2） 所有涉及到的報(bào)表等輸出界面有關(guān)部分； （ 3） 所有涉及到的外部接口部分； （ 4） 所有涉及到的內(nèi)部接口部分； （ 5） 所有涉及到的數(shù)據(jù)庫表結(jié)構(gòu)； （ 6） 所有涉及到的系統(tǒng)數(shù)據(jù)定義； （ 7） 所有涉及到的公用模塊定義、公用子程序庫、控件庫； （ 8） 所有涉及到的系統(tǒng)常量、宏定義； （ 9） 所有涉及到的已經(jīng)實(shí)現(xiàn)的代碼； （ 10） 所有涉及到的已經(jīng)完成的單元、集成測試； （ 11） 所有涉及到的已經(jīng)編寫完成的用戶文檔（使用手冊(cè)、維護(hù)手冊(cè)）； （ 12） 所有涉及到的已經(jīng)編寫完成的幫助文件、培訓(xùn)教材； （ 13） 所有涉及到的第三方軟件和工具； （ 14） 所有涉及到的項(xiàng)目管理有關(guān)的需求管理、計(jì)劃管理、成本管理、配 置管理、質(zhì)量管理有關(guān)的數(shù)據(jù)庫、文檔庫； （ 15） 所有涉及到的其他應(yīng)該檢查的部分； （ 16） 所有涉及到的 ……… 。 需求變更波及分析 變更波及分析的意義 對(duì)于項(xiàng)目組來說，一個(gè)新的需求提出來以后，這個(gè)需求如果接受，可能對(duì)系統(tǒng)造成多大的影響？系統(tǒng)結(jié)構(gòu)上的、數(shù)據(jù)結(jié)構(gòu)上的、涉及的模塊、版本上的變更影響有多大？ 需求波動(dòng)在技術(shù)上有潛伏性，在工程上，也表現(xiàn)為不可預(yù)知性。因?yàn)?，?dāng)產(chǎn)品面對(duì)不同地區(qū)、不同用戶群的時(shí)候，也可以確定不同的版本。依據(jù)需求跟蹤矩陣，可以完整地追蹤到需求變更所影響到的所有地方，可以不會(huì)發(fā)生遺漏，而產(chǎn)生系統(tǒng) BUG，或產(chǎn)品缺陷。 項(xiàng)目經(jīng)理應(yīng)根據(jù)新需求，明確相關(guān)任務(wù)，評(píng)估新的工作量和相應(yīng)的要求變化。對(duì)變更的需求設(shè)置優(yōu)先級(jí)、制定版本規(guī)定等。 需求追蹤鏈（ 4）：從用例到測試用例 需求實(shí)現(xiàn) —— 需求追蹤能力 ?如果項(xiàng)目開發(fā)的文檔化 、 形式化做的不夠 ， 需求追蹤鏈存在于工程師的頭腦中 ， 則需求追蹤是沒有保證的 。 需求追蹤鏈（ 2）：從需求特性到用例 采用需求追蹤矩陣的辦法 ， 來跟蹤需求的實(shí)現(xiàn) ， 是需求追蹤鏈的具體化 。 建立需求追蹤鏈的前提條件 ， 是必須統(tǒng)一地標(biāo)識(shí)每一個(gè)需求 ， 也就是前面我們講到的 ， 需求的形式化 。 因?yàn)槿绻皇峭ㄟ^有管理的處理過程 ， 這些需求有可能是應(yīng)該被接受 、并被實(shí)現(xiàn)的需求 ， 而成為系統(tǒng)的疏忽而遺漏 ？ 項(xiàng)目經(jīng)理也應(yīng)該關(guān)注被交付的需求 ， 因?yàn)樽鳛轫?xiàng)目經(jīng)理 ， 他的主要責(zé)任是項(xiàng)目階段的里程碑控制 。 被批準(zhǔn) 在需求 （ 特別是變更需求 ） 被分析 ， 評(píng)估了合理 、 可行 、 成本 、 影響等要素 ， 被確認(rèn)可接受 ， 被標(biāo)注了新的版本號(hào) 、 給出了新的標(biāo)號(hào)等需求屬性 、 被加入到需求基線庫中 ， 進(jìn)入實(shí)現(xiàn)過程 。 （ 4） 相關(guān)小組協(xié)商由給定需求所得出的約定 。 軟件構(gòu)架與系統(tǒng)的軟件需求往往不是一一對(duì)應(yīng)的關(guān)系，通常軟件架構(gòu)的設(shè)計(jì)應(yīng)當(dāng)基于超出當(dāng)前軟件需求定義的邊界之外、更為廣泛的需求超集，這個(gè)需求超集通常而言就是業(yè)務(wù)領(lǐng)域模型。 這樣確保了整個(gè)需求的基線化控制和管理 。 他們將根據(jù)人員 、 時(shí)間等 ， 再被分解為更細(xì)的需求項(xiàng) ， 直至不需求再進(jìn)行分解 。 需求形式化的技術(shù)方法： 需求屬性化是需求數(shù)據(jù)庫化的基礎(chǔ) 需求屬性 含義 說明 名稱 * 需求名稱 用最簡潔的語言表示需求的核心含義 描述與定義 * 對(duì)需求的描述定義 需求的最本質(zhì)內(nèi)容可以用模型 、 圖 、 表表示 編號(hào)層 /序 * 需求的順序號(hào) 可根據(jù)系統(tǒng)結(jié)構(gòu)或任務(wù)的 WBS編排 來源 * 需求的提出來源 用戶需求的更高層依據(jù) 、 來源 提出 /決策人 需求的提出人 當(dāng)需求變化或受到影響時(shí)能最終決定的人 優(yōu)先級(jí) 需求的優(yōu)先級(jí) 表明高 、 中 、 低 ， 以備取舍或決定響應(yīng)次序 實(shí)體 * 需求實(shí)現(xiàn)的實(shí)體 表明需求與實(shí)現(xiàn)實(shí)體的對(duì)應(yīng)關(guān)系 狀態(tài) * 需求所處的狀態(tài) 包括：提出批準(zhǔn) 、 實(shí)施 、 實(shí)現(xiàn) 、 完成或拒絕 、推遲 、 等待 、 丟棄等 。 在這樣的情況下 ， 需求的分解和實(shí)現(xiàn) ， 充滿了二意性 ， 完全根據(jù)實(shí)現(xiàn)者的理解。 關(guān)鍵： 對(duì)關(guān)鍵部分 、 關(guān)鍵字 ， 盡量用大家都理解的 、 無二義的限定詞描述 。 能真正達(dá)到形式化的需求 ， 是需求分解 、 分配 、 追蹤 、 評(píng)估的條件 。 這些文件 ， 成為需求分析的成果 。 ?系統(tǒng)主要的主角確定后，可以根據(jù)為系統(tǒng)主角提供有價(jià)值的結(jié)果（ Result of Value）這一準(zhǔn)則（用例是為主角的活動(dòng)最終提供一個(gè)有價(jià)值的結(jié)果的活動(dòng)過程）來確定系統(tǒng)的用例。 需求分析 ——細(xì)化系統(tǒng)定義 在需求分析階段，我們不可避免地要涉及到進(jìn)行設(shè)計(jì)決策 設(shè)計(jì)決策： ?硬件環(huán)境（運(yùn)行在 PC服務(wù)器上？還是小型機(jī)？） ?平臺(tái)的選擇（只支持 Windows平臺(tái)，是否也支持 UNIX平臺(tái)？） ?工具的限制（采用 VB實(shí)現(xiàn)？） ?方法的約束（用 XYZ類庫實(shí)現(xiàn)數(shù)據(jù)庫訪問？） 當(dāng)前需求使我們考慮采用某種設(shè)計(jì)選項(xiàng) 被選擇的設(shè)計(jì)選項(xiàng)可能影響需求 需求分析是在需求獲取、需求分析和設(shè)計(jì)決策之間反復(fù)迭代循環(huán)的過程 需求分析 ——細(xì)化系統(tǒng)定義 軟件需求是具體的： ?面向系統(tǒng)設(shè)計(jì)、編碼 ?面向測試 因此，在需求獲取的基礎(chǔ)上，進(jìn)一步細(xì)化系統(tǒng)需求、明確和細(xì)化系統(tǒng)定義，這就是需求分析階段的任務(wù) 在傳統(tǒng)軟件過程方法中，這二個(gè)階段不是非常清晰和明確 系統(tǒng)需求 功能性需求 非功能性需求 設(shè)計(jì)約束 需求分析 —— 細(xì)化用例 在需求獲取過程中 ， 我們建立了業(yè)務(wù)模型和系統(tǒng)模型 ， 引入了角色和用例的概念 角色與用例的區(qū)別： ?系統(tǒng)的角色是業(yè)務(wù)之外與業(yè)務(wù)交互的人或事 ?例如： ATM取款機(jī)作為一個(gè)業(yè)務(wù)系統(tǒng) ， 來取款的客戶就是一個(gè)角色 ?用例是業(yè)務(wù)模型中 ， 業(yè)務(wù)的活動(dòng) ?在系統(tǒng)模型中 ， 描述了業(yè)務(wù)中系統(tǒng)的工作 （ 內(nèi)部活動(dòng) ） 。 傳統(tǒng) 軟件工程的局限性 傳統(tǒng)軟件工程的假象前提： （ 1） 軟件工程假定：用戶需求在需求分析開始之前 ， 是一個(gè)基本明確的 、 固定的 、 可獲得的 。 ? 需求變更控制 是指依據(jù) “ 變更申請(qǐng)－審批－更改－重新確認(rèn) ” 的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。 ? 需求分析 的目的是對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。 CMM2的需求管理 需求的開發(fā)包括： （ 1） 需求獲取； （ 2） 需求分析； （ 3） 編寫需求規(guī)格說明書； （ 4） 需求驗(yàn)證 。 因此 ， 需求管理活動(dòng)的內(nèi)容應(yīng)包括就軟件的需求同客戶達(dá)成一種共識(shí)并加以管理 。需求工程包括獲取、分析、規(guī)定、驗(yàn)證和管理軟件需求，而 “ 軟件需求管理 ” 則是對(duì)所有相關(guān)活動(dòng)的規(guī)劃和控制。 ? 國內(nèi)軟件業(yè)的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。滿足項(xiàng)目需求即為成功打下了基礎(chǔ)。 評(píng)測和驗(yàn)證有效的軟件開發(fā)流程的標(biāo)準(zhǔn)得到推廣和普及 。采用需求管理可以給 項(xiàng)目 組帶來很多的好處，直至項(xiàng)目取得成功 。 著名的需求工程設(shè)計(jì)師 Merlin Dorfman 和 Ric