从用户接触到完成需求说明书

在所用技术体系大概范围已经明确的情况下，选择合适的系统分析人员。要求系统分析人员对相应技术体系有一定的了解，以便在相应的分析时有所依据。不同的技术体系有一定的局限性，而有些需求对某些技术体系有一定的难度。如WAP（手机上网）是不太可能实现打印。虽然没有绝对不能实现的用户业务需求，但一般情况下开发协议上明确的费用，已经决定系统功能做到什么程度。

其它

相应的工具的使用熟练程度。如果多人进行分析，分工及责任的明确，及团队的稳定性。相应计划安排是否合理周全等也是影响获取需求质量的因素。

到用户前的准备

组织队伍

根据实际的工作量及其他情况，组建需求调研队队伍，提供办分设备，明确责任、启动任务。

准备相应文档

开发商方的系统分析人员同用户的需求提供人员正式接触前，完成一个问询表及需求分析计划。

一般情况下只需要完成一个整体细节问询表，一般问询用户为明确需求已经完成的文档情况（如果可以在进行正式接触前可以得到并了解完成最好），业务的目的，当前的目标，长远的目标，当前准备情况，完成的业务功能列表，将来系统操作人员的业务及电脑技术了解情况，最终操作用户，当前及将来的硬件、软件及网络环境等整体问题。

由开发商系统分析人员根据对业务的了解程度，适当编写各业务功能细节问询表。不过业务功能细节问询表的使用，是在业务需求调研过程中用户表明其需求后，再根据问题还没有明确的情况下再进行问询的。不过有时业务功能细节问询表由于用户的需求和原计划不同，使业务功能细节表不在发挥作用。

其他业务相关政策法规、技术文档、技术支持人员的通信录等也要进行相应的准备。

联系及了解用户方

同用户进行联系并取得对方的人员名单、分工情况、权重、工作计划、工作时间、节假日安排（特别是用户公司内部的额外规定），如果可能的情况下要求也有用户的IT人员参加需求过程，实际的需求如果没有IT人员的参加，在后面的更改一般是IT人员提出的。应在需求过程中把用户IT人员的需求调研，作为业务调研中一部分。

编写计划

根据当前情况，编写需求分析计划，明确正式开始日期，中间阶段性日期（时间长可多个，调研时间不大于3天可没有），结束时间，人员名单，分工情况，需用户提供的帮助等。

将计划发送给用户请其确认，在可能的情况下协调用户和开发商的计划，以便共同开展工作。

对于计划如果能编写及控制到每日是最好的，但是否可以达到真正可控制到日，那就看你的能力了。如果每3天为一个中间性阶段进行控制，延迟的时间可以通过加班来弥补。计划最好根据一天工作8小时进行。如果计划一天是工作10个小时，也许第一次延迟可以通过加班8小时（一天工作24小时）来弥补，但再有延迟你会发现你的工作人员没有精力再加班了。

如果要去用户所在地进行工作，还要准备相应的办公工具，人手一台笔记本电脑（电源插座及网络互连线也要考虑）是比较好的资源配置。

需求调研

第一日

本次所说的第一日是开发商系统开发人员到用户处正式需求调研过程的第一日。如果是异地调研，那么在第一日前一日开发商系统开发人员应到达用户所在地，结解住宿，了解住宿地周边情况。最好是早些休息，为第一日工作开始做好准备。

一般第一日的上午是开发商系统分析人员和用户业务需要者进行整体介绍，了解办公环境，建立需求调研过程办公环境。如果是小型项目涉及人员不多（双方人员共同不多于3人），一般上午可以进行调研工作1到2小时，不然下午才能正式开始工作（也就说做计划时第1天一般只有半日的工作时间）。

调研过程

调研的过程推荐开发商系统开发人员有专人进行会议记录，并在每日会议结束后，当场宣布本次会议的结果，并由参加会议人员进行签字。第二日复印或发送电子文件给参加会议人员及相关人员。以便做到有据可查，明确过程。

开发商系统开发人员每周对用户提供开发周报，告诉用户当前开发的进展、是否有问题、是否用户协助等，这是一个好的加强双方沟通的方法。

注意：在调研过程的中系统开发人员的变更会对计划产生重大的影响，不要简单认为是人员更换的问题。因为在调研过程中对业务的理解，不是通过看看文档就可以达到。3天通过讨论达到对需求理解的程序，9天对文档的学习也不一定能达到。

整体调研

对于调研过程中的整体调研，一定要其用户主管者及用户全体人员（含用户IT人员）参加，第一个目的是了解用户的整体需求细节，第二个目的使用户人员从各自的角度也了解到用户方要做一个什么样的系统。

需求提供者如果是一个人，他知道自己要一个什么样的系统。但如果是多人，在开发商系统分析人员进行调研前，每人也不过是计划自己的需求而已，即使有时沟通，一般也是在讨论而不是进行结论。使业务需求并不是很明确。整体调研的其中一个目的就是把用户的多人需求组成一个整体，整体调研过程也是一个用户人员沟通并整合需求的一个过程。

用户方多人在进行开发商需求确认前，业务互相有分歧是相当正常的，开发商系统分析人员必须要在需求调研过程，使其达成一致。

一般情况下需明确以下问题:

当前整体业务需求的目的

要求提供的需求功能列表

已经定义的需求规则

将来发展的设想

明确服务器、客户机的软、硬件及性能要求（容量、速度、可操作性等）

用户目前相关的技术人员和业务人员情况

将来最终系统操作人员的技术及业务人员情况

用户需求的系统及用户本身或其它系统的接口要求

用户的其它要求

需求完全明确情况

对于整体调研过后就要进行各个具体业务需求的调研，对于具体需求调研如果是用户提供的现有的文档，开发商的系统分析人员只是对业务进行了解及进行修改为系统分析人员及业务人员全可以看懂的需求说明书，那么这个过程就比较容易。

只要系统分析人员把业务文档看懂看明白，并且对于一些难理解的业务描述修改为易懂（有些业务名词有一定的专业性就要进行额外的说明）、明确进出的单据（数据项）就可以。当然编写需求说明书具体的细节可以参见其他的众多的书籍及文件模版了。

需求不完全明确情况

如果用户对于自己的需求在调研开始并没有完全明确，需要进行引导及细化，那么这个过程就比较麻烦了。

对于用户本身需求不明情况下，对于业务要先从基本业务进行细化，对于不明业务或不确定业务在后面进行。对于进出的单据一般在这种情况下用户当没有现在的文档，这个过程只需明确单据的进出的必须数据源就可以，如果做到细节，由用户在需求调研期确定单证，是不太可能的----只是设计单据的样式、风格就不是短时间可以完成的。对于报表也只能明确基本报表要求及数据项。一般这种情况使用原型法进行，先做一个简单的，在简单的上面再进行完善。

对于用户本身需求不明情况下的调研要做每日（或2到3天,最多3天为间隔）的工作（分析进展）记录，由双方签字，因为调研过程会出现为用户要求添加一支新业务，对新业务进行分析后，因某些原因发现不能添加。这个过程的结果是一个0，但为证明是0这结果可能花了很长的时间。要记录这个过程，说明调研过程中做了什么事情，有时有些人可能会说为什么这么长时间才出这点点东西，到时以便说明原因。

关于选取开发模型

有时开发模型的选取不是很容易判断的，这里面有时不单是需求及开发的问题，对于开发商有开发周期、开发费用的问题，对于用户同样有内部计划、公司发展计划等因素进行影响。

一般来说对于应用开发―――为客户开发软件，客户在开发及测试完毕软件后就要实际开始使用，那么就使用瀑布模型。

当然在需求明确的情况下自然也要使用瀑布模型

对于自主开发及客户需求不明并有较长的设计时间―――可以用演化模型。

而螺旋模型适于适合于大型软件开发，吸收了"演化"概念，不过有时也用于用户需求不明的情况下。

当然还有其他开发模型，没有在本文讨论。

名词定义：

瀑布模型：规定了各项软件工程活动。包括：制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及维护。

特点：自上而下，相互衔接的固定次序，如瀑布流水、逐级下落。

演化模型：第一次只是试验开发，其目标只在于探索可行性，弄清软件需求;第二次则在此基础上获得较为满意的软件产品，通常把一次得到的试验性产品称"原型"。

特点：减少由于软件需求不明确而给开发带来的风险。

螺旋模型：将瀑布模型及演化螺旋模型结合起来，并且加入被两种模型都忽略了的风险分析，弥补了两者的不足。

完成需求确认

对于需求最终的确认需求先由系统开发人员对编写的文档进行内部审核及修订，特别是文字问题。系统分析人员（在中国这些人员一般是物科专业人员）编写的文档文字语法上一般有一定问题。

内部审核后交由用户业务人员进行确认，明确系统开发人员已经了解业务需求，并进行签字确认。