如何正确的理解和管理需求及其变更：
  问题1: 从项目的需求搜集开始，业务专家搜集和提出基于整个业务的需求体系，但是在从初始的需求转化为软件特性和功能的过程中，由于业务专家和技术人员的沟通不充分或者需求描述不完善，导致技术人员对需求的理解产生曲解，从而影响该软件完成后不符合用户提出的真实需求。
  问题2: 从初始的业务需求转化为软件特性的过程中，缺乏有效的跟踪和管理，导致软件功能特性与用户需求脱节。
  问题3: 在项目过程中，用户提出改进的需求或者增加软件功能和特性，项目组在了解需求后，对软件架构进行调整或者重构，但是如此频繁的重复下来，需求来源不清楚，软件规格书未反应需求变化，或者接受需求但未调整项目的整体进度，导致一些混乱情况的发生。
  上述1，2个问题其实都是对需求跟踪和管理机制的不完善引起的。在任何一个软件开发过程中，都充分地强调了需求管理的重要性。因此，在项目初期，相对花比较多的时间做需求的搜集和跟踪，完善业务人员和技术人员的沟通机制是很重要的。这会减少大量的由于曲解需求导致软件不符合用户需求从而返工造成的人力和物力的浪费。避免这种情况产生的一种方式是，在项目立项后，由专人或专门的团队(这些人必须是了解该项目业务领域的知识，并且有相关的技术经验)搜集该项目的原始需求，然后和技术专家(或团队)进行充分的沟通和讨论，保证技术专家对原始需求乃至一些用户要求的细节有完整而正确的理解，接着技术专家就会根据原始需求的文档，根据对需求的理解撰写软件规格书，在写的过程中，应该不断让业务专家一定程度的参与(例如审稿或一定程度的修订，并且参与评审)，这样的软件规格书才能为进一步正确地进行软件分析设计提供素材和指导。
  对第3个问题，用户提出的对软件进行改进可能是经常有的事情，遇到这种情况，有两种处理办法。一种办法是用户提出的改进建议在下一个发布版本中实现。但是用户往往要求能够在当前版本中进行实现。第二种办法就是认真考虑用户用户的建议，用各种方法来满足用户的需求，其中包括系统重构。在这些过程中，可能会造成一些混乱。其实归根结底还是需求的跟踪机制不完善引起的。建议采用需求和变更跟踪工具(比如rational clearquest)来对需求和变更进行全过程的跟踪，这样在形成需求文档的时候，每个需求来源和其状态都是非常清楚的。