也是我上面談到的先請行業(yè)專家的原因。畢竟，客戶是不可能給你系統(tǒng)地介紹業(yè)務的。只有你通曉了行業(yè)業(yè)務，才能和用戶交流，并正確而有效地引導客戶，做好需求分析，你不能指望客戶能明確地說出需求。當然，這也是系統(tǒng)分析人員的職責所在。在開始做需求的時候，你最后花一點時間搞清楚你接觸的客戶是不是做實際業(yè)務的客戶，如果你面對的客戶不是將來的系統(tǒng)的實際使用者。你就有點麻煩了?？赡芩强蛻艄九蛇^來的IT部的人，他會提一大堆東西，而這些東西可能根本不是實際業(yè)務需要的功能，而他一般還會興致勃勃地給你一些技術實現的建議。這個時候你就要小心了，如果你聽了他的話，你可能在最后才發(fā)現，你花了大量精力解決的問題，其實并不是客戶真正需要的。而你真正需要關注的，卻做得遠遠不夠。
? 參考其他類似軟件和系統(tǒng)
在經過與客戶的溝通，并形成初步的需求之后，不要急成正式的需求，請先參考一下以前的一些系統(tǒng)，去理解一下了解到的需求與原先系統(tǒng)的差異，并去發(fā)現是否有些需求會產生錯識需求。
? 業(yè)務建模
為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。
? 需求整理并形成需求規(guī)格說明書
需求規(guī)格說明書的模板我想每家公司都是不一樣的，也沒有必要都一樣，但我認為每個需求規(guī)格說明書至少應包括
軟件需求一旦通過了評審，就應該基線化，納入配置管理庫。而在配置管理庫中的文檔或代碼不能再輕易進行修改。當有需求要進行變更的時候，就必須提出申請，寫需求變更計劃，審核通過，才有權限進行需求變更。然后配置管理員一定要做好需求的跟蹤。，凡是跟變更需求有牽連的開發(fā)人員和測試人員都要同步的通知到和及時讓他們做好相應部分的各類文檔的修改。
? 需求變更管理
需求的變更管理我個人認為是最容易出問題，一般項目做不完也主要是由此產生。需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改變他們的工作方式；或者要開發(fā)的系統(tǒng)對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨著開發(fā)工作的不斷進展，系統(tǒng)開始展現功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現。如何有效的管理需求變更，下面是我公司目前的做法。公司采用Test Director作為需求管理工具，需求人員每次與客戶溝通后形成需求調查表，統(tǒng)一錄入Test Director,并進行綜合及整理后形成需求規(guī)格說明書， 之后由研發(fā)部、產品部、及銷售代表（如果有客戶參加就更好了）進行需求評審，建立需求基線。制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循變更控制流程進行控制，同時每一筆重要的需求變更都需要客戶簽字確認才認為需求變更生效。需求變更后，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。因為Test Director提供了需求變更記錄，可以幫助我們形成良好的文檔，便于進行管理。
2. 需求管理
首先要針對需求做出分析，隨后應用于產品并提出方案。需求分析的模型正是產品的原型樣本，優(yōu)秀的需求管理提高了這樣的可能性：它使最終產品更接近于解決需求，提高了用戶對產品的滿意度，從而使產品成為真正優(yōu)質合格