心曲沉烟，悄望雪云平

  在软件系统开发过程中，最让人头痛的问题之一恐怕就是用户需求的变更了，由此导致的交付延期、预算超支、功能减少、质量下降等后果通常令人头痛不已。而实际情况又是，任何系统的开发过程都会遇到需求变更的问题，从我以往的经验看，变更的比例在1/4到1/3都是正常的。
  用户，尤其不是IT领域的用户，通常很难用专业的语言表达他们的需求。而软件开发团队则通常以自己熟悉的方式与用户沟通，就如在UML中，我们觉得已经非常直观、非常简洁的Use Case图，在很多非专业用户看来，依旧是一头雾水，尤其是在面临一个复杂的业务需求时，Use Case图的表达能力是有限的。
  开发人员都希望用户需求越明确越好，最好是如同[input]-->[processing]-->[output]这样形式化过程化的语言描述，既避免了含糊不清的表达，也可以借助一些工具来自动生成设计方案、乃至源代码。计在算机界，这种理想在几十年前就进行过大量的讨论和实验。可惜至今除了汗牛充栋的paper work，所谓需求工程方面的研究工作的实际成效甚微。
  因此，问题又归结到两方面：
  第一，如何有效获知用户的需求。
  第二，如何减少潜在的需求变更。
  需求分析的实质是人与人的交往问题。从社会学的角度考察，在人际交往中,矛盾和冲突是经常出现的。常见的人际冲突可以归纳为以下几种;①组织结构冲突。这主要是指由于组织结构中的不合理因素导致的人际关系的矛盾与冲突；②沟通障碍冲突。这主要是指因对情况了解不全面或未能及时交换意见而造成的意见分歧或误解,偏见等；③利益分配冲突。这是由于涉及个人利益的问题上存在不公平,或因主观期望过高而自感不公平而引起的矛盾和冲突；④个性差异冲突。这是由于个性差异,如兴趣爱好不同,性格特征不同,而导致的互相看不惯或不适应。正是由于这些冲突的存在，需求分析的工作才显得具有极强的不确定性。基于此，软件开发团队不妨问几个问题：
  1. 我们与之交流的用户，是否是有权决定系统功能需求的角色？若不是，应该去找谁？
  2. 用户内部如果有分歧，我们能做些什么降低风险？
  3. 我们能否确认用户理解我们的意思？若不能，该怎么办？是否可以不用技术语言来交流？
  4. 我们能否确认我们理解用户的意思？若不能，该怎么办？是否可以不用专业语言来交流？
  5. 若用户对自己的需求表达不完整，我们应该如何协助用户梳理自己的思想？
  6. 用户能否及时地主动发出需求变更请求？若不能，该怎么办？
  7. 我们在不理解用户需求的情形下，是否能及时与用户交流？若用户的态度很冷淡，又该如何？
  8. 若用户没有及时地反馈，我们是否需要调整自己的计划？
  9. 我们是否可以开发出一些简单的界面、原型，给用户一个正确的直观的认识？
  10. 我们与用户之间的开发合同或者协议是否足以令我们承担需求变更的风险？
  11. 用户提出的需求是否都是必要的？能够删减？
  这些问题的解决，对于有效地进行需求分析会有些帮助，但还不是全部。用户需求永远是动态的，开发团队的应变能力是成熟度的重要表现，能否有效地应对需求的变更则是一块试金石。
 
  不过，有时候也在想，闭门造车造出来的难道一定不是好车吗？