【正文】 需求形式化與需求分配 在上面的這張表中定義的一個(gè)需求 ， 對應(yīng)需求數(shù)據(jù)庫的一個(gè) “ 數(shù)據(jù)項(xiàng) ” ， 我們稱之為一個(gè) “ 需求項(xiàng) ” 。 ?通過需求數(shù)據(jù)庫 ， 我們可以方便地對需求的變化 ， 增加 、修改 、 變化記錄 、 狀態(tài)變化等 ， 做出完善的記錄 。 需求形式化的技術(shù)方法： 需求屬性化是需求數(shù)據(jù)庫化的基礎(chǔ) 需求屬性 含義 說明 名稱 * 需求名稱 用最簡潔的語言表示需求的核心含義 描述與定義 * 對需求的描述定義 需求的最本質(zhì)內(nèi)容可以用模型 、 圖 、 表表示 編號層 /序 * 需求的順序號 可根據(jù)系統(tǒng)結(jié)構(gòu)或任務(wù)的 WBS編排 來源 * 需求的提出來源 用戶需求的更高層依據(jù) 、 來源 提出 /決策人 需求的提出人 當(dāng)需求變化或受到影響時(shí)能最終決定的人 優(yōu)先級 需求的優(yōu)先級 表明高 、 中 、 低 ， 以備取舍或決定響應(yīng)次序 實(shí)體 * 需求實(shí)現(xiàn)的實(shí)體 表明需求與實(shí)現(xiàn)實(shí)體的對應(yīng)關(guān)系 狀態(tài) * 需求所處的狀態(tài) 包括：提出批準(zhǔn) 、 實(shí)施 、 實(shí)現(xiàn) 、 完成或拒絕 、推遲 、 等待 、 丟棄等 。 有支持需求數(shù)據(jù)庫化處理的工具 ， 如： Rational的RequisitePro或 MS的 VSS， 來協(xié)助進(jìn)行需求的數(shù)據(jù)庫管理 。 如果把需求的層 、 項(xiàng)看成是一個(gè)搜索網(wǎng)絡(luò)的話 ， 借助這個(gè)網(wǎng)絡(luò) ， 可以全面地捕捉容易疏忽的需求 ， 特別是系統(tǒng)的邊界情況 。 在追求需求形式化的道路上 ， 軟件人做了長期的努力 ， 但結(jié)果并不盡人意 。 在這樣的情況下 ， 需求的分解和實(shí)現(xiàn) ， 充滿了二意性 ， 完全根據(jù)實(shí)現(xiàn)者的理解。 需求記錄不僅僅是一篇文字 。 需求的形式化處理 ， 可以幫助你實(shí)現(xiàn)以上目標(biāo) 。 分解： 對需求進(jìn)行分解 ， 在分解過程中 ， 找到不合理和不符合邏輯的錯(cuò)誤 。 關(guān)鍵： 對關(guān)鍵部分 、 關(guān)鍵字 ， 盡量用大家都理解的 、 無二義的限定詞描述 。 因?yàn)?， 代價(jià)太高了 。 需求形式化 ——消除歧義的努力 消除需求描述的歧義性 ， 是軟件工程的 “ 軟肋 ” ， 沒有什么更好的方法 。 IBM公司對需求描述的形式化研究 ， 已經(jīng)提出了一種保證需求文檔更一致的需求描述方法學(xué) ， 使通過使用這種規(guī)定的方法建立的需求 ， 不同人寫的需求之間的差異 ， 已經(jīng)降到最小 。 能真正達(dá)到形式化的需求 ， 是需求分解 、 分配 、 追蹤 、 評估的條件 。 任何口頭的傳誤 ， 在文字記錄上 ， 會被減少 。 需求文檔：需求的形式化問題 需求文檔化： 需求一旦確定 ， 就需要把它用文檔的形式 ， 固定下來 。 需求處理 —— 傳統(tǒng)的 《 需求規(guī)格說明書 》 1 2 3 4 5 6 A 引言 目的 文檔約定 預(yù)期的讀者和閱讀建議 產(chǎn)品的范圍 參考文獻(xiàn) B 綜合描述 產(chǎn)品前景 產(chǎn)品的功能 用戶類和特征 運(yùn)行環(huán)境 設(shè)計(jì)和實(shí)現(xiàn)上的限制 假設(shè)和依賴附錄 C 外部接口需求附錄 用戶界面附錄 硬件接口 軟件接口 通信接口 D 系統(tǒng)特性 說明和優(yōu)先級 激勵 /響應(yīng)序列 功能需求 E 其他非功能需求 性能需求 完全設(shè)施需求 安全性需求 軟件質(zhì)量屬性 業(yè)務(wù)規(guī)范 用戶文檔 F 其他需求 G 附件 詞匯表 分析模型 待確定問題清單 軟件需求規(guī)格說明書闡述一個(gè)軟件系統(tǒng)必須提供的功能和性能 ， 以及他們必須考慮的限制條件 。 這些文件 ， 成為需求分析的成果 。 為了后續(xù)開發(fā)階段 （ 概要設(shè)計(jì)和詳細(xì)設(shè)計(jì) ） 的需要 ， 在傳統(tǒng)模式下， 有了用戶實(shí)例 ， 還必須編寫從用戶實(shí)例派生出來的功能需求規(guī)格說明書和非功能需求文檔 。 需求處理階段 需求規(guī)格說明書 項(xiàng)目 《 用戶需求說明書 》 或 《 前景文件 》 提供了業(yè)務(wù)需求的宏觀描述文檔 ， 使得公司內(nèi)部相關(guān)部門對項(xiàng)目 ， 有一個(gè)全局的了解 。 ?有二種 Interaction圖 ， 按時(shí)間順序排列的是 Sequence圖 ， 按對象關(guān)系排列的是 Collaboration圖 。 ?系統(tǒng)主要的主角確定后，可以根據(jù)為系統(tǒng)主角提供有價(jià)值的結(jié)果（ Result of Value）這一準(zhǔn)則（用例是為主角的活動最終提供一個(gè)有價(jià)值的結(jié)果的活動過程）來確定系統(tǒng)的用例。 ?確定系統(tǒng)的用例，通常從尋找系統(tǒng)的主角開始。 用例模型描述事件流 ， 包括主事件流 、 其他事件流 、前提條件 、 事后條件等等 。 取款的客戶是角色 ， 取款是用例 。 需求分析 ——細(xì)化系統(tǒng)定義 在需求分析階段，我們不可避免地要涉及到進(jìn)行設(shè)計(jì)決策 設(shè)計(jì)決策： ?硬件環(huán)境（運(yùn)行在 PC服務(wù)器上？還是小型機(jī)？） ?平臺的選擇（只支持 Windows平臺，是否也支持 UNIX平臺？） ?工具的限制（采用 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ù)的活動 ?在系統(tǒng)模型中 ， 描述了業(yè)務(wù)中系統(tǒng)的工作 （ 內(nèi)部活動 ） 。 ?用例 ——業(yè)務(wù)模型和系統(tǒng)模型的最典型表示形式 ?軟件產(chǎn)品本身可能還存在與業(yè)務(wù)無直接關(guān)系的另類需求（一般與硬件、軟件環(huán)境相關(guān)），比如支持多種操作系統(tǒng)、對軟件運(yùn)行的遠(yuǎn)端監(jiān)控要求、異常處理（如通訊連接中斷等非業(yè)務(wù)異常）等等。 （ 4） 軟件工程更關(guān)注這種： “ 描述 ” 的方法和過程 （ 需求分析方法 ） 。 （ 3） 軟件工程把這個(gè) “ 描述 ” 工作 ， 做了定義 ， 就是需求分析的四個(gè)任務(wù) 。 傳統(tǒng) 軟件工程的局限性 傳統(tǒng)軟件工程的假象前提： （ 1） 軟件工程假定：用戶需求在需求分析開始之前 ， 是一個(gè)基本明確的 、 固定的 、 可獲得的 。 在這個(gè)假設(shè)下，軟件工程的需求分析，是一個(gè)“純”技術(shù)性的“轉(zhuǎn)換”。 現(xiàn)代軟件工程的需求工程 需求開發(fā)過程 需求管理過程 需求獲取 需求分析 需求處理 需求確認(rèn) 需求實(shí)現(xiàn) 需求跟蹤 需求變更控制 從思想方法上看： 我們從傳統(tǒng)軟件工程的定義和計(jì)劃階段的工作內(nèi)容 ， 可以看出 ， 軟件工程認(rèn)定： ?“ 問題 ” 已經(jīng)是一個(gè)明確的 、 固定的 、 可獲得的； ?如果通過可行性分析 ， 認(rèn)為項(xiàng)目可行 ， 則此 “ 問題 ”也是可 “ 求解 ” 的 。 （ 1） 確定對系統(tǒng)的綜合要求 （ 2） 分析系統(tǒng)的數(shù)據(jù)要求： （ 3） 抽象出并確立目標(biāo)系統(tǒng)的邏輯模型； （ 4） 編寫需求規(guī)格說明書。 ? 需求變更控制 是指依據(jù) “ 變更申請－審批－更改－重新確認(rèn) ” 的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。 ? 需求實(shí)現(xiàn) 是指在系統(tǒng)概要分析、詳細(xì)分析和系統(tǒng)編碼、測試等開發(fā)過程中，實(shí)現(xiàn)系統(tǒng)的需求。 ? 需求確認(rèn) 是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。 ? 需求處理 的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生 《 產(chǎn)品需求規(guī)格說明書 》 。 ? 需求分析 的目的是對各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。 需求工程的 兩大過程域 現(xiàn)代軟件工程的需求工程 需求開發(fā)過程 需求管理過程 需求獲取 需求分析 需求處理 需求確認(rèn) 需求實(shí)現(xiàn) 需求跟蹤 需求變更控制 現(xiàn)代軟件工程的需求工程 需求開發(fā)過程域 ? 需求開發(fā) 的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。 ?需求工程是提供一種適當(dāng)?shù)臋C(jī)制 ， 以了解用戶想要什么 、分析需求 、 評估可行性 、 協(xié)商合理的解決方案 、 無歧義地規(guī)約解決方案 、 確認(rèn)規(guī)約以及在開發(fā)過程中管理這些被確認(rèn)的需求規(guī)約的過程 。 從 CMM2對需求管理的要求 、 目標(biāo)和管理過程中可以看出 ， CMM2的側(cè)重點(diǎn)在于需求獲取以后 ， 如何建立需求基準(zhǔn)線 ， 并依據(jù)需求基準(zhǔn)線 ，對項(xiàng)目的需求進(jìn)行的控制和管理 。 CMM2的需求管理 需求的開發(fā)包括： （ 1） 需求獲?。? （ 2） 需求分析； （ 3） 編寫需求規(guī)格說明書； （ 4） 需求驗(yàn)證 。 或者說 ， 廣義的需求管理還應(yīng)包括用戶需求的收集 、 處理 、 分析和驗(yàn)證等內(nèi)容 。 從定義出發(fā) ， 需求管理涉及三個(gè)方面的內(nèi)容： 需求定義的管理 、 需求實(shí)現(xiàn)的管理 、 需求變更的管理 。 CMM2需求管理的目標(biāo)是： （ 1） 控制指定給軟件的系統(tǒng)需求 ， 為軟件工程和管理應(yīng)用建立基線； （ 2） 保持軟件計(jì)劃 、 產(chǎn)品和活動與指定給軟件的系統(tǒng)需求一致 。 因此 ， 需求管理活動的內(nèi)容應(yīng)包括就軟件的需求同客戶達(dá)成一種共識并加以管理 。 而需求管理就是這六個(gè)關(guān)鍵過程域中的第一個(gè) ，是其他五個(gè)域?qū)嵤┑那疤?。 這一控制過程的含義同時(shí)還指：確保項(xiàng)目組和用戶 （ 或稱為項(xiàng)目利益關(guān)系人 ） 對作為項(xiàng)目結(jié)果的項(xiàng)目產(chǎn)品以及生產(chǎn)這些產(chǎn)品所用到的過程有一個(gè)共同的理解 。 范圍管理 是指對項(xiàng)目包括什么和不包括什么的定義與控制過程 。需求工程包括獲取、分析、規(guī)定、驗(yàn)證和管理軟件需求，而 “ 軟件需求管理 ” 則是對所有相關(guān)活動的規(guī)劃和控制。 換句話說，需求管理就是： 一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個(gè)使客戶與項(xiàng)目團(tuán)隊(duì)對不斷變更的系統(tǒng)需求達(dá)成并保持一致的過程。 系統(tǒng)或系統(tǒng)構(gòu)件為了滿足合同、規(guī)約、標(biāo)準(zhǔn)或其他正式實(shí)行的文檔而必須滿足或具備的軟件功能。電氣和電子工程師學(xué)會使用的定義與此類似。 ? 國內(nèi)軟件業(yè)的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。 ? 需求是對系統(tǒng)要做什么、如何工作、表現(xiàn)出來的特征、必須具備的質(zhì)量、必須滿足的約束的敘述 ? 需求的重要性 ? 需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。 Brooks[1987]：不能得到完整、正確以及無二義性的軟件需求仍然是如今導(dǎo)致軟件開發(fā)失敗的一個(gè)重大原因 需求的噩夢 一組數(shù)字 據(jù) Standish Group(1994)的研究表明，在美國： ?每年大約花 2500億美元，開發(fā) ?大公司開發(fā)項(xiàng)目的平均成本是 ?中等公司的平均成本是 ?小公司則是 另一方面： ?大約 31%的項(xiàng)目在完成之前被取消 ?%的項(xiàng)目成本是項(xiàng)目原來預(yù)算