何謂需求？簡單的理解，就是用戶期望軟件達到的效果。既然是期望，一個看不見摸不到的東西，憑着客戶去想，再讓研發人員去分析，理想與現實的差距也就慢慢顯現出來。用戶的需求分析不準，需求的界限又難以清除的劃定，失敗的由頭便開始埋下，畢竟需求才是軟件的始源。因此，對軟件開發我一直持悲觀的態度，在處理用戶需求方面也是謹慎的避免歧義的產生，而非單方面激進的提出過多的功能設想。
大多數情況下，在軟件未開發之前，用戶對軟件功能的要求是非常多的，用一句業內話來說，就是他希望點一下按鈕就解決所有的問題。這是用戶的理想，當然也是軟件供應商的理想，但終歸是理想。現實來說，這個要求很難滿足，我們惟有對用戶的要求一一分析，分清主次，量力而行。
現在很多管理類文檔將需求分爲合理需求和不合理需求兩種類型，這種分類方式本身並沒有錯誤，但在實際判斷起來卻很難，主要是無法清晰的界定合理和不合理的屬性，用戶和研發人員的出發點是不一樣的，每個研發人員也都有各自的認識，很難確定合理與不合理的標準。因此我更主張將需求按重要程度進行分級，需要解決用戶核心問題、必須問題的需求就是重要的，其他的就可以認爲是次要的，這就很容易區分了。而且不同的項目可以根據客戶與研發人員的共同認識，靈活的定義重要程度的級次，可以都是重要的需求，可以分爲重要的和次要的，也可以分爲重要的、次要的和更次要的，每個項目都可以有自己的靈活性。需求分類好了，自然就可以在以重要需求爲出發點，兼顧次要需求的基礎上來進行設計。
問題的關鍵開始轉移到如何具體的對用戶需求按重要程度進行分類。這個就是每個項目自己的靈活性了，如果你做的是財務系統，財務數據處理和票據打印就是重要需求；如果你做的是公文系統，文件撰寫和流程處理就是重要需求，等等。做爲用戶和軟件研發人員，這方面的共識還是很容易達成的。如果要想做的更好，則可以將一個系統分成若干個子系統，每個子系統又分成若干個模塊，模塊再劃分成功能點，這樣每一個單元都給其標註重要程度，一個清晰完整的需求框架就出來了。需求有了主次之分，則就容易做出取捨了。
對需求按重要程度進行分類可以認爲是需求分析在宏觀層面的東西，微觀方面則是對每一個需求點如何理解和處理。前者是項目經理或需求負責人的責任，後者則是實際參與需求分析的團隊成員的責任。既然是微觀方面，則越詳細越好，越具體越好，模糊性的詞語一定要杜絕，如“大概”、“應該”、“可能”等等。另外，大家還容易犯的毛病，就是文檔描述過於簡略，憑自己的感覺理解去敘述，把文檔的讀者只定義成自己，而不是完全基於需求事實，將文檔的讀者定義成所有參與項目的人。初入行者和懶於寫文檔的人都容易出現這種問題，但結果是，概括性的語言無限放大了大家對需求的理解，造成歧義。所以，需求越具體、詳細就越好，磨刀不誤砍柴功。
一言一蔽之，需求要先分主次，再具體分析。