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