何谓需求？简单的理解，就是用户期望软件达到的效果。既然是期望，一个看不见摸不到的东西，凭着客户去想，再让研发人员去分析，理想与现实的差距也就慢慢显现出来。用户的需求分析不准，需求的界限又难以清除的划定，失败的由头便开始埋下，毕竟需求才是软件的始源。因此，对软件开发我一直持悲观的态度，在处理用户需求方面也是谨慎的避免歧义的产生，而非单方面激进的提出过多的功能设想。
大多数情况下，在软件未开发之前，用户对软件功能的要求是非常多的，用一句业内话来说，就是他希望点一下按钮就解决所有的问题。这是用户的理想，当然也是软件供应商的理想，但终归是理想。现实来说，这个要求很难满足，我们惟有对用户的要求一一分析，分清主次，量力而行。
现在很多管理类文档将需求分为合理需求和不合理需求两种类型，这种分类方式本身并没有错误，但在实际判断起来却很难，主要是无法清晰的界定合理和不合理的属性，用户和研发人员的出发点是不一样的，每个研发人员也都有各自的认识，很难确定合理与不合理的标准。因此我更主张将需求按重要程度进行分级，需要解决用户核心问题、必须问题的需求就是重要的，其他的就可以认为是次要的，这就很容易区分了。而且不同的项目可以根据客户与研发人员的共同认识，灵活的定义重要程度的级次，可以都是重要的需求，可以分为重要的和次要的，也可以分为重要的、次要的和更次要的，每个项目都可以有自己的灵活性。需求分类好了，自然就可以在以重要需求为出发点，兼顾次要需求的基础上来进行设计。
问题的关键开始转移到如何具体的对用户需求按重要程度进行分类。这个就是每个项目自己的灵活性了，如果你做的是财务系统，财务数据处理和票据打印就是重要需求；如果你做的是公文系统，文件撰写和流程处理就是重要需求，等等。做为用户和软件研发人员，这方面的共识还是很容易达成的。如果要想做的更好，则可以将一个系统分成若干个子系统，每个子系统又分成若干个模块，模块再划分成功能点，这样每一个单元都给其标注重要程度，一个清晰完整的需求框架就出来了。需求有了主次之分，则就容易做出取舍了。
对需求按重要程度进行分类可以认为是需求分析在宏观层面的东西，微观方面则是对每一个需求点如何理解和处理。前者是项目经理或需求负责人的责任，后者则是实际参与需求分析的团队成员的责任。既然是微观方面，则越详细越好，越具体越好，模糊性的词语一定要杜绝，如“大概”、“应该”、“可能”等等。另外，大家还容易犯的毛病，就是文档描述过于简略，凭自己的感觉理解去叙述，把文档的读者只定义成自己，而不是完全基于需求事实，将文档的读者定义成所有参与项目的人。初入行者和懒于写文档的人都容易出现这种问题，但结果是，概括性的语言无限放大了大家对需求的理解，造成歧义。所以，需求越具体、详细就越好，磨刀不误砍柴功。
一言一蔽之，需求要先分主次，再具体分析。