關於需求-III

需求是一種實踐型的工作，在項目中永遠不能說我能寫好需求，通過不斷練習，不斷向編寫好的需求靠近。有一些需求編寫的技巧如下：採用較短的句子，易於編寫，容易閱讀理解。採用一致性的術語。採用主動語氣，例如「系統應……」。如果句子中出現了「和」或者「或」，則分開成為兩個句子。總之，需求是否容易被理解，看系統設計人員是否經常來找你詢問，此外，好的需求描述加上一些具體的實例，就是功能測試的用例，是為系統測試人員提供便捷的。編寫需求規格說明書也有一些誤區。需求不是設計，即需求不是如何去實現這個系統，不是流程，而是對系統業務功能的詳細解釋。需求說明不是來自於軟體實現，例如系統原型不是需求，系統原型是用來引導需求的，此外需求中避免使用軟體的功能名稱。需求也不是解決方案，不包括技術的細節，尤其在網站系統的需求編寫過程中。

需求是一條一條編寫出來的，用例圖是一幅一幅畫出來的，當完成部分需求或整個需求文檔以後，要對組織會議對需求文檔進行驗證和評審，利用需求檢查表保證需求的若干特性最大程度的實現。評審還有一個重要的原因是合規性檢查，看需求是否和項目外部的法律、法規、業務規則等存在衝突。這是對客戶、公司的項目干係人提供一種保障。但有的時候，因為進度的要求，需求評審流於形式，或者是根據系統開發的功能後補的需求，但實際上害的還是自己。完成內部需求評審，還要給項目干係人進行審批，讓客戶、用戶共同評審需求規格說明書，因為需求用的是業務語言，所以客戶也易於理解，從而確保需求的理解，如果評審通過，可以採用個人簽字，專家評審簽字的會議紀要方式等對需求規格說明書進行確認。

經過驗證、評審和審批後的需求為項目範圍基線，如果以後再出現需求變更情況，則可以對需求進行有效的控制。需求變更在軟體項目中是非常常見的，控制不是避免變更，而是控制變更，減少對後續的設計、開發工作有更大的影響。關於變更的控制，要利用項目計劃中的變更控制來進行，完成團隊對變更進行評估，上級領導和客戶進行審批等工作。

n

完成需求規格說明書以後，將需求放在需求跟蹤矩陣中，採用需求跟蹤矩陣的意義是，保證需求、設計、開發、測試過程的一致性，容易對過程數據進行度量。需求跟蹤矩陣還確保需求是可以修改的，維護需求變更的歷史。再者就是需求是可以被跟蹤的，可以在系統的生命周期中看到需求被實現的狀態。最後放置在需求跟蹤矩陣中的需求是需求的簡要描述，是按照優先順序和功能類別分類的，可以通過需求的編號和需求規格說明書中的需求進行對應。管理需求跟蹤矩陣是一項工作量大，技術要求高的工作。

推薦閱讀：