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