項目管理理論與實踐（2）——軟件需求分析

1、需求分析的目的

1. 馬斯洛的需求層次理論

具體能夠參考：（http://baike.baidu.com/view/295140.htm）

 

2. 需求分析的目的

1）與相關干係人在工做內容方面達成並保持一致

2）使設計、開發、測試人員可以更清楚地瞭解需求

3）定義系統邊界，造成需求基線

4）爲估算系統的規模、工做量、成本和進度提供基礎

5）爲開發計劃的造成提供範圍（SOW）基礎

 

2、需求工程概述

1. 什麼是需求工程？用一張圖能夠形象的表示

需求也屬於一門工程學，需求工程包括需求開發、需求管理兩個方面，其中需求開發包括需求開發準備、需求獲取、需求分析、需求驗證。

 

2. 需求分析的流程圖

 

3、需求獲取

1. 需求獲取的基本原則

1）深刻淺出

      對企業的需求調研的要儘量的全面、細緻調研的需求是個全集，系統真正實現的是個子集。

      調研的細緻並不等於在分析時都面面俱到地將調研的內容歸入到新系統中, 而有可能實現的不多,但其中在向細處擴充時將會很容易。

2）以流程爲主線

      應該用流程將全部的內容串起來，如單據、信息、組織結構、處理規則等。

      流程的描述既要有宏觀，又要有微觀。

3）魚刺圖

      石川圖，魚骨圖， ishikawa圖

 

2. 六邊形法則

1）組織結構：企業爲進行相應的業務流程所作的人員的組織安排。

2）業務流程：企業開展業務所必須的各個環節及在每一個環節中的具體作法。

3）業務數據：企業內部經營信息的存儲和流動形式。

4）業務地點分佈：反映企業在什麼地方開展業務以及業務流程中的各個環節之間的地點關係。

5）業務應用：企業以什麼樣的應用軟件處理業務流程中的各個環節。

6）技術基礎設施：企業在信息技術基礎設施上的情況。

 

5、需求分析

1. 繪製關聯圖

1）用於定義系統與系統外部實體間的界限和接口的簡單模型。

2）明確了經過接口的信息流和物流。

 

2. 建立開發原型

1）使得許多概念和可能發生的事更爲直觀明瞭。

2）用戶經過評價原型將使項目參與者能更好地相互理解所要解決的問題。

 

3. 肯定需求優先級

1）應用分析方法來肯定使用實例、產品特性或單項需求實現的優先級別。

2）以優先級爲基礎肯定產品版本將包括哪些特性或哪類需求。

3）帕雷託圖定理（Pareto，2,8定理）

 

4. 爲需求創建模型

1）是軟件需求規格說明極好的補充說明。

2）它們能提供不一樣的信息與關係以有助於找到不正確的、不一致的、遺漏的和冗餘的需求。

3）這樣的模型包括用例圖、流程圖、實體關係圖、狀態圖、時序圖、類圖、對象類及交互調用圖。例如：

而且書寫用例狀況

用例名稱：網站新聞發佈

用例標識號：102

角色：後臺系統管理員

用例說明：後臺系統管理員用來填寫和修改物流網站首頁的新聞，新聞最終顯示在物流網站的首頁上。

前置條件：後臺系統管理員已經登陸物流網站後臺管理系統

基本事件流：

1． 選擇發佈新聞 2． 填寫新聞標題，內容以及上傳圖片 3． 修改標題、內容、圖片，也能夠徹底刪除，重填新聞信息 4． 編輯完成，選擇提交 5． 用例終止

其餘事件流：在提交以前，隨時能夠返回，任何修改內容都不會影響網站首頁的新聞

異常事件流：

1． 提示圖片大小超過範圍錯誤信息，從新上傳， 2． 返回到後臺管理系統主頁面

後置條件：網站首頁的新聞信息被更新

註釋：無

 

5. 編寫數據字典

1）建立數據字典，數據字典是對系統用到的全部數據項和結構的定義，以確保開發人員使用統一的數據定義。

2）在需求階段，數據字典至少應定義客戶數據項以確保客戶與開發小組是使用一致的定義和術語。

 

6. 應用質量功能調配要

1）將產品特性、屬性與對客戶的重要性聯繫起來。

2）明確那些是客戶最爲關注的特性。

3）將需求分爲三類：

–指望需求，即客戶或許並未說起，但如若缺乏會讓他們感到不滿意

–普通需求

–興奮需求，即實現了會給客戶帶去驚喜，但若未實現也不會受到責備

 

6、編寫需求規則說明書

1. 採用軟件需求規格說明模版

1）爲記錄功能需求和各類其它與需求相關的重要信息提供了統一的結構。

2）其目的並不是是建立一種全新的模板，而是採用一種已有的且可知足項目須要並適合項目特色的模板。

1. 概述	編寫目的	系統目標	術語定義
2. 功能需求	功能劃分	模塊名	子模塊	功能名稱	功能描述
3. 非功能需求	性能指標	可維護性	可擴展性	安全性
4. 設計約束	語言約束	系統模型約束
5. 界面要求	頁面佈局
6. 驗收標準
7. 附件	數據字典	模型

 

2. 指明需求的來源

1）爲了讓全部項目風險承擔者明白需求規格說明書中爲什麼提供這些功能需求，要都能追溯每項需求的來源；

2）多是一種使用實例或其它客戶要求，也多是某項更高層系統需求、業務規範、政府法規、標準或別的外部來源。

 

3. 爲每項需求註上標號

1）可跟蹤性和可修改性的質量標準，必須惟一肯定每一個軟件需求。

2）爲每項需求註上標號制定一種慣例來爲需求規格說明書中的每項需求提供一個獨立的可識別的標號或記號。

3）這種慣例應當很健全，容許增長、刪除和修改。

4）做了標號的需求使得需求能被跟蹤，記錄需求變動併爲需求狀態和變動活動創建度量。

5）需求標識方法有序列號;層次化編碼;使用"待肯定"（to be determined, TBD）符號等。

 

4. 記錄業務規範

1）是指關於產品的操做原則，好比誰能在什麼狀況下采起什麼動做。

2）將這些編寫成需求規格說明書中的一個獨立部分，或一獨立的業務規範文檔。

 

7、需求驗證

1. 審查需求文檔

1）在需求開發期間進行非正式評審。

2）對需求文檔進行正式審查是保證軟件質量的頗有效的方法。

3）組織一個由不一樣表明（如分析人員，客戶，設計人員，測試人員）組成的小組，對需求規格說明書及相關模型進行仔細的檢查。

 

2. 依據需求編寫測試用例

1）根據用戶需求所要求的產品特性寫出黑盒功能測試用例。

2）客戶經過使用測試用例以確認是否達到了指望的要求。

3）從測試用例追溯回功能需求以確保沒有需求被疏忽，而且確保全部測試結果與測試用例相一致。

4）要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。

 

3. 肯定合格的標準

1）肯定合格的標準讓用戶描述什麼樣的產品纔算知足他們的要求和適合他們使用的。

2）將合格的測試創建在使用情景描述或使用實例的基礎之上。

 

4. 需求確認簽字

1）在主要的業務清楚之後便可以進行需求確認

2）目的是肯定需求基線

3）不要指望全部的需求在簽字後不變

 

8、需求管理

1. 需求基線

1）軟件需求規格說明及相關分析模型。經評審批准，這些文檔就定義了開發工做的需求基線；

2）創建需求基準版本和需求控制版本文檔肯定一個需求基準，這是一致性需求在特定時刻的快照；

3）以後的需求變動就遵循變動控制過程；

4）每一個版本的需求規格說明都必須是獨立說明，以免將底稿和基準或新舊版本相混淆。

 

2. 需求變動控制

1）肯定需求變動控制過程，肯定一個選擇、分析和決策需求變動的過程。

2）需求變動控制流程

 

3. 創建變動控制委員會

1）組織一個由項目風險承擔者組成的小組做爲變動控制委員會，由他們來肯定進行哪些需求變動，此變動是否在項目範圍內，估價它們，並對此評估做出決策以肯定選擇哪些，放棄哪些，並設置實現的優先順序，制定目標版本；

2）變動控制委員會成員能夠是甲方與乙方的人員共同組成；

3）按期進行需求變動評審會議；

4）每次評審要有評審報告。

 

4. 需求變動影響評估

1）進行需求變動影響分析，應評估每項選擇的需求變動，以肯定它對項目計劃安排和其它需求的影響。

2）明確與變動相關的任務並評估完成這些任務須要的工做量。

 

5. 需求變動時，修改需求跟蹤能力矩陣

1）跟蹤全部受需求變動影響的工做產品當進行某項需求變動時，參照需求跟蹤能力矩陣找到相關的其它需求、設計模板、源代碼和測試用例，這些相關部分可能也須要修改。

 

6. 維護需求變動的歷史記錄

1）記錄變動需求文檔版本的日期以及所作的變動、緣由，還包括由誰負責更新和更新的新版本號等。

2）在需求基線的基礎上記錄變動歷史記錄；

3）針對每個需求造成一個單獨記錄；

 

經過對於軟件需求分析的學習，知道需求分析要承擔着不少風險，所以作好計劃以及風險控制是很是重要的。