浅谈软件需求调研的方法

韦明武

摘要：软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。对于一个应用软件来说，需求调研是一个系统开发的开始阶段，它是为我们项目设计阶段而准备的，需求调研的质量也直接关系和决定了软件的交付结果，

关键词：调研计划；需求报告；需求分析

软件需求工程是软件工程中重要的环节，是整个软件开发过程中最基础最重要的部分，同时也是一个复杂的庞大的工程体系，本文无意对整个软件需求工程进行说明，而仅就最开始的需求调研这部分来简单说明如何进行有效的需求调研工作。需求调研，简而言之就是和客户进行谈话沟通，把客户的想法和要求记录下来，最后整理成为《用户需求说明》，以便进行下一步的需求分析、系统设计等，正因为后面的需求分析、系统设计，乃至开发等等都以需求调研的内容为依据，那么需求调研质量的好坏直接就决定了软件系统的好坏，也即项目的成败。通常我们一提到某个系统，感觉上应该始终就是一个东西，但其实在不同人眼里，可能是不一样的，比如按照一般软件开发过程来说，就有如下几种：1、客户实际需要的软件2、客户脑子里想的软件3、调研人员调研后的软件4、设计人员设计出来的软件5、开发完成的软件（这里面要注意客户实际要的软件和客户脑子里想的软件可能并不是一个东西）如果上述中间各个过程都有理解偏差，那么很可能就出现最终开发完成的软件和客户实际需要的软件差异较大，一个失败的或者做的不好的项目，往往原因就在这里。而且还有一点，上述过程中，越往后，修改这些偏差要付出的代价就越大，直到你无法承受。那么，保证你调研出来的需求和客户实际的需求以及客户脑子里想的三者保持一致，并且这个需求在开发上是能够实现并且容易实现，就是每一个需求调研人员努力要做到的。

1需求调研流程

调研计划要有明确的起始时间与结束时间，并将调研计划分为6个阶段进行。调研准备阶段:此阶段需要拟定调研计划，并得到甲方的认可（甲方认可调研计划，方便安排相关部门人员配合需求调研的访谈与记录）。完成标志：甲方认可《需求调研计划》。需求调研实施阶段:按照需求调研计划的日程实施调研，最后形成《用户需求调研总结报告》。每天调研小组要对当天的调研形成总结，每周向甲方小组提交一次总结报告。甲方项目组对《用户需求调研总结报告》中的偏差和遗漏进行指正（将需求记录下，并随时得到客户确认）。完成标志：需求调研计划日程完成，完成《用户需求调研总结报告》。提交文档形成阶段:对需求调研过程中分析形成的用户需求说明，由甲方业务部门进行确认，形成《软件需求规格说明书》初稿。完成标志：提交给甲方《软件需求规格说明书》初稿。文档提交阶段：确认完善《需求说明书》并按甲方意见对《需求说明书》进行修改。完成标注：甲方对《需求说明书》确认签字。

2制定调研计划与方式

需要确定每项内容的调研方式（集中、分散）、调研时间、调研内容、参与人员。调研方式:参与人员超过2人以上，建议还是采取集中方式，一个是客户集中精力专注于调研这件事，较少被其他工作事情打扰；另外就是集中方式，大家提出的最后意见是共享的、一致的，不需要我们再分头去确认、协调用户之间的不一致意见；还有很多时候，是需要经常看我们系统的功能的。分散方式主要针对那些少量问题确认，或了解详细业务的情况，且必须调研的这个人是权威人士，也就是他说了算。调研内容:按业务类别分开几块，组织不同的人员进行调研，经营做一次，生产做一次，办公做一次。参与人员:不论哪类业务，各层面的人员一定要派代表参加，有业务衔接的部门也要参加，否则可能会遗漏一些关键性的问题。比如项目管理，各专业科室需要派1-2名代表参加，设总、生产部门主任、生产管理人员、总工、分管生产的领导都需要参加。

3编写调研提纲

在调研计划确定后，需要向客户索取资料，主要包括体系文件、管理制度、业务表格、流程等，以便有针对性的准备调研提纲。根据用户前期提供的资料，结合合同要求的模块功能，编写每个模块功能需要了解的问题。对于用户已提供的表单、流程等，只需在调研提纲中一一确认是否按已提供的资料来做即可，不要再重复提问题。另外针对提供资料有疑问的地方，也需要在调研提纲中列出问题。如果前期有技术支持人员事先和用户对接过业务需求或项目前期进行过招投标，则需要了解这方面的内容，将用户提出或招标文件的一些要求补充到调研提纲进行细化。避免针对同一个问题重复提问，或是用户讲过的问题又去问一遍，这样容易造成用户反感。对于客户单位已经有其他的系统，也要在调研提纲中考虑接口及使用习惯等问题。对于我们没有原型系统或者用户需求描述不清的情况，尽量结合图表、界面模型进行准备，才能更直观的引导出用户的需求。

4现场调研

主要是围绕调研提纲，结合我们的系统或界面模型演示进行调研。调研过程中，尽量不要打断用户的说话，这样会打断用户的思路。对于用户需求一定不要有想当然或者猜测的成分，所有不清楚的地方一定要问清楚。对于没有听明白或者觉得不对的地方，我们可以将用户的意思重复一遍来和用户确认。引导用户按流程发生的先后顺序描述，这样条理性较好，不会出现遗漏。对于调研中用户跑题的情况，可采用问题总结性发言的方式，将用户拉回来。调研时，经常碰到用户意见不统一，长时间讨论的情况，难免延误已有的调研计划，可建议先继续其他问题，此问题待后面他们讨论清楚后将结果告知我们即可。但对于业务复杂难以控制进度的问题则可以让用户继续下去，要搞清楚为主。对于我们熟悉的业务，调研问题应该尽量带有引导性，比如一个功能怎么做，尽量用我们已有的功能或我们觉得应该怎么做的方式和用户讨论，从而引导出用户的真正想法，而不是简单的提问，这个功能应该怎么做，很多时候用户是答不出来的。了解用户的实际业务以后，我们需要将这些业务在系统实现上进行优化，将实现的效果和用户确认。我们做系统的目的是帮助用户进行流程优化，管理提升，而不是仅仅将手工流程搬到系统来进行。调研结束后，根据调研内容整理调研记录，对于遗留问题及待提供资料，单独罗列一个列表，连同调研记录发送给用户，并确认要求提交的时间。调研时，可直接在调研提纲上对问题进行回答，这样整理调研记录时只需将调研提纲整体过一遍，补充完善即可。有些时候，我们会觉得用户的某些要求不合理或者没必要，这个是需要多站在用户的角度来考虑问题，而不是以我们的感觉来作为标准。目前我们碰到的很多客户都是用过系统的，他们提出的需求是特别值得重视的，因为他们是在大量的使用经验基础上提出的真正有用的功能，他们觉得值得做的功能，特别是那些易用性方面的需求。另外当我们觉得不合理或者没必要的时候，可以多问下客户为什么需要这样做，需要这样控制，这样就能搞清楚用户的真正用意了，从而可以和用户更好的分析讨论如何解决此类问题。对于有些规则可能不是很合理，但却是客观存在的，我们不能因为不合理不科学而不去接受它，但这种问题一定要得到客户的认可和确认。

5整理调研记录

一般我们的调研结果，都是在调研提纲上将调研结果直接记录的，那么整理调研记录，就可以将调研提纲里面的调研内容直接进行整理，比如补充完整、修改描述，在整理的过程中，结合需要实现的功能，也就是我们实现功能的几大要素（表单、流程、权限、业务规则），看看是否都提供了，将待提供的资料、疑问等罗列出来，发给用户进行补充。

6需求报告

对于需求文档，有两种情况，一种是用户没有贯标文件，没有自己的表单、流程，这种情况一般是拿演示原型系统的表单流程与用户确认，再根据用户的修改意见，拿原型系统的需求文档进行修改，这样能比较快速的形成需求文档。另一种情况是，用户有自己的表单、流程，这种情况如果拿原型系统的需求文档来修改，改动量会比较大，还不如重新编写每个模块的需求。根据调研记录及用户提供的资料，进行需求报告的编写。由于我们的需求报告编制的比较细，到字段级，因此编制过程中还会有细节的规则或问题需要和用户讨论。这类问题可以先在需求报告中进行标注，待需求报告编制完成再统一电话问用户或现场讨论。对于某些功能的实现方式，建议和开发人员多讨论，定出比较好的实现方式和实现效果以后，再写入需求报告，避免需求报告中描述的功能要求，开发人员实现困难。需求报告编写完以后，需要经过内部评审，评审通过后再发送给客户进行审核确认。确认签字后的需求报告才能作为设计开发的依据。

7结语

需求调研是为需求说明书做前期工作，可以说需求说明书说是从需求调研表中得到或抽取而出。需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程，再把这些需求细节整理由设计部开发，再由销售部销售给用户。本文通过对于软件需求调研的流程、具体实现方法的阐述，论述了需求调研的各流程步骤的目的以及实现的具体操作。

参考文献

[1]王晓宁.关于如何做好软件需求分析的探讨[J].科技资讯，2010.

[2]冯阿芳，石研.软件需求分析的思考[J].中国新技术新产品，2010.

[3]孟亚辉.浅析软件开发项目中的需求分析[J].职业圈，2007.