主题：【原创】软件开发项目中的需求开发问题 -- 闲云野熊

链接出处终于看到有人在河内讨论软件工程问题了，兴奋ing,但在下还是决定另开一题，因为在下关注的问题是属于项目管理范畴，而不是软件工程范畴。

本文所讨论的软件开发项目，是特指为某客户订制开发软件应用系统，而不是根据市场需求开发一个软件产品。因为本熊没有这方面工作经验，所以没有发言权。

在本文中，本熊只是提出了自己遇到的问题和自己的看法，并没有多少理论支持，希望河内高人指教。

在软件开发项目中，本熊最感到困难的就是需求的确定，事实上，在本熊参与开发的所有项目中，从没有需求真正确定的例子。有的只是开发人员与用户的妥协产物：

成功的项目：

开发人员：我只能做到这样了，以后咱们再搞一个二期工程？

用户：我先凑合用吧，不过按合同我们还有个适应性维护期，到时候你可得随叫随到给我改！

。。。。。。。

不成功的项目：

开发人员：我只能做到这样了，这已经比当初的需求多多了！

用户：你们这样不行呀！这个系统现在跑不起来！要么换人，要么加人给我做，什么？没人了？！扣钱！

。。。。。。。。

几乎所有的开发人员都有一个梦想：让我经历一回真正的瀑布开发流程吧！所有的需求都在最初的阶段得到确定，我们获得了一个完美的系统定义。。。。。但是梦想肯定是梦想。

为什么总是这样呢？

本熊认为原因可能有以下几点：

（1）开发一个新系统，尽管是用户订制的，但这是一个以前从未存在过的系统。任何人无法凭空想象该系统如何运作，如何实现以前从未实现的功能。因此没有人能够告诉开发人员这个系统的功能如何匹配系统建设目标。只有获得了一个实际的系统才能检验实际运行能否满意。而在实施过程中，用户的灵感总会被不断激发，产生新的愿望。

（2）一个系统的使用肯定牵扯到用户群体中的很多人，每个人，每个部门都对系统有着自己的幻想，都希望维护自己的利益。而这些利益不一定重合为系统建设目标。因此需求调研有如盲人摸象，只能获得很多片面、破碎的信息。这些信息之间有矛盾，不可调和，只能妥协，但妥协只能带来各方面都不满意。

（3）对项目建设有决定权的领导有自己的看法，但这些看法只能通过下级人员反映给开发者。下级人员会塞入自己的意见。其次，系统的使用者不关心投入，只关心系统是否减轻自己的负担。因此最初的需求调研肯定获得了很多锦上添花的需求，而不是系统建设目标所必需的需要。

（4）开发者并不实际关心系统是否贴近用户需要。只是关心是否不被抓住把柄。承建商只关心预计开发成本是否压缩利润。

针对以上问题，本熊认为

（1）必须把需求开发视为一个过程，包括原始需要调研、整理出面向用户需要说明、面向用户的功能设计、面向开发者的需求分析、面向用户的操作运行设计、面向开发者的设计任务书。分清需要、功能需求、操作需求、性能需求、系统集成需求之间的关系。

无论用户代表多么有经验，需求开发必然是一个递进的、迭代过程。因此在需求开发过程中不要急于确定系统边界（这是无法确定的），应该首先关注当前尚未实现的最主要的功能。

（2）认真分析用户群体，找到真正的组织结构图，找到用户在系统中的位置和相互关系。并在用户中建立系统建设代言人链，在这一链条中的成员必须真正是系统建设的责任和利益相关者。并且直达决策层。如果该链条中的成员不能达到决策层，必须纠正，否则项目无法成功。

（3）建立项目需求开发组，成员一定不能是系统设计者。强迫用户、需求、设计开发者之间的交流通过文档进行。并隔离用户和设计开发人员。避免用户对系统设计、开发组织的干扰，避免设计开发者之间不能充分理解用户需求。同时审定需求追踪和需求变更管理。

（3）建立需求字典，使双方讨论问题概念一致。

（4）建立用户能够接受的成本估算方法，与用户共同估算开发成本，核算需求变更成本。

（5）必须记住，与其他系统的接口是客观存在的，并不因为用户没有想到就不存在，并不因为可以推迟考虑就减轻，反而可能更严重。在处理接口时的原则是没有接口谁的承受能力低谁的工作量大，谁越早做出行动和形成文档谁越主动。

• 也试着侃一哈