需求分析方法

1、 目錄 目錄 目錄 在一個(gè)以 軟件架構(gòu)為中心 的軟件項(xiàng)目開(kāi)發(fā)過(guò)程中，需求分析在概念化階段和架構(gòu)設(shè)計(jì)之間。 軟件需求的基礎(chǔ)知識(shí) 概念化階段分析階段架構(gòu)設(shè)計(jì)階段詳細(xì)設(shè)計(jì)階段 并行開(kāi)發(fā)與 測(cè)試階段 驗(yàn)收與交付 階段 交付的系統(tǒng)軟件需求規(guī)格軟件架構(gòu)文檔軟件設(shè)計(jì)文檔 代碼及集成系 統(tǒng) 愿景文檔 軟件需求的基礎(chǔ)知識(shí) IEEE將需求定義為： 1.用戶所需的解決某個(gè)問(wèn)題或達(dá)到某個(gè)目標(biāo)索要具備的條件或能力。 2. 系統(tǒng)或系統(tǒng)組件為符合合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔而必須滿足條件或必須具備的能 力。 RUP（統(tǒng)一軟件開(kāi)發(fā)過(guò)程）將需求定義為： 1.需求描述了系統(tǒng)必須滿足的情況或提供的能力，它可以是直接來(lái)自客戶需求，

2、也可以來(lái)自 合同、標(biāo)準(zhǔn)、規(guī)范或其他有正規(guī)約束力的文檔。 軟件需求的基礎(chǔ)知識(shí) 軟件需求 非功能需求 功能需求 約束 開(kāi)發(fā)期質(zhì)量屬性 運(yùn)行期質(zhì)量屬性 界面需求 軟件架構(gòu)重點(diǎn)關(guān)注 的是質(zhì)量屬性。架 構(gòu)的基本需求主要 是在滿足功能屬性 的前提下，關(guān)注軟 件質(zhì)量屬性。 商業(yè)需求 軟件需求的基礎(chǔ)知識(shí) p 功能需求 描述要開(kāi)發(fā)的 軟件系統(tǒng)應(yīng)該做什么，既包括為用戶提供的服務(wù)，又包括本系統(tǒng) 為其他系統(tǒng)提供的服務(wù)。 p 非功能需求 包括質(zhì)量屬性，界面需求，約束 以及 商業(yè)需求。 質(zhì)量屬性是架構(gòu)設(shè)計(jì)最受關(guān)注的需求。 架構(gòu)設(shè)計(jì)通常不涉及界面需求。 約束需求規(guī)定了開(kāi)發(fā)軟件系統(tǒng)時(shí)必須遵守的限制條件。如：為了獲得相關(guān)行業(yè)或

3、組織的 認(rèn)可，或者大型企業(yè)集團(tuán)處于長(zhǎng)期整合規(guī)劃的要求；軟件的設(shè)計(jì)和開(kāi)發(fā)可能還必須遵守 相關(guān)行業(yè)標(biāo)準(zhǔn)、企業(yè)標(biāo)準(zhǔn)等約束。 商業(yè)需求可能包含系統(tǒng)的上線時(shí)間要求，成本因素等。 軟件需求的基礎(chǔ)知識(shí) p 軟件質(zhì)量屬性分為運(yùn)行期質(zhì)量屬性和開(kāi)發(fā)期質(zhì)量屬性兩大類： 開(kāi)發(fā)期質(zhì)量屬性包含了和軟件開(kāi)發(fā)、維護(hù)和移植這三類活動(dòng)相關(guān)的所有質(zhì)量屬性； 開(kāi)發(fā)期質(zhì)量屬性是開(kāi)發(fā)人員、開(kāi)發(fā)管理人員和維護(hù)人員都非常關(guān)心的，對(duì)最終用戶而言， 這些質(zhì)量屬性只是間接地促進(jìn)用戶需求的滿足； 運(yùn)行期質(zhì)量屬性是軟件系統(tǒng)在運(yùn)行期間，最終用戶可以直接感受到的一類屬性，這些質(zhì) 量屬性直接影響著用戶對(duì)軟件產(chǎn)品的滿意度。 軟件需求的基礎(chǔ)知識(shí) 運(yùn)行期質(zhì)量屬性

4、開(kāi)發(fā)期質(zhì)量屬性 性能（Performance） 安全性（Security） 易用性（Usability） 可用性（Availability） 可伸縮性（Scalability） 互操作性（Interoperability） 可靠性（Reliability） 魯棒性（Robustness） 易理解性（Understandability） 可擴(kuò)展性（Extensibility） 可重用性（Reusability） 可測(cè)試性（Testability） 可維護(hù)性（Maintainability） 可移植性（Portability） 軟件需求的基礎(chǔ)知識(shí) p 性能（Performance）：軟件系統(tǒng)及時(shí)提

5、供相應(yīng)服務(wù)的能力，包括速度、吞吐量和持續(xù)行 三個(gè)方面的要求 吞吐量通過(guò)單位時(shí)間處理的交易數(shù)來(lái)度量 速度往往通過(guò)平均響應(yīng)時(shí)間來(lái)度量 持續(xù)時(shí)間是指保持高速處理速度的能力 p 安全性（Security）：軟件同時(shí)兼顧向合法用戶提供服務(wù)，以及阻止非授權(quán)使用的能力 p 易用性（Usability）：軟件易于使用的程度 p 持續(xù)可用性（Availability）：在預(yù)定的運(yùn)行時(shí)間中，系統(tǒng)真正可用并且完全運(yùn)行時(shí)間所占 的百分比。 軟件需求的基礎(chǔ)知識(shí) p 可伸縮性（Scalability）：當(dāng)用戶數(shù)和數(shù)據(jù)量增加時(shí)，軟件系統(tǒng)維持高服務(wù)質(zhì)量的能力 p 互操作性（Interoperability）：本軟件系統(tǒng)與其他

6、軟件系統(tǒng)交換數(shù)據(jù)和相互調(diào)用服務(wù)的難 易程度 p 可靠性（Reliability）：軟件在一定時(shí)間內(nèi)無(wú)故障運(yùn)行的能力 p 魯棒性（Robustness）：軟件系統(tǒng)在以下情況仍能夠正常運(yùn)行的能力：用戶進(jìn)行了非法操 作；相連的軟硬件系統(tǒng)發(fā)生了故障，以及其他非正常情況。 軟件需求的基礎(chǔ)知識(shí) 提高可靠性需要強(qiáng)調(diào)減少系統(tǒng)中斷（故障）的次數(shù)，提高可用性需要強(qiáng)調(diào)減少?gòu)臑?zāi)難中 恢復(fù)的時(shí)間。 A系統(tǒng)每年因故障中斷十次，每次恢復(fù)平均要20分鐘，B系統(tǒng)每年因故障中斷2次，每次 需5小時(shí)恢復(fù)。則A系統(tǒng)可用性比B系統(tǒng)高，但可靠性比B系統(tǒng)差。 可靠性的量化指標(biāo)是周期內(nèi)系統(tǒng)平均無(wú)故障運(yùn)行時(shí)間，可用性的量化指標(biāo)是周期內(nèi)系統(tǒng) 無(wú)

7、故障運(yùn)行的總時(shí)間。一般提高可靠性的同時(shí)，也同時(shí)提高了可用性。 要提高可靠性，可使用變更管理，UPS，RAID，Cluster，鏈路冗余等管理和技術(shù)手段減 少系統(tǒng)Down機(jī)的可能性。要提高可用性，除提高可靠性外，還可以使用合理備份，業(yè)務(wù)連續(xù) 性計(jì)劃等方式來(lái)減少?gòu)臑?zāi)難中恢復(fù)的時(shí)間。 軟件需求的基礎(chǔ)知識(shí) p 易理解性（Understandability）：指設(shè)計(jì)被開(kāi)發(fā)人員理解的難易程度 p 可擴(kuò)展性（Extensibility）：為適應(yīng)新需求或需求變化為軟件增加功能的能力 p 可重用性（Reusability）：重用軟件系統(tǒng)或者其中一部分的能力的難易程度 p 可測(cè)試性（Testability）：對(duì)軟

8、件測(cè)試以證明其滿足需求規(guī)約的難易程度 p 可維護(hù)性（ Maintainability）：對(duì)軟件運(yùn)行時(shí)進(jìn)行維護(hù)的難易程度 p 可移植性（Portability）：將軟件系統(tǒng)從一個(gè)環(huán)境轉(zhuǎn)移到另一個(gè)環(huán)境的難易程度 軟件需求的基礎(chǔ)知識(shí) 功能需求架構(gòu)質(zhì)量屬性 約束導(dǎo)致某些功能需求導(dǎo)致某些質(zhì)量屬性需求 支持 限制 影響 適應(yīng) 更大的影響 遵守 軟件需求的基礎(chǔ)知識(shí) p 需求的變更既蘊(yùn)含了風(fēng)險(xiǎn)，又包含了機(jī)遇 p 需求變更可能有三類來(lái)源 我們要解決的問(wèn)題發(fā)生了變化 我們對(duì)問(wèn)題的理解發(fā)生了變化 我們理解問(wèn)題的過(guò)程有誤 軟件需求的基礎(chǔ)知識(shí) p 功能需求最易變，而質(zhì)量屬性需求最穩(wěn)定 p 功能需求的易變性中潛藏著兩類不

9、易變性 功能需求中存在少量長(zhǎng)期穩(wěn)定的功能 功能點(diǎn)本身趨于穩(wěn)定 p 約束性需求的穩(wěn)定性稍差，技術(shù)趨勢(shì)發(fā)生變 化、法律規(guī)范重新界定、用戶組織調(diào)整，都 有可能使約束性需求變更 易變更性 （從低到高） 質(zhì)量屬性需求 約束性需求 功能需求 軟件需求分析實(shí)踐 p 需求獲取五步法 1.收集資料，了解概況，初步劃定范圍 2. 識(shí)別所有可能的需求提供者 3. 準(zhǔn)備需要了解調(diào)研的問(wèn)題 4. 調(diào)查和訪談 5. 總結(jié)歸納，準(zhǔn)備新的問(wèn)題，多次迭代 軟件需求分析實(shí)踐 p 需求獲取的方式 與用戶個(gè)別交流 需求討論會(huì) 查閱相關(guān)文檔 分發(fā)問(wèn)卷調(diào)查表 現(xiàn)場(chǎng)訪問(wèn)客戶 業(yè)務(wù)流程分析 同類產(chǎn)品分析 根據(jù)現(xiàn)有系統(tǒng)推導(dǎo)需求 回顧以往項(xiàng)目

10、觀察用戶對(duì)原有系統(tǒng)的使用 軟件需求分析實(shí)踐 p 識(shí)別所有可能的需求提供者 誰(shuí)使用該系統(tǒng) 誰(shuí)維護(hù)該系統(tǒng) 誰(shuí)需要從系統(tǒng)中獲取數(shù)據(jù) 系統(tǒng)會(huì)影響到誰(shuí) 誰(shuí)推廣該系統(tǒng) 誰(shuí)測(cè)試該系統(tǒng) 誰(shuí)生產(chǎn)該系統(tǒng) 誰(shuí)購(gòu)買該系統(tǒng) 軟件需求分析實(shí)踐 p 需求獲取的常用技術(shù) 需求訪談 推薦3人訪談小組（1人提問(wèn)，1人記錄，1人輔助） 用例技術(shù) 最終用戶使用用例來(lái)模擬 用戶與系統(tǒng)之間交互 用例可以看作是解釋如何使用系統(tǒng)的經(jīng)歷 原型法 需求原型；設(shè)計(jì)原型；產(chǎn)品原型 紙上原型；界面原型；可執(zhí)行原型 拋棄型原型；演化型原型 專題討論會(huì)（頭腦風(fēng)暴） 軟件需求分析實(shí)踐 p 消除原始需求中存在的： 沖突 重疊 遺漏 不一致 不切實(shí)際的 p 細(xì)

11、化需求 p 劃分需求的優(yōu)先級(jí) p 需求建模 軟件需求分析實(shí)踐 p 窮舉：確保需求無(wú)遺漏 p 分類：確保需求無(wú)遺漏并去除冗余的需求 p 分層：結(jié)構(gòu)化表達(dá)需求 p 抽象：識(shí)別出穩(wěn)定與變化的需求 軟件需求分析實(shí)踐 提出者獲取方法文檔量文檔形式評(píng)審方式穩(wěn)定性返工影響 優(yōu)先級(jí) 的確定 者 目標(biāo)需求高層經(jīng)理訪談幾頁(yè)ppt,word 正規(guī)評(píng)審 會(huì) 最穩(wěn)定最大客戶 業(yè)務(wù)需求中層經(jīng)理訪談幾十頁(yè) excel, word 正規(guī)評(píng)審 會(huì) 較穩(wěn)定次之客戶 操作需求 操作員+ 開(kāi)發(fā)人員 原型 幾十頁(yè) ,上百頁(yè) word 非正式評(píng)審 會(huì),正規(guī)評(píng)審 會(huì),分多次評(píng) 審 最易 變化 局部 影響 客戶+ 開(kāi)發(fā)人員 軟件需求分析實(shí)踐

12、 p 步驟一：列舉需求 1.消除客戶需求中的矛盾與不一致 2. 補(bǔ)充遺漏的客戶需求 3. 刪除不必要的需求 4. 定義非功能性需求 5. 定義外部接口需求 軟件需求分析實(shí)踐 p 步驟二：整理需求 1.功能分解 2. 定義內(nèi)部接口 3. 平衡需求、進(jìn)度、質(zhì)量與投入 4. 識(shí)別需求相關(guān)的風(fēng)險(xiǎn) 5. 對(duì)需求進(jìn)行分類 6. 劃分需求優(yōu)先級(jí) 7. 識(shí)別可復(fù)用需求 8. 建立需求分析模型 軟件需求分析實(shí)踐 p 步驟三：需求建模 需求建模方法 結(jié)構(gòu)化建模 IPO ER圖 數(shù)據(jù)流程 數(shù)據(jù)字典 面向?qū)ο蠼?模 USE CASE 模型 USE CASE 圖 USE CASE 描述 靜態(tài)建模 類圖 包圖 動(dòng)態(tài)建模交

13、互圖 簡(jiǎn)單的理解為將自 然語(yǔ)言描述的需求 轉(zhuǎn)換為開(kāi)發(fā)人員能 夠理解的設(shè)計(jì)語(yǔ)言。 軟件需求分析實(shí)踐 p 步驟四：設(shè)定系統(tǒng)目標(biāo)與劃分系統(tǒng)范圍 目標(biāo) 要解決的核心問(wèn)題是什么? 為解決該問(wèn)題的約束有哪些? 范圍 哪些是系統(tǒng)應(yīng)該完成的任務(wù)? 哪些不是系統(tǒng)的責(zé)任? 從廣度與深度2個(gè)緯度考慮范圍 廣度：覆蓋的業(yè)務(wù),部門,功能 深度：做到什么程度？ Gilb的模糊目標(biāo)定律：一個(gè)沒(méi)有明確目標(biāo)的項(xiàng)目，是不可能明確地實(shí)現(xiàn)其目標(biāo)的。 軟件需求分析實(shí)踐 p 步驟五：劃分需求的優(yōu)先級(jí) 1.優(yōu)先級(jí)的分配由系統(tǒng)分析員和客戶一起完成 2. 優(yōu)先級(jí)一般分為3級(jí)，不宜定義太多的等級(jí) 3. 幫助客戶定義優(yōu)先級(jí)的問(wèn)題： 最重要的3個(gè)需

14、求是什么？ 是否有其他方法可以滿足這一需求？ 如果忽略或者推遲實(shí)現(xiàn)這一需求，其后果是什么？ 如果不立即實(shí)現(xiàn)這一需求，對(duì)項(xiàng)目目標(biāo)會(huì)有什么影響？ 4. 需求的優(yōu)先級(jí)可以從兩個(gè)層次來(lái)劃分 用戶劃分宏觀的優(yōu)先級(jí)：需求優(yōu)先級(jí) 開(kāi)發(fā)劃分微觀的優(yōu)先級(jí)：特性優(yōu)先級(jí) 5. 需求的優(yōu)先級(jí)影響了開(kāi)發(fā)順序和開(kāi)發(fā)計(jì)劃 軟件需求分析實(shí)踐 p 步驟六：使用需求分析檢查單來(lái)分析需求 1.檢查單中的問(wèn)題： 需求中包含不成熟的設(shè)計(jì)或?qū)崿F(xiàn)信息嗎？ 這項(xiàng)需求還可以細(xì)分為不同的需求嗎？ 這項(xiàng)需求只是系統(tǒng)的裝飾，而不是真正必須的嗎？ 這項(xiàng)需求符合系統(tǒng)的目標(biāo)嗎？ 這項(xiàng)需求存在二義性嗎？ 這項(xiàng)需求可以實(shí)現(xiàn)嗎？ 這項(xiàng)需求是可測(cè)試的嗎？ 軟件需

15、求分析實(shí)踐 正確 清楚 無(wú)二義性 一致 必要 完備 可實(shí)現(xiàn) 可驗(yàn)證 確定優(yōu)先級(jí) 闡述“做什么”，而不是“怎么做” 軟件需求分析實(shí)踐 Release Product Backlog Sprint 4 week Sprint Backlog Daily meetingsBurn down Scrum開(kāi)發(fā)模型 軟件需求分析實(shí)踐 檢查文檔是否符合標(biāo)準(zhǔn) 組織正式的需求審查 需求審查應(yīng)有一個(gè)多學(xué)科的小組來(lái)進(jìn)行 使用原型來(lái)確認(rèn)需求 編寫(xiě)用戶手冊(cè)草案 設(shè)計(jì)測(cè)試用例 檢查文檔是否符合標(biāo)準(zhǔn) 組織正式的需求審查 需求審查應(yīng)有一個(gè)多學(xué)科的小組來(lái)進(jìn)行 使用原型來(lái)確認(rèn)需求 編寫(xiě)用戶手冊(cè)草案 設(shè)計(jì)測(cè)試用例 檢查文檔是否符合標(biāo)準(zhǔn) 組織正式的需求審查 需求審查應(yīng)有一個(gè)多學(xué)科的小組來(lái)進(jìn)行 使用原型來(lái)確認(rèn)需求 編寫(xiě)用戶手冊(cè)草案 設(shè)計(jì)測(cè)試用例 檢查文檔是否符合標(biāo)準(zhǔn) 組織正式的需求審查 需求審查應(yīng)有一個(gè)多學(xué)科的小組來(lái)進(jìn)行 使用原型來(lái)確認(rèn)需求 編寫(xiě)用戶手冊(cè)草案 設(shè)計(jì)測(cè)試用例 軟件需求管理 p 需求變化的原因 1.誤解 2. 遺漏了需求 3. 外部環(huán)境發(fā)生了變化，產(chǎn)生了新的需求 軟件需求管理 禿頭論證 稻草原理 螞蟻效應(yīng) 軟件需求管理 商務(wù)手段 溝通手段 技術(shù)手段 管理手段 Release Product Backlog