的细致性问题
在文章的开头就说明了软件需求在整个软件系统开发中的重要性，正是由于它的重要性，一般来说，需求描述越详细越好。项目的开发方与用户在各种问题上的要求都是基本轮廓达到一致即可，具体的细节可以以后再填充，这是一种非常危险的思想。不管需求分析做的多么细致，以后对需求的变更都是必然的。另一方面，在需求分析阶段，开发人员希望再多投人一些时间，但是用户却不这么认为，因为需求阶段是软件系统开发首先要进人的阶段，离最终开发出可用的系统还有很长一段距离，这导致了双方的不一致。但如果在需求阶段投人很多时间，时间越长，可能的变化就越多，对设计的限制越严格，因此在需求描述的问题上，没有统一的界定，需要开发人员学会适当的把握。
3.2需求描述的正确性
软件开发是一种专业行为，一般的业主难以理解软件开发人员的开发理念。所以在和业主交流时，他们讲述的需求在实际中利用现有的技术是实现不了的，用户以为自己很清楚自己的需求了，但实际上他们只是依据当时的工作需求提出的。随着开发工作的不断进展，用户可能想到更多的功能和特色，进而对以前的需求进行改动，导致需求的不一致。
另外一种情况就是开发人员和业主交流时，由于业主本身对需求的描述不清晰，导致开发人员误解或曲解了业主最初的要求，最后开发出来的系统不是不能满足用户，就是一个发生需求错误的系统。事实上这种错误在需求阶段也会经常发生。更可怕的是，对于需求阶段出现的错误，如果在软件项目进行到后期的时候才发现，修复费用是非常可怕的，甚至会超出项目本身的费用。因此做好需求管理、减少需求错误的出现对于降低软件项目的成本是必要的，也是至关重要的。
3. 3需求描述的完备性
系统的需求是层出不穷的，我们不可能做到把所有的需求都一一列举出来，并且随着时间的推进，用户的需求也会越来越多，要穷举需求是不可能做到的。另外，并不是用户提出的所有需求都要满足，在项目的最后，改变一个需求对整个项目的影响或损失很可能会超过需求本身给用户带来的益处。
3. 4需求的变更
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办?管理它!使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变(Project Scope Creep)问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定程度时，双方才蓦然回首，发现已经物是人非，换了一番天地。
4解决问题的策略
4. 1对需求文档版本控制
客户签收的所有过程文档都要作为基线确定下来，做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线，需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档，这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后，都要重新确定新的需求基线，以免将来用户需求发生变更时，原来的需求无法查找。为有效进行需求变更控制，必然要做的工作就是保存好各个版本的需求基线，维护需求基线文档，以备不时之需。
4. 2正确认识需求变更
在软件开发过程中有这样一条真理:需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是一个变化的过程，需求的变更不一定是坏事，也有可能是好事。
变更的需求之所以变