需求的概念

    從根本上說，需求來源于用戶的“需要”和“要求”，這些“需要”和“要求”被分析、整理、確認后形成完整的文檔，該文檔詳細地說明了產(chǎn)品“應當”實現(xiàn)的功能。

    需求的重要性

    需求是整個產(chǎn)品鏈的源頭，需求工作的優(yōu)劣將直接影響到產(chǎn)品的設計，生產(chǎn)，銷售和維護的全過程。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。目前國內(nèi)很多軟件業(yè)普遍存在這樣一個現(xiàn)象：人們并不真正清楚到底該做什么，卻一直忙碌不停地開發(fā)。
Frederick Brooks在他的經(jīng)典文章“No Silver Bullet”是這樣描述需求的重要性的：開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。

    什么是需求管理

    把所有與需求直接相關的活動通稱為需求管理。
    需求管理中的活動可分為兩大類，
    需求分析：對用戶的需求進行整理、分析和完善，形成文檔
    需求維護：需求確認，需求跟蹤和需求變更

    需求工程貫穿產(chǎn)品生命周期的全過程。

    需求管理的主要內(nèi)容
    需求分析流程
    需求調(diào)查
    首先需求分析員起草需求調(diào)查問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)查工作將變得漫無邊際。問題表可以是層次化的，隨著調(diào)查的深入，問題表將不斷地被細化。問題表應當以“選擇題”和“是非題”為主。
    其次，需求分析員應當確定需求調(diào)查的方式，例如： 與用戶交談，向用戶提問題。向用戶群體發(fā)調(diào)查問卷等。
    還可以從用戶的工作流程，相關文檔以及行業(yè)標準、規(guī)則中提取需求。分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。
    最后，需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員等，進行需求調(diào)查。
細化用戶需求
    根據(jù)用戶需求調(diào)查，對用戶的需求進行細化，對比較復雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解需求。例如采用Rational 的Rose工具進行需求的建模分析。
撰寫需求說明書
   需求分析員按照指定的文檔模板撰寫《需求說明書》。如果待開發(fā)的產(chǎn)品分為軟件和硬件兩部分的話，則應當撰寫《軟件需求說明書》和《硬件需求說明書》。

    需求確認

    需求確認是指開發(fā)方和客戶方共同對《需求說明書》進行評審，雙方對需求達成共識后作出承諾。需求確認包括兩方面的工作：“需求評審”和“需求承諾”。
    需求評審： 對需求的必要性和可行性進行分析，確定需求文檔。
    需求承諾： 開發(fā)方和客戶方的對通過了正式技術評審的《需求說明書》作出承諾，按照“變更控制規(guī)程”執(zhí)行，明確指出需求的變更將導致雙方重新協(xié)商成本、資源和進度等。

    需求跟蹤

    需求跟蹤的目的是建立與維護“需求－設計－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。
    需求跟蹤有兩種方式：
    正向跟蹤：檢查《產(chǎn)品需求規(guī)格說明書》中的每個需求是否都能在后繼工作成果中找到對應點。
    逆向跟蹤：檢查設計文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。
    正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣。需求跟蹤矩陣保存了需求與后繼工作成果的對應關系。

    需求變更控制

    需求變更的原因：
    隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。
    市場發(fā)生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。
    需求變更控制的目的：
    提出需求變更的動機是好的，目的是希望產(chǎn)品更加符合用戶的需求。對項目開發(fā)小組而言，變更需求意味著要調(diào)整資源、重新分配任務、修改前期工作成果等，開發(fā)小組要為此付出較重的代價。如果每次需求變更請求都被采納的話，這個項目也許永遠不能按時完成。
    如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。
    需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個問題最好的辦法是事先建立“游戲規(guī)則”。