的事情。只有進行深入收集和分析，才可以消除任何沖突或不一致性。
信息量越大，對準確理解客戶的需求越有幫助，但同時，對需求的分析也就越難。對于軟件項目，我認為這可能是最困難、最關鍵、最需要交流的工作。因為軟件不是硬件，不是主板，顯示卡之類看得到摸得著的東西，軟件是思想，是理念，是規(guī)則，是對真實世界的抽象。軟件項目的交付物是有形的，可又不同于其他行業(yè)，比如汽車的構造是固定的，其組成部分是不變的。
而一個軟件系統(tǒng)的模塊劃分則可以有多種方法，多種結構。這個特征導致對軟件項目經理的抽象思維能力要求很高，要求要有較強的邏輯性。否則，就有可能表現為缺少全局概念，對項目整體的范圍和業(yè)務系統(tǒng)把握不夠，在項目過程中被客戶牽著鼻子走，今天客戶說要個什么功能，就添加個什么，明天要修改個什么，就跟著修改什么，被動至極。
將客戶信息結構化，編寫成需求文檔。這是需求定義的工作。公司的《產品需求規(guī)格說明書》的主要內容包括：“ 產品介紹；描述用戶群體的特征；定義產品的范圍； 闡述產品應當遵循的標準或規(guī)范；定義產品中的角色；定義產品的功能性需求；定義產品的非功能性需求，如用戶界面、軟硬件環(huán)境、質量等需求；”僅有這份需求文檔還不夠，我上現場調研時帶了個美工，將我們和客戶溝通好的軟件部分用圖形界面UI畫了出來。
需求定義是需求獲取中最“痛苦”的一件事情，為了盡量避免日后的扯皮，我們力圖使每個需求都應當用陳述句說明“是什么”，如果“是什么”的內涵不夠清晰，則應補充說明“不是什么”。
如果“是什么”和“不是什么”并不是“理所當然”的，那么應當解釋“為什么”，追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對需求定義的標準大致如下：
需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎？需求是必要的嗎？需求可實現嗎？需求可驗證嗎？需求的優(yōu)先級確定了嗎？等等。
以上就是我個人的總結，希望在項目需求管理上對大家有所幫助。