软件需求本身的特点决定的

    软件需求作为整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，也是软件开发过程中最复杂的一项工作。象以下这些问题很难有一个万全的解决方案。

    ● 需求如何做到没有遗漏?

    ● 如何准确划定系统的范围?

    ● 需求到底描述到多细，才算可以结束?

    如何面对软件项目中的需求变更

    在软件开发过程中如果只有一条真理的话，那一定是:需求不可能是完备的，需求的变化是永恒的。软件开发的过程实际上是同变化作斗争的过程，因此，需求的变化问题是每个开发人员，每个项目经理都会遇到的问题，并且也是最头痛的问题。

    一旦发生了需求变化，你不得不来修改你的设计，重写你的代码、修改你的测试用例，调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常进展带来了不尽的麻烦。那么怎样来解决这个问题呢?下面是我在项目管理过程中积累的一些经验:

    建立需求文档并进行版本控制

    需求必须被记录成文档，这一点很重要。我曾在一个项目中经历过开发人员的角色轮换。每次轮换后，新任需求分析员都跑去对客户蜕:“我们来谈谈需求吧。”客户不胜其烦，回答也变得很不客气:“我早就把需求告诉某某某某了，你们找他们去吧。”实际情况是没有谁把需求明确详细的写下来，所以每位新任分析员都几乎只能是从头开始。

    需求分析的最终成果是，在客户和开发人员对所要开发的产品达成共识后，所编写的具体的文档。只有把所有与项目有关的需求组织起来，编写成易于阅读的文档，并由项目的主要相关人员对这些需求进行评审后，人们才能确定这些需求并定义需求基线。

    在定义需求基线之前，虽然仍然可以对需求进行任意变更，但是，只要创建了初步的需求文档草稿，就应该开始实施版本控制，即唯一的标识每一个需求文档的不同版本。

    需求评审并设置需求基线

    根据项目管理的经验，进行需求评审不仅是必要的，而且是必须的。应该让不同角色的人员从不同的角度对需求进行验证，验证需求的可行性、完整性、一致性、正确性等 那么怎样才能做好需求评审呢?

    评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，在评审文档中存在大量的低级错误或者没有在评审前进行沟通，从而导致评审的效率很低，质量很差。

    为了保证评审的质量和效率，首先要保证使不同角色的人员都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

    为了避免评审小组被冗长的软件需求规格说明所吓倒，在审查整个需求文档之前，可以在整个需求开发期间采用增量式评审和多种评审方式相结合的方法。找出风险高的地方，并进行仔细审查，而风险较小的部分则可以采用非正式评审。。

    需求在通过正式的评审和批准之后。应该确定需求基线，进一步的需求变更将在此基线的基础上，依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。

    对于需求变更控制，绝大多数用户并不喜欢它，其实，变更控制流程并不是一种人为设置的障碍，而是一个漏斗和过滤机制，可以确保项目将最合适的需求包含进来。

    很难想像，一个面对全国上万名会计人员的财务管理信息．系统项目，如果对每个人提出的需求不加任何控制，那将是一种怎样的局面。

    在软件项目的研发过程中，需求变更贯穿了软件项目的整个生命周期，通过建立规范的变更控制流程，改进软件分析与设计，把变化纳入计划之中，在应对需求变更时可以更加的从容和有信心。