【文章內(nèi)容簡介】 系統(tǒng)需求 功能性需求 非功能性需求 設(shè)計約束 需求分析 —— 細(xì)化用例 在需求獲取過程中 ， 我們建立了業(yè)務(wù)模型和系統(tǒng)模型 ， 引入了角色和用例的概念 角色與用例的區(qū)別： ?系統(tǒng)的角色是業(yè)務(wù)之外與業(yè)務(wù)交互的人或事 ?例如： ATM取款機作為一個業(yè)務(wù)系統(tǒng) ， 來取款的客戶就是一個角色 ?用例是業(yè)務(wù)模型中 ， 業(yè)務(wù)的活動 ?在系統(tǒng)模型中 ， 描述了業(yè)務(wù)中系統(tǒng)的工作 （ 內(nèi)部活動 ） 。 角色是外部 ， 用例是內(nèi)部 。 取款的客戶是角色 ， 取款是用例 。 用例模型開始定義角色之間的關(guān)系 （ 關(guān)聯(lián)關(guān)系：包括關(guān)系 、 擴展關(guān)系 、一般化關(guān)系等 ） 。 用例模型描述事件流 ， 包括主事件流 、 其他事件流 、前提條件 、 事后條件等等 。 需求分析 —— 細(xì)化用例 細(xì)化用例的主要步驟： ?審查主角 ?細(xì)化描述 ?定義和細(xì)化事件流程 ?確定前置條件和后置條件 ?確定特殊需求 ?擴展用例 需求分析 —— 細(xì)化用例關(guān)系 為需求處理做準(zhǔn)備 ?在定義系統(tǒng)的用例規(guī)約之前，確定一份基本的術(shù)語詞匯表，以統(tǒng)一項目開發(fā)中的用詞。 ?確定系統(tǒng)的用例，通常從尋找系統(tǒng)的主角開始。如果做了業(yè)務(wù)建模，則可以先從業(yè)務(wù)對象模型中的業(yè)務(wù)工人（ Business Worker）著手。 ?系統(tǒng)主要的主角確定后，可以根據(jù)為系統(tǒng)主角提供有價值的結(jié)果（ Result of Value）這一準(zhǔn)則（用例是為主角的活動最終提供一個有價值的結(jié)果的活動過程）來確定系統(tǒng)的用例。 ?理清系統(tǒng)用例之間存在的密切關(guān)系，具有的內(nèi)在結(jié)構(gòu)，如泛化關(guān)系、包含關(guān)系、擴展關(guān)系等。 ?有二種 Interaction圖 ， 按時間順序排列的是 Sequence圖 ， 按對象關(guān)系排列的是 Collaboration圖 。 二種圖從不同的角度 ， 反映了案例中特定情形的流程 。 需求處理階段 需求規(guī)格說明書 項目 《 用戶需求說明書 》 或 《 前景文件 》 提供了業(yè)務(wù)需求的宏觀描述文檔 ， 使得公司內(nèi)部相關(guān)部門對項目 ， 有一個全局的了解 。 Use Case圖和 Interaction圖為用戶 ， 為項目組提供了需求的詳細(xì)描述 。 為了后續(xù)開發(fā)階段 （ 概要設(shè)計和詳細(xì)設(shè)計 ） 的需要 ， 在傳統(tǒng)模式下， 有了用戶實例 ， 還必須編寫從用戶實例派生出來的功能需求規(guī)格說明書和非功能需求文檔 。 包括：質(zhì)量檢驗標(biāo)準(zhǔn) 、 接口說明等 。 這些文件 ， 成為需求分析的成果 。 CMM2也規(guī)定 ， 必須以文檔形式 ， 給出給定需求 。 需求處理 —— 傳統(tǒng)的 《 需求規(guī)格說明書 》 1 2 3 4 5 6 A 引言 目的 文檔約定 預(yù)期的讀者和閱讀建議 產(chǎn)品的范圍 參考文獻(xiàn) B 綜合描述 產(chǎn)品前景 產(chǎn)品的功能 用戶類和特征 運行環(huán)境 設(shè)計和實現(xiàn)上的限制 假設(shè)和依賴附錄 C 外部接口需求附錄 用戶界面附錄 硬件接口 軟件接口 通信接口 D 系統(tǒng)特性 說明和優(yōu)先級 激勵 /響應(yīng)序列 功能需求 E 其他非功能需求 性能需求 完全設(shè)施需求 安全性需求 軟件質(zhì)量屬性 業(yè)務(wù)規(guī)范 用戶文檔 F 其他需求 G 附件 詞匯表 分析模型 待確定問題清單 軟件需求規(guī)格說明書闡述一個軟件系統(tǒng)必須提供的功能和性能 ， 以及他們必須考慮的限制條件 。這不但是測試和用戶使用 、維護(hù)文檔的基礎(chǔ) ， 而且 ， 也是系統(tǒng)的子系統(tǒng)規(guī)劃 、 設(shè)計和編碼的基礎(chǔ) 。 需求文檔：需求的形式化問題 需求文檔化： 需求一旦確定 ， 就需要把它用文檔的形式 ， 固定下來 。 文檔化的目的： ?首先通過記錄 （ 紙質(zhì)的文字或數(shù)據(jù)庫記錄等 ） ， 使需求被記錄下來 。 任何口頭的傳誤 ， 在文字記錄上 ， 會被減少 。 ?其次 ， 形式化最主要的追求 ， 是解決完整性和無歧義性 。 能真正達(dá)到形式化的需求 ， 是需求分解 、 分配 、 追蹤 、 評估的條件 。 20世紀(jì) 80年代的一項研究表明 ， 20%的錯誤是對需求的錯誤解釋造成的。 IBM公司對需求描述的形式化研究 ， 已經(jīng)提出了一種保證需求文檔更一致的需求描述方法學(xué) ， 使通過使用這種規(guī)定的方法建立的需求 ， 不同人寫的需求之間的差異 ， 已經(jīng)降到最小 。 為了便于需求實現(xiàn)和變更控制管理 ， 需求形式化在形式上 ， 進(jìn)一步發(fā)展為需求數(shù)據(jù)庫化 。 需求形式化 ——消除歧義的努力 消除需求描述的歧義性 ， 是軟件工程的 “ 軟肋 ” ， 沒有什么更好的方法 。 因為對需求的描述和定義 ， 不可能像計算機語言的定義那樣 ， 做到無二義性 。 因為 ， 代價太高了 。 消除歧義的方法： 原始： 了解和記錄用戶的最原始需求 ， 不要轉(zhuǎn)述 、 不要用自己的理解代替 。 關(guān)鍵： 對關(guān)鍵部分 、 關(guān)鍵字 ， 盡量用大家都理解的 、 無二義的限定詞描述 。 逆向： 對需求試著用其他的 （ 逆向的 ） 思維和理解方式進(jìn)行解讀 ， 看有什么可能得到不同的解釋 。 分解： 對需求進(jìn)行分解 ， 在分解過程中 ， 找到不合理和不符合邏輯的錯誤 。 圖形： 用非自然語言的方法 ， 表述需求 ， 減少理解的差異 。 需求的形式化處理 ， 可以幫助你實現(xiàn)以上目標(biāo) 。 需求形式化的技術(shù)方法： 為了規(guī)范化需求 ， 使以下各階段能夠在可分解 、 可追溯 、 允許增 /刪改的基礎(chǔ)上對需求進(jìn)行使用和管理 ， 需求形式化的最基本要求 ， 是應(yīng)該把需求按系統(tǒng)體系結(jié)構(gòu)進(jìn)行分解 ， 形成類似工作分解的 WBS， 需求被標(biāo)上層號和序號 。 需求記錄不僅僅是一篇文字 。 在很多項目組中 ， 需求就是一篇長文章 ， 有的甚至是事后補寫的 ， 更談不上條理化 、 數(shù)據(jù)庫化 。 在這樣的情況下 ， 需求的分解和實現(xiàn) ， 充滿了二意性 ， 完全根據(jù)實現(xiàn)者的理解。 同樣 ， 項目任務(wù)的分解是模糊不清的 ， 需求變更是界線不清的 ， 變更的影響不但無法評估 ， 甚至涉及的范圍都無從知曉 。 在追求需求形式化的道路上 ， 軟件人做了長期的努力 ， 但結(jié)果并不盡人意 。 可以實用的方法有： ?偽代碼 ?有限狀態(tài)機 ?決策表和決策樹 ?活動圖 （ 流程圖 ） ?實體聯(lián)系模型 （ ER模型 ） ?不成功的方法：形式語言描述 需求數(shù)據(jù)庫 在需求數(shù)據(jù)庫的支持下 ， 需求是細(xì)致的 。 如果把需求的層 、 項看成是一個搜索網(wǎng)絡(luò)的話 ， 借助這個網(wǎng)絡(luò) ， 可以全面地捕捉容易疏忽的需求 ， 特別是系統(tǒng)的邊界情況 。 同時需求數(shù)據(jù)庫也是可標(biāo)記狀態(tài) 、 記錄活動的 。 有支持需求數(shù)據(jù)庫化處理的工具 ， 如： Rational的RequisitePro或 MS的 VSS， 來協(xié)助進(jìn)行需求的數(shù)據(jù)庫管理 。 需求記錄和管理的數(shù)據(jù)庫化 ， 先是對需求進(jìn)行分解 ， 然后 ， 是建立需求項的屬性 。 需求形式化的技術(shù)方法： 需求屬性化是需求數(shù)據(jù)庫化的基礎(chǔ) 需求屬性 含義 說明 名稱 * 需求名稱 用最簡潔的語言表示需求的核心含義 描述與定義 * 對需求的描述定義 需求的最本質(zhì)內(nèi)容可以用模型 、 圖 、 表表示 編號層 /序 * 需求的順序號 可根據(jù)系統(tǒng)結(jié)構(gòu)或任務(wù)的 WBS編排 來源 * 需求的提出來源 用戶需求的更高層依據(jù) 、 來源 提出 /決策人 需求的提出人 當(dāng)需求變化或受到影響時能最終決定的人 優(yōu)先級 需求的優(yōu)先級 表明高 、 中 、 低 ， 以備取舍或決定響應(yīng)次序 實體 * 需求實現(xiàn)的實體 表明需求與實現(xiàn)實體的對應(yīng)關(guān)系 狀態(tài) * 需求所處的狀態(tài) 包括：提出批準(zhǔn) 、 實施 、 實現(xiàn) 、 完成或拒絕 、推遲 、 等待 、 丟棄等 。 穩(wěn)定性 需求的穩(wěn)定性 按穩(wěn)定性定義描述穩(wěn)定性的高 、 中 、 低 驗收標(biāo)準(zhǔn) 驗收標(biāo)準(zhǔn) 需求實現(xiàn)的驗證方式和標(biāo)準(zhǔn) 負(fù)責(zé)人 需求實現(xiàn)的負(fù)責(zé)人 備注 對需求的附加說明 作者 需求的提交者 版本號 * 需求的版本號 變更記錄 * 本版本的變更內(nèi)容 描述本版本的變更原因 、 內(nèi)容 、 影響 更新日期 * 需求的變更日期 需求形式化與需求數(shù)據(jù)庫 ?有了具有信息屬性的需求信息 ， 根據(jù)這些屬性描述 ， 我們可以抽象出需求數(shù)據(jù)字典 ， 這樣 ， 我們就可以建立需求數(shù)據(jù)庫了 。 ?通過需求數(shù)據(jù)庫 ， 我們可以方便地對需求的變化 ， 增加 、修改 、 變化記錄 、 狀態(tài)變化等 ， 做出完善的記錄 。 ?更重要的是 ， 借助需求數(shù)據(jù)庫 ， 我們可以： ?分配資源 ， ?評估狀態(tài)， ?計算軟件指標(biāo)， ?管理項目風(fēng)險， ?估算成本， ?確保用戶的安全， ?管理項目規(guī)模。 需求形式化與需求分配 在上面的這張表中定義的一個需求 ， 對應(yīng)需求數(shù)據(jù)庫的一個 “ 數(shù)據(jù)項 ” ， 我們稱之為一個 “ 需求項 ” 。 根據(jù)對整個系統(tǒng)需求的分解 ， 我們可獲得一棵需求樹（ WBS樹 ） 。 “ 根 ” 需求項 ， 就是對整個系統(tǒng)的需求描述 。 需求項在需求 WBS架構(gòu)中 ， 處于節(jié)點的需求 ， 可以分配給一個部門 、 小組或個人 。 他們將根據(jù)人員 、 時間等 ， 再被分解為更細(xì)的需求項 ， 直至不需求再進(jìn)行分解 。 處于 WBS“葉 ” 位置的那些需求項 ， 是需求實現(xiàn)的最低層單位 ， 應(yīng)根據(jù)人員和任務(wù)周期計劃 ， 進(jìn)行工作分配 。 在項目管理中 ， 有了分層次的需求分解 ， 很快 ， 就可以建立根據(jù) “ 需求項 ” 的任務(wù)分解和任務(wù)分配 ， 這就是需求分配 。 需求形式化與需求基線的建立 ?基線 ?在軟件工程環(huán)境中，基線是指在軟件開發(fā)過程中的里程碑，這些里程碑的標(biāo)志是一項或多項經(jīng)過正式的技術(shù)評審并一致認(rèn)同的軟件制品的提交 。 ?項目開發(fā)過程的制品經(jīng)過正式評審并被相關(guān)人員一致同意，可以作為以后項目開發(fā)的基礎(chǔ)。對已經(jīng)基線化制品的修改必須要通過正式的變更控制流程。 ?不同的基線 ?A. 功能基線 (Functional Baseline) ?B. 已分配基線 (Allocated Baseline) ?C. 開發(fā)基線 (Development Baseline) ?D. 產(chǎn)品基線 (Product Baseline) ?在用戶和項目組之間達(dá)成共識、并已經(jīng)按需求屬性建立需求數(shù)據(jù)庫的需求，是建立需求基線的基本條件。 需求基線的管理 ?配置管理組或委員會 （ CCB） 按照需求基線 ， 對整個項目的進(jìn)程 ， 進(jìn)行控制和把握 ， 配置管理員負(fù)責(zé)把符合基線要求完成的構(gòu)件 ， 放進(jìn)配置管理庫中 。 這樣確保了整個需求的基線化控制和管理 。 ?需求基線的核心是按基線進(jìn)行控制 。 ?需求基線的條件是需求形式化 。 因為需求基線是按需求項進(jìn)行控制的 。 需求項是必須形式化的 。 ?需求的跟