如何進行需求管理

下面主要針對需求開發及需求管理兩個方面對需求進行分析。　　1. 需求開發，從目前我們的實際工作情況來看按順序主要分成如下幾個部分：　　? 請教行業專家　　行業客戶對信息化的需求越來越細化，對專業性以及行業能力的全面性要求越來越高，惟有深入行業，洞察其需求，研發出更適合客戶需求的產品，才能成功。因此有必要先請這方面的行業專家對於客戶的業務需求進行從流程上的梳理。為什麽請行業專家，而不是直接請客戶進行交談，得到其實需求，個人認為主要是因為目前各政府部門、企事業單位對於信息化與業需求的整合這壹塊缺少經驗，大部分情況還不能完全整理出完善、清晰的系統需求來。只有通過行業專家對其實業務流程進行梳理，壹方面更容易與客戶產生***鳴，另壹方面也可以大大減少因為知識方面的差異導致錯識需求的產生。　　? 和客戶交談　　妳要面對正確的客戶區分不同層次的客戶需求，要面對不同層級，不同部門的客戶，把客戶分類，區分需求的優先級別。如果妳做的項目業務是妳熟悉的，那還好，如果是妳不熟悉的，壹定要花點精力學習壹下這個行業業務的背景資料，這也是我上面談到的先請行業專家的原因。畢竟，客戶是不可能給妳系統地介紹業務的。只有妳通曉了行業業務，才能和用戶交流，並正確而有效地引導客戶，做好需求分析，妳不能指望客戶能明確地說出需求。當然，這也是系統分析人員的職責所在。在開始做需求的時候，妳最後花壹點時間搞清楚妳接觸的客戶是不是做實際業務的客戶，如果妳面對的客戶不是將來的系統的實際使用者。妳就有點麻煩了。可能他是客戶公司派過來的IT部的人，他會提壹大堆東西，而這些東西可能根本不是實際業務需要的功能，而他壹般還會興致勃勃地給妳壹些技術實現的建議。這個時候妳就要小心了，如果妳聽了他的話，妳可能在最後才發現，妳花了大量精力解決的問題，其實並不是客戶真正需要的。而妳真正需要關註的，卻做得遠遠不夠。　　? 參考其他類似軟件和系統　　在經過與客戶的溝通，並形成初步的需求之後，不要急成正式的需求，請先參考壹下以前的壹些系統，去理解壹下了解到的需求與原先系統的差異，並去發現是否有些需求會產生錯識需求。　　? 業務建模　　為需求建立模型，需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助於找到不正確的、不壹致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。　　? 需求整理並形成需求規格說明書　　需求規格說明書的模板我想每家公司都是不壹樣的，也沒有必要都壹樣，但我認為每個需求規格說明書至少應包括　　軟件需求壹旦通過了評審，就應該基線化，納入配置管理庫。而在配置管理庫中的文檔或代碼不能再輕易進行修改。當有需求要進行變更的時候，就必須提出申請，寫需求變更計劃，審核通過，才有權限進行需求變更。然後配置管理員壹定要做好需求的跟蹤。，凡是跟變更需求有牽連的開發人員和測試人員都要同步的通知到和及時讓他們做好相應部分的各類文檔的修改。　　? 需求變更管理　　需求的變更管理我個人認為是最容易出問題，壹般項目做不完也主要是由此產生。需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什麽。用戶常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改變他們的工作方式；或者要開發的系統對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨著開發工作的不斷進展，系統開始展現功能的雛形，用戶對系統的了解也逐步深入。於是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地壹次又壹次出現。如何有效的管理需求變更，下面是我公司目前的做法。公司采用Test Director作為需求管理工具，需求人員每次與客戶溝通後形成需求調查表，統壹錄入Test Director，並進行綜合及整理後形成需求規格說明書， 之後由研發部、產品部、及銷售代表（如果有客戶參加就更好了）進行需求評審，建立需求基線。制訂簡單、有效的變更控制流程，並形成文檔。在建立了需求基線後提出的所有變更都必須遵循變更控制流程進行控制，同時每壹筆重要的需求變更都需要客戶簽字確認才認為需求變更生效。需求變更後，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求壹致。