需求的問題，是一個簡單的問題

發布: 2008-10-15 11:18 | 作者: 網絡轉載 | 來源: 測試時代采編 | 查看: 162次 | 進入軟件測試論壇討論

　更精確的優先級設定如下表：

權值 1 1     1   1
需求收益代價價值價值% 成本成本% 風險風險% 優先級
<需求> <1-9> <1-9> <> <> <1-9> <>  <1-9> <>  <>

　　其中各權值按實際情況而定，不能確定按1取值。

　　收益：實現此需求對用戶的益處；

　　代價：未實現此需求對用戶的損害；

　　價值=收益*收益權值+代價*代價權值

　　價值%=價值/（總價值）*100%

　　成本：實現此需求所需的各種成本；

　　成本%=成本/（總成本）*100%

　　風險：實現此需求所承擔的風險，特別是技術上的；

　　風險%=風險/（總風險）*100%

　　優先級=價值%/（成本%*成本權值+風險%*風險權值）

　　最后按需求優先級排序，優先實現高優先級的需求。

　　風險的控制和避免：

　　對需求將可能面臨的風險要有充分的估計并盡量避免風險的發生及其所造成的損失。建立風險跟蹤，保持對危害最大的幾項風險的控制，并在開發過程中周期性地更新風險跟蹤項目。

　　需求的問題，是一個管理的問題

　　需求取得：市場銷售部門、技術支持或客戶服務所得到的需求，或者開發人員內部通過對業務的分析歸納得出的一些要改進的功能。

　　對需求進行管理的環節應該盡可能精簡。最好直接由系統分析來做。經過很多環節的篩選，需求可能已經走樣了。紙面上只有一兩句話的需求，背后有你看不到的真正想法存在。所以應該主動走出去尋找需求，應該選擇最典型的客戶進行訪問。領會他們的管理思路和改革方向。

　　需求決策：對于相互矛盾的需求，在同類用戶中由產品代表決策；對于不同類用戶要根據重要性作適當折衷；對于用戶的特別喜好要根據用戶的重要性決定；用戶中領導的需求要服從最終實際使用的用戶需求；當開發者想象中的產品通常要服從用戶的需求，但并不表示用戶總是對的。

　　需求分析：分析需求的各個特性，制作出需求分析規格說明書。

　　需求評審：由相關人員共同對需求進行評審。

　　需求變更：如果遇到需求的變更，需要及時作出調整，即使與開發部門聯系，提出變更的建議，并分析可能產生的影響，如對產品穩定性的影響。變更的需求需要嚴格的測試。

　　版本控制：確定需求文檔版本，確定單個需求文檔的版本；

　　需求跟蹤：需求的跟蹤記錄需求的狀態，包括未定義、放棄、需完善、已定義、實現中、待測試、測試中、完成、放棄實現等

　　需求管理工具：曾經看到過的工具有Rational Requsite Pro 4.5版。需要用Word 97支持。但對中文的支持不夠好。

需求的問題，是一個簡單的問題

需求的問題，是一個簡單的問題