需求工程系列（一）- 软件需求的困境 - 分析代替了需求

alimama_pid="mm_11307516_1146824_2589042";
alimama_titlecolor="0000FF";
alimama_descolor ="000000";
alimama_bgcolor="FFFFFF";
alimama_bordercolor="E6E6E6";
alimama_linkcolor="008000";
alimama_bottomcolor="FFFFFF";
alimama_anglesize="0";
alimama_bgpic="0";
alimama_icon="0";
alimama_sizecode="12";
alimama_width=468;
alimama_height=60;
alimama_type=2;

转载：需求分析 http://blog.csdn.net/adwu73/archive/2008/07/13/2646329.aspx 十年来国内软件工程方面的进展有目共睹，在软件需求方面，我们看到在大多数组织中已经建立起了一级或两级需求体系（业务需求和软件需求）；在某
些组织中，需求分析员已经成为一种专门的职位；甚至在某个大型国有商业银行已经成立一个专门的部门来负责需求分析工作。应该来说，这是一些非常可喜的进
步。

然而，目前大多数的项目参与者都对需求工程的现状不满，这又是为什么呢？首先，我们必须承认市场快速变化而带来的需求变化的确对项目带来了很大
的挑战，为此许多项目应用了迭代化开发来应对这样的变化。但根据我们对客户的访谈，更多的需求变化是由于需求沟通不力造成的，也就是说，参与需求沟通的各
方并没有达成真正的共识，这又是什么原因呢？根据我们的分析，这主要是由于缺少一个可以被各方真正理解和沟通、并可以被逐步精化的需求体系。

目前，大多数用户采用的需求体系基本上是沿袭了结构化分析的文档体系（包括数据流图，数据字典等）。这种文档体系起源于70年代，当时，软件的
主要应用还是科学计算或信息处理，理解需求的人往往也受过结构化分析的相关教育，然而这些内容对今天的大多说业务人员或最终用户而言就是很难理解的了。这
里的主要问题是分析代替了需求。为了解决这个问题，有的组织引入了非形式化、非结构化的业务需求，然而却很难在两种需求之间建立明确的对应关系，从而出现了业务人员/最终用户认可业务需求，但开发人员觉得不够详细；开发人员认可软件需求，但业务人员/最终用户无法给与确认。

那么，我们如何解决这一软件需求的困境呢？ （待续）