软件需求分析具体实操流程
本文来源：www.sunseam.com 发布日期：2014-11-09
1 到用户前的准备
1.1 组织队伍
根据实际的工作量及其他情况，组建需求调研队伍，提供办分设备，明确责任、启动任务。1.2准备相应文档
开发商方的系统分析人员同用户的需求提供人员正式接触前，完成一个问询表及需求分析计划。一般情况下只需要完成一个整体细节问询表，问询用户为明确需求已经完成的文档情况（如果可以在进行正式接触前可以得到并了解完成最好）、业务目的、当前目标、长远目标、当前准备情况、完成的业务功能列表、将来系统操作人员的业务及电脑技术了解情况、最终操作用户、当前及将来的硬件、软件及网络环境等问题。
由开发商系统分析人员根据对业务的了解程度，适当编写各业务功能细节问询表。不过业务功能细节问询表的使用，是在业务需求调研过程中用户表明其需求后，再根据问题还没有明确的情况下再进行问询的。
其他业务相关政策法规、技术文档、技术支持人员的通信录等也要进行相应的准备。
1.3 联系及了解用户方
同用户进行联系并取得对方的人员名单、分工情况、权重、工作计划、工作时间、节假日安排（特别是用户公司内部的额外规定），如果可能的情况下要求也有用户的IT人员参加需求过程，实际的需求如果没有IT人员的参加，在后面的更改一般是IT人员提出的。应在需求过程中把用户IT人员的需求调研，作为业务调研中一部分。1.4 编写计划
根据当前情况，编写需求分析计划，明确正式开始日期，中间阶段性日期（时间段可多个，调研时间不大于3天），结束时间，人员名单，分工情况，需用户提供的帮助等。将计划发送给用户请其确认，在可能的情况下协调用户和开发商的计划，以便共同开展工作。
对于计划如果能编写及控制到每日是最好的，但是否可以达到真正可控制到日，那就看你的能力了。如果每3天为一个中间性阶段进行控制，延迟的时间可以通过加班来弥补。计划最好根据一天工作8小时进行。
如果要去用户所在地进行工作，还要准备相应的办公工具，人手一台笔记本电脑（电源插座及网络互连线也要考虑）是比较好的资源配置。
2 需求调研
2.1 第一日
本次所说的第一日是开发商系统开发人员到用户处正式需求调研过程的第一日。如果是异地调研，那么在第一日前一日开发商系统开发人员应到达用户所在地，住宿，了解住宿地周边情况。最好是早些休息，为第一日工作开始做好准备。一般第一日的上午是开发商系统分析人员和用户业务需要者进行整体介绍，了解办公环境，建立需求调研过程办公环境。如果是小型项目涉及人员不多（双方人员共同不多于3人），一般上午可以进行调研工作1到2小时，不然下午才能正式开始工作（也就说做计划时第1天一般只有半日的工作时间）。
2.2 调研过程
调研的过程推荐开发商系统开发人员有专人进行会议记录，并在每日会议结束后，当场宣布本次会议的结果，并由参加会议人员进行签字。第二日复印或发送电子文件给参加会议人员及相关人员。以便做到有据可查，明确过程。开发商系统开发人员每周对用户提供开发周报，告诉用户当前开发的进展、是否有问题、是否用户协助等，这是一个好的加强双方沟通的方法。
注意：在调研过程的中系统开发人员的变更会对计划产生重大的影响，不要简单认为是人员更换的问题。因为在调研过程中对业务的理解，不是通过看看文档就可以达到。3天通过讨论达到对需求理解的程序，9天对文档的学习也不一定能达到。
2.3 三个阶段
分析的初期，即总体分析阶段，需要得到整体意义上的轮廓需求，此时，应与客户方总工以上层次的人员进行交流，这一层次的人，对未来的系统会有完整的描绘，可以划分出子系统、及其之间的关系，这也是高级管理层对系统的期望。可以以此作为纲领性的文档指导进一步的分析，并约束后续的分析过程，避免需求范围漫无边际的扩大；专业系统分析阶段，通常，客户单位都会有专业分工，彼此之间既相互独立，又会在某些点上发生联系。此阶段应与客户方专业人员进行深入的讨论。这一层次的人，对自己的专业相当熟悉，对专业内的需求会非常到位，大都年富力强，有相当的阅历和理解能力，甚至自己都可以绘制业务流图，总结业务功能点。对他们应充分鼓励，尽量调动其积极性；
系统关联分析阶段，在各专业系统得到充分分析的基础上，紧接着就要理清它们之间的关系，这是提升需求档次的关键阶段，也是高级领导层和专业人员都关心的阶段。通常，客户单位都会有一些零散的软件，如财务软件，部颁软件等，这些专业软件都发挥着重要的作用，但都是些信息孤岛，客户会很自然的希望能把这些信息融合到整个系统中来，为更多的人所共享。同时，也希望数据能够在各专业系统间顺畅的流动，从而减少重复劳动，提高工作效率。此阶段应把总工层和专业人员召集到一起，共同理清系统间的接口。
经过这三个阶段，对需求的描述将比较准确和完整。
3 一般情况下需明确的问题
当前整体业务需求的目的要求提供的需求功能列表
将来发展的设想
明确服务器、客户机的软、硬件及性能要求（容量、速度、可操作性等）
用户目前相关的技术人员和业务人员情况
将来最终系统操作人员的技术及业务人员情况
用户需求的系统及用户本身或其它系统的接口要求
用户的其它要求
4 需求完全明确情况
对于整体调研过后就要进行各个具体业务需求的调研，对于具体需求调研如果是用户提供的现有文档，开发商的系统分析人员只是对业务进行了解及进行修改为系统分析人员及业务人员全可以看懂的需求说明书，那么这个过程就比较容易。只要系统分析人员把业务文档看懂看明白，并且对于一些难理解的业务描述修改为易懂（有些业务名词有一定的专业性就要进行额外的说明）、明确进出的单据（数据项）就可以。当然编写需求说明书具体的细节可以参见其他的众多的书籍及文件模版。
5 需求不完全明确情况
如果用户对于自己的需求在调研开始并没有完全明确，需要进行引导及细化，那么这个过程就比较麻烦了。对于用户本身需求不明情况下，对于业务要先从基本业务进行细化，对于不明业务或不确定业务在后面进行。对于进出的单据一般在这种情况下用户当没有现存文档，这个过程只需明确单据进出的必须数据源就可以，如果做到细节，由用户在需求调研期确定单证，是不太可能的----只是设计单据的样式、风格就不是短时间可以完成的。对于报表也只能明确基本报表要求及数据项。一般这种情况使用原型法进行，先做一个简单的，在简单的上面再进行完善。
对于用户本身需求不明情况下的调研要做每日（或2到3天,最多3天为间隔）的工作（分析进展）记录，由双方签字，因为调研过程会出现为用户要求添加一支新业务，对新业务进行分析后，因某些原因发现不能添加。这个过程的结果是一个0，但为证明是0这结果可能花了很长的时间。要记录这个过程，说明调研过程中做了什么事情，有时有些人可能会说为什么这么长时间才出这点点东西，到时以便说明原因。
6 需求分析的方法
- 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。
- 创建用户界面原型，当开发人员或用户不能确定需求时，开发一个用户界面原型——一个可能的局部实现，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
- 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
- 确定需求的优先级别，应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
- 为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
- 依据分析阶段确定合适的客户方配合人员。
- 多方位描述同一需求
比如，在设备管理类软件中，有一个概念叫"缺陷"，指由于材料老化或外力作用，使得设备处于不正常的运行状态，但还没有到立刻就酿成"事故"的程度，但如不及时检修，就可能出事。对于设备缺陷业务，就涉及到从班组人员到领导，上上下下对此都非常关心，但各层次的人关心的侧重点却不尽相同：领导关心"消缺率"（即缺陷消除率）、"消缺及时率"；专业人员关心缺陷类型和处理方法；班组人员关心消缺工作的人员安排及时间地点。缺陷的业务处理流程依赖于"设备缺陷单"（用于记录缺陷及消除情况），如果仅仅局限于从由基层得到的设备缺陷单上的数据结构（设备名称、缺陷发现人、发现时间、二级单位确认时间、缺陷性质、安排消缺时间、消缺人员、消除日期、处理方法），无法满足专业人员的分析要求：对设备的缺陷情况按类型、零部件、型号、生产厂家等分类统计，为设备采购时作为选型参考、调整设备及其零部件的检修周期以减少缺陷发生的频率等，因此需要在原来的设备缺陷单上增加一些相关信息。
- 清晰化每一数据项
- 充分挖掘潜在需求
对这些潜在需求，会有两种处理方式：告诉客户，客户会得到启发，可能进一步提出新的需求，会有一些更大胆的想法，从而扩大了需求范围，增加了工作量，甚至会影响到工期；不告诉客户，等客户想到了再说。
这些需求如果对于产品软件，可能会是一个卖点，要尽可能的去挖掘。但对项目软件，考虑各种风险，有时候可能会回避，或对客户隐瞒。
- 积累领域知识
- 抱着学习与指导并存的态度