第9章需求開發與管理
9.1 目的
通過調查分析、定義、評審、確認、跟蹤、溝通等需求活動，使開發方和客戶對需求有共同清晰的理解，並依據雙方確認的需求開展後續開發工作（如設計、程式設計、測試等）。
9.2 關鍵活動與流程
需求分析與管理的流程如圖9-1所示，關鍵活動是「需求調查與收集」、「需求分析與定義」、「需求評審與確認」、「需求跟蹤」和「客戶溝通」。
開發人員和客戶 迭代
圖9-1 需求分析與管理的流程
該流程的主要工作成果見表9-1。
表9-1 需求分析與管理流程的主要工作成果
9.2.1 需求調查與收集
需求分析人員起草需求問題表，將調查重點鎖定在該問題表內，否則調查工作將變得漫無邊際。問題表可以有多份，隨著調查的深入，問題表將不斷地被細化。
需求分析人員確定需求調查與收集的方式，例如：
☆ 與使用者交談，向使用者提問題
☆ 參觀使用者的工作流程，觀察使用者的操作
☆ 向使用者群體發調查問卷
☆ 與同行、專家交談，聽取他們的意見
☆ 分析已經存在的同類軟體產品，提取需求
☆ 從行業標準、規則中提取需求
☆ 從inter***上搜查相關資料
需求分析人員與被調查者建立聯絡，確定調查的時間、地點、人員等，要特別留意的是不要漏掉典型的使用者。在調查過程中隨時記錄需求資訊，格式參見表9-2。
表9-2 需求資訊記錄
9.2.2 需求分析與定義
1）需求分析
（1）需求分析的目的：對各種需求資訊進行分析、消除錯誤、刻畫細節等。
（2）需求分析的方法：常見的有「問答分析法」和「建模分析法」兩類。
a． 問答分析法
問答分析最重要的問題是：「是什麼」和「為什麼」
每個需求都應當用陳述句說明「是什麼」，如果「是什麼」的內涵不夠清晰，則應補充說明「不是什麼」。如果「是什麼」和「不是什麼」並不是「理所當然」的，那麼應當解釋「為什麼」，以便加深讀者的理解。追究「是什麼」和「為什麼」的目的是獲得正確、清楚的需求。
b．建模分析法
需求建模：指用圖形符號表示、刻畫需求。
對於某些型別的資訊，用圖形表示要比文字表示更加有效。所以將圖形與文字結合起來描述需求是很自然的方法。
2）需求定義
需求定義的目的：根據需求調查和需求分析的結果，進一步定義準確無誤的軟體需求，產生《需求規格說明書》。後續開發工作將依據《需求規格說明書》開展。
需求分析員按照指定的文件模板撰寫《需求規格說明書》。如果待開發的產品分為軟體和硬體兩部分的話，則應當分別撰寫《軟體需求規格說明書》和《硬體需求規格說明書》。
《軟體需求規格說明書》的格式參加表9-3。
表9-3 軟體需求規格說明書
9.2.3 需求評審與確認
（1）需求評審
專案經理先在專案內部組織人員進行非正式的需求評審，以消除明顯的錯誤和分歧。需求分析人員根據內部評審意見，完善《需求規格說明書》。在內部評審期間不能解決的問題，留到正式評審時處理。
專案經理邀請客戶代表和終端使用者代表一起評審《軟體需求規格說明書》，大家盡最大努力使《需求規格說明書》能夠正確無誤地反映使用者的真實意願。
（2）需求確認
需求確認是指當《需求規格說明書》通過雙方評審之後，開發方負責人和客戶負責任人做書面承諾，使之具有商業合同效力。
人們作出書面承諾之前務必要認真閱讀文件，一定要明白簽字意味著什麼。
「書面承諾」的示例如下：
本《需求規格說明書》建立在雙方對需求的共同理解基礎之上，我同意後續的開發工作根據該《需求規格說明書》開展。如果需求發生變化，我們將按照「需求變更控制規程」執行。我明白需求的變更將導致雙方重新協商成本、資源和進度等。
開發方負責人簽字
客戶方負責人簽字
9.2.4 需求跟蹤
（1）需求跟蹤的目的
需求跟蹤的目的是建立與維護「需求-設計程式設計-測試」之間的一致性，確保所有的工作成果符合使用者需求。
為什麼要需求跟蹤？
即使嚴格線性順序的開發模型也不能保證各個開發階段的工作成果與需求保持一致。因為開發者是人而不是機器。由於人們的表達能力、理解能力不可能完全相同，人與人之間的協作很難達到天衣無縫的境界。
（2）需求跟蹤的方式
a．正向跟蹤：檢查《需求規格說明書》中的每個需求是否都能在後繼工作成果中找到對應點。
b．逆向跟蹤：檢查設計文件、**、測試用例等工作成果是否都能在《需求規格說明書》中找到出處。
（3）需求跟蹤矩陣
正向跟蹤和逆向跟蹤合稱為「雙向跟蹤」。不論採用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即**）。需求跟蹤矩陣儲存了需求與後繼工作成果的對應關係。
矩陣單元之間可能存在「一對一」、「一對多」或「多對多」的關係。由於對應關係比較複雜，最好在**中加上必要的文字解釋。
表9-4為簡單的需求跟蹤矩陣示例。
表9-4 簡單的需求跟蹤矩陣示例
使用需求跟蹤矩陣的優點是很容易發現需求與後繼工作成果之間的不一致，有助於開發人員及時糾正偏差，避免幹冤枉活。主要麻煩是，當需求或工作成果發生變更時，開發人員要及時更新需求跟蹤矩陣。
9.2.5 客戶溝通
在整個專案週期內，開發方應當與客戶進行廣泛地交流溝通，盡可能地消除雙方對需求、專案計畫、軟體工作成果的誤解和分歧，不斷改善雙方的人際關係，最終順利地開發出符合客戶需求的軟體。
客戶溝通的主要方式有：
☆ 客戶互動會議。開發方的專案人員、市場人員和客戶代表周期性地開會，開發方向客戶方匯報專案進展情況，雙方對現階段存在的問題進行協商，達成共識。
☆ 成果評審。專案經理應當邀請客戶代表評審重要的工作成果，例如需求評審、使用者介面評審，及早地消除雙方對工作成果的誤解和分歧。
☆ 聯誼活動。為了不斷改善開發方和客戶方的人際關係，專案經理在時間、經費允許的前提下，主動邀請客戶方人員參加聯誼活動，例如運動、聚餐、娛樂等等。
9.3 常見問題解答和實施建議
9.3.1 如何理解「以客戶為中心」
人們開發商業軟體是為了賣給客戶，從客戶那裡賺錢。所以軟體一定要符合客戶需求，否則賣不出去。開發商業軟體一定要以「客戶為中心」，而不能以「技術為中心」。
為了得到客戶的金錢，企業不得不鼓吹：客戶就是上帝，客戶永遠是正確的。
誰都知道這不是真的。事實上，很多時候客戶說不清楚需求、說錯需求或者提出一些無法實現的需求。
所以開發人員不僅要聆聽客戶講述他們的需求，在收集到原始的客戶需求後，一定要進行需求分析，消除錯誤、刻畫細節，最終產生雙方認同的《需求規格說明書》。之後，開發方要有策略地拒絕客戶不合理的需求變更，既不得罪客戶，又保護開發方的利益。
9.3.2 需求建模工具uml、rose
（1）uml
2023年11月，由rational公司發明的「統一建模語言」uml被國際物件管理組織（omg）採納，此後uml成為物件導向建模語言的國際標準。
uml的建模能力超過了以往任何一種物件導向方法，當然複雜性也隨之膨脹。大多數軟體開發人員沒有興趣閱讀枯燥乏味的uml文件。
（2）rose
rose是rational公司基於uml的建模工具。
rose易學易用，它能互動式地構建類圖、用例圖、構件圖、部署圖、狀態圖、活**、順序圖、協作圖等等，深得開發人員的喜愛。
rose有非常豐富的圖形符號和文字標註，能很好地表達模型的細節，因此被很多人用於需求建模。
需要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的複雜化，將使開發人員更難掌握，而且使圖形文件更加雜亂。
世上不存在乙個包羅永珍的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文件中，文字描述是第一重要的，建模主要是起分析、解釋作用。
9.3.3 如何寫好需求文件
開發人員寫不好需求文件是業界普遍存在的問題，原因和對策如下：
☆ 需求調查工作不充分，獲取的需求資訊太少或者太亂，以至於寫不成需求文件。所以要想寫出好的需求文件，前提條件是把需求調查工作做好。
☆ 開發人員寫作能力比較差，雖然在調查過程中已經獲得了不少需求資訊，卻寫不出好的需求文件來。可以毫不誇張地說，國內大部分軟體開發人員的寫作能力遠不及開發能力。提高開發人員寫作能力的根本辦法就是讓他們多練習寫文件。
另外，企業應當提供合適的文件模板以及比較好的示例文件，盡可能地降低寫作難度。
☆ 開發人員撰寫需求文件後，一定要認真檢查文件，力求使需求文件達到：正確、清楚、無二義性，一致、必要、完備、可實現、可驗證。
9.3.4 如何使開發方和客戶共同理解需求
不論是複雜的專案還是簡單的專案，開發人員和客戶都有可能誤解需求。所以雙方的需求評審很重要。嚴格地講，應當檢查需求文件中的每乙個需求，每一行文字，每一張圖表，以確保需求文件準確反映客戶真實的需求。
第九章採購管理
採購管理是財務及企管軟體購銷存系統的乙個子系統，它的主要功能包括以下幾個方面。採購訂單管理 採購訂單管理包括採購訂單的編制 採購訂單的審核，動態掌握採購訂單的執 況，並向拖期交貨的 商發出催貨函。採購業務處理 採購業務處理主要包括採購入庫 受託代銷入庫 採購退貨 採購結算等內容。採購管理系統處理採購...
第九章班級管理
1 班級管理的功能有哪些？1 有助於實現教育目標，提高學習效率 2 有助於維持班級秩序，形成良好班風 3 有助於鍛鍊學生能力，學會自治自理。2 班級的規章制度由哪些部分組成？1 教育行政部門統一規定的有關班集體與學生管理的制度 2 學校根據教育目標 上級有關指示制定的學校常規制度 3 班集體根據學校...
第九章調動管理
一 目的 規範員工調動手續，確保對員工的各項工作不致因調動而出現脫節 失誤。二 範圍 適用於所有正式員工的崗位調整 調動等手續的辦理。第一節調動定義與分類 一 調動的定義及相關費用劃分 一 調動 因工作需要調往其它公司，或部門 崗位發生變動的情況稱為調動。二 借用 因工作需要 開業 大忙增援或其他情...