需求分析的几个问题
需求分析的问题跟设计的问题差不多：有那么多可行的手段，哪一种才是最好的呢？
同一个问题，从不同的视角看，可能产生多种不同的划分结果。但是最稳妥的其实只有一种：那就是用户自己的视角。
需求分析如果作为一种记录用户需要的手段，那么采用用户自己的视角原样记下用户对系统的描述当然是很重要的。最终的需求或产品也许与用户最初描述的并不一样。但是用户的这些描述最少会是一个很好的分析起点。它从解决不确定性的角度来说仍然是具有相当大的价值的。
在这个阶段，如果尝试去曲解用户的需求当然也是可以的。有文章认为需求分析是对系统的定义。这其实是一种从开发方理解的观点。开发方需要得到具体的问题描述或方案描述。比如一个细致到页面元素的需求规格，它到底是一个问题描述还是其其实已经是一个方案？
我觉得凡是涉及系统本身的东西都应该是属于设计范畴里的东西。用户的需求应该永远地独立于任何系统以外。开发方当然可以去分析这样的需求，但是分析的结果中不应该包含系统设计的因素。拿着系统设计与用户去讨论，这正是为什么很多项目最终失败的原因。因为用户根本不理解系统级的语言。就象开发者也没有办法理解用户的需求一样。
现在有一种观点其实也是现实那就是，很难找到那种就是两边都懂的人：即懂需求又懂开发。因为什么呢？
因为需求肯定有人懂，开发也有很多人懂，这就象是英语有人懂，汉语也有人懂，但是没有即懂英语又懂汉语的人。为什么这么说呢？
意思是，比方，需求分析得到一个结果（纯文字描述或图形化描述，或形式化描述），系统设计也得到一个结果（形式化）。两者都可以做得很好。但是如何把两者映射起来，这个才是问题。如果能找到两边都懂的人，那么显然，简单地在两边连连线就差不多了（比喻）。
上面有提到形式化的需求描述。这个可能会是解决需求问题的一个重大突破口：因为系统设计的结果“正好”也是一个形式化系统。如果需求分析已经能得出形式化的结果，为什么不能把这个形式化直接映射到系统设计的结果中去呢？
Ontology就是一种这样的技术。我们不需要两边都懂的人，也很难找到这样的人。但是我们可以很容易找到或培训懂Ontology的人。
页:
[1]
