近來，我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件。不幸的是，當他們開發完這個工具后，發現這個工具不能打印出源代碼文件，使用者當然希望有這個功能。結果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。
相反的情況，我曾見一個要集成到“錯誤跟蹤系統”中的簡單界面寫了一頁需求說明。而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用。他們依據需求對系統進行測試時，此系統不僅非常清晰地實現了所有必需功能，而且未發現任何錯誤。
事實上，需求文檔在開發過程中一直起指導作用。
3.需求分析過程
可把整個軟件需求工程研究領域劃分為需求開發和需求管理兩部分更合適
需求開發可進一步分為：問題獲取、分析、編寫規格說明和驗證四個階段。這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動。需求開發活動包括以下幾個方面：
確定產品所期望的用戶類別。
獲取每個用戶類的需求。
了解實際用戶任務和目標以及這些任務所支持的業務需求。
分析源于用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息。
將系統級的需求分為幾個子系統，并將需求中的一部份分配給軟件組件。
了解相關質量屬性的重要性。
商討實施優先級的劃分。
將所收集的用戶需求編寫成文檔和模型。
評審需求規格說明，確保對用戶需求達到共同的理解與認識，并在整個開發小組接受說明之前將問題都弄清楚。
需求管理需要“建立并維護在軟件工程中同客戶達成的合同” 。這種合同都包含在編寫的需求文檔與模型中�？蛻舻慕邮軆H是需求成功的一半，開發人員也必須能夠接受他們，并真正把需求應用到產品中。通常的需求管理活動包括：
定義需求基線(迅速制定需求文檔的主體)。
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。
以一種可控制的方式將需求變更融入到項目中。
使當前的項目計劃與需求一致。
估計變更需求所產生影響并在此基礎上協商新的承諾，這種承諾具體體現在項目解決方案上。
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤。
在整個項目過程中跟蹤需求狀態及其變更情況。
以上幾點說明是我總結了成功實施項目后系統分析人員的經驗，同時也根據國內外的其他系統實施的相關成功經驗，進行了總結。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
