需求工程之一概览

  2013年参与某能源集团的信息化平台建设，更多的负责了前期的调研工作和设计工作，当然也还在继续编码。在和客户的沟通交流过程中积累了一些需求调研方面的经验，恰逢年终总结之计给自己整理总结，也希望能够给后来者提供一些帮助。

一、认清需求工程

需求工程，需求的调研过程是一个系统性的工程，既然是系统性的工程就要遵循一定的规律和工程学方法。

需求工程几乎涉及到所有的项目干系人，会涉及到跨公司、跨部门的协作，而且由于人对事物的认知是不断趋向于正确的(复杂多变)，因此需求工程是一项极其复杂的工作。认清需求工作的困难性，摆正确自己的态度是成功的第一步。需求工程切记客户说什么记录什么，然后拿着记录的文档回去就组织后续工作，这会使后期的工作万劫不复。

从上而下大方向调研：对于整个信息化系统而言，系统级别的范围的界定，是从上而下的，这种调研对象应该是集团信息化一把手。这个范围的界定应该在签订项目合同的时候就已经达成共识了。接下来子模块的功能，就需要和相关部门干系人进行确认了。所以在调研的初始阶段，应该是从上而下的。

从下而上小细节确认：从上而下这一过程完成后，对整个系统的思路和整体方向就了把握。当然这还远远不足以形成文档，我们还需要跟操作层进行细节调研。操作层对于某一细节领域会更具有权威，他们会提供一些具体的资料，尽量保持这些资料(单据、报表等)是有内容的。

 

二、需求工程的周期

  需求工程是复杂的，因此我们需要了解需求工程的周期，把握其规律。

  入下图所示，我们常说的需求调研是分为很多个过程的。我在刚刚开始做需求方面工作的时候，客户在描述需求的时候，我总是不自觉的把需求转化为“界面原型”和“具体的业务事件”，后来被同事批评了。他告诉我，需求调研和需求分析是两个过程，调研的时候先多去了解客户提出的问题，搜集资料等，先不着急去做分析。因为在不了解整体情况的时候，你的分析可能是有偏差的。因此，调研的时候就应该已调研为主，拿到较为全面的第一手资料之后，在开始进行分析。

  分析的过程中，可能为产生业务流程图和业务模型，甚至简易的操作界面也会出来。注意，我们的分析一定是有成果的，而不是和客户简单的达成口头共识。分析出来之后，就需要组织客户进行确认了，这个会是一个反复的过程。随着项目干系人的认知提高，PDCA戴明循环螺旋上升。对于分析输出成果没有问题了，就要和客户签字确认了。

  和客户签字确认完之后，公司内部对需求进行评审，评审完毕之后，开始进去其他项目阶段。也开始了需求变更的管理。

三、需求工程过程的把控

  开始开发之后，需求也是会发生变更的，因此我们需要需求过程多的管理。公司今年新来的以前做外包的同事，认为变更是管理不到位，对这种变更他是深恶痛绝的。当然人人都是深恶痛绝，但是需求变更只能减少，不能消除。需求变更后，要及时的调整计划和需求规格说明书等等。

四、需求工程与开发的衔接

需求通过内部评审后，进入开发阶段。开发过程中碰到需求变更不要立马就去改动，要权衡着去调整。

五、需求工程与测试及验收的衔接

需求规格说明书出来后，可以开始编写测试计划和用例。由于需求说明书是甲方和乙方干系人的共识，因此在项目验收或验收的时候也要适当以此作为依据。

 

  以上是今年工作中的大致总结，后期会慢慢完善，并且写的更加详细一些。