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