需求工作大體分為：需求收集，需求分析。需求收集就是派人到甲方單位收集相關人員對系統的要求。大公司有專職的需求人員去做這個事，小公司可能就是項目經理去做這件事了。不同的人去做自然效果不一樣。需求收集需要記錄完整，準確。一個系統在甲方單位涉及到多個崗位，職位的用戶。每類用戶對系統的訴求是不一樣的。曾經一個系統，就主界面都做了4版，甲方領導說界面看上去要高端、大氣，信息展示豐富，主要的報表圖表什麽的都要在首頁顯示；中層職位用戶要求我只關心我那部分的數據、工作流程，其他的不要顯示；基礎崗位用戶要求界面簡潔，輸入方便，盡量少讓點擊鼠標，到處找。最後按用戶崗位不同，進入系統後顯示不同的主界面。如果在需求收集階段，漏掉部分類型的用戶，後期再調整工作量就會加大。需求收集階段記錄的內容基本上是作為原始需求的，但也需要準確，詳盡。因為有些用戶在講述要求時，不能很準確的描述，用些比如，類似，就像之類的詞。有時是在需求人員的提示下才能說明白，“對，就是你說的那個”。

這就要求需求人員有一點的行業知識，能從行業背景，企業背景去理解客戶說的要求，並提示，補充完整。同時需要對收集到，理解到的需求進行適當的轉義，轉成軟件行業內語義。

還有個關鍵人物也應該參與到需求工作中，測試人員。因為後期的測試都將基於需求來驗證功能是否達到規定要求。

還有個人也應該參與到需求工作中來，主開發員（核心開發，設計人員）。後期開發中的設計，技術選型，工作量估算都需要準確了解需求。同時彌補需求人員在與客戶溝通時，軟件專業技術知識的不足，特別是需求分析階段，有些需求在技術實現方面存在困難，或沖突都需要專業軟件人員來一一分析、識別。對後期的開發也是有利的。核心開發人員掌握第一手的需求，而不是通過其他人轉述的，更容易把握需求，使開發在正確的軌道上進行。

有了專業技術人員的參與，在工作量，時間估算上也會更準確。當然這裏的專業技術人員就是以後項目開發的主技術員。交給誰來做就應該由誰來估算工作量，工作時間。否則都是不準確的。在這點上吃過虧，掉過坑。項目的初次談判，到簽訂合同，往往都是項目經理（或老板）和甲方項目負責人，碰個面商談項目的大概情況，覺得可以做，就讓項目經理寫總體設計，實施方案。這些又都是套用以前項目的文檔改改，就拿去投標了，到簽訂合同。到了開發時，開發人員手上可能都沒有需求文檔，就一個總體設計。做到具體的功能又去詢問甲方用戶，一問傻了，這麽多，這麽復雜。而總體設計或者合同上寫得很粗獷。導致最後的時間估計不足，技術風險估計不足，技術準備不足。

就角色而言，需求工作需要：需求人員，主開發人員，測試人員，或者 項目經理，主開發人員。即不能少了主開發人員角色。

需求，需要誰參與進來？