软件开发需求分析怎么做(20210309004357)

1、目录1 到用户前的准备 21.1 组织队伍 21.2 准备相应文档 21.3 联系及了解用户方 21.4 编写计划 32 需求调研 32.1 第一日 32.2 调研过程 32.3 三个阶段 43 一般情况下需明确的问题 44 需求完全明确情况 55 需求不完全明确情况 56 需求分析的方法 67 完成需求确认 88 误区 88.1 分析结果越复杂越好 88.2 必须一次到位 88.3 客户的需求必须全部满足 91 到用户前的准备1.1 组织队伍根据实际的工作量及其他情况，组建需求调研队伍，提供办分设备，明确 责任、启动任务。1.2 准备相应文档开发商方的系统分析人员同用户的需求提供人员正式接触

2、前，完成一个问 询表及需求分析计划。一般情况下只需要完成一个整体细节问询表，问询用户为明确需求已经完 成的文档情况（如果可以在进行正式接触前可以得到并了解完成最好） 、业务 目的、当前目标、长远目标、当前准备情况、完成的业务功能列表、将来系统 操作人员的业务及电脑技术了解情况、最终操作用户、当前及将来的硬件、软 件及网络环境等问题。由开发商系统分析人员根据对业务的了解程度，适当编写各业务功能细节 问询表。不过业务功能细节问询表的使用，是在业务需求调研过程中用户表明 其需求后，再根据问题还没有明确的情况下再进行问询的。其他业务相关政策法规、技术文档、技术支持人员的通信录等也要进行相 应的准备。1

3、.3 联系及了解用户方同用户进行联系并取得对方的人员名单、分工情况、权重、工作计划、工 作时间、节假日安排（特别是用户公司内部的额外规定） ，如果可能的情况下 要求也有用户的 IT 人员参加需求过程，实际的需求如果没有 IT 人员的参加， 在后面的更改一般是 IT 人员提出的。应在需求过程中把用户 IT 人员的需求调 研，作为业务调研中一部分。1.4 编写计划根据当前情况，编写需求分析计划，明确正式开始日期，中间阶段性日期 （时间段可多个，调研时间不大于 3 天），结束时间，人员名单，分工情况， 需用户提供的帮助等。将计划发送给用户请其确认，在可能的情况下协调用户和开发商的计划， 以便共同开展

4、工作。对于计划如果能编写及控制到每日是最好的，但是否可以达到真正可控制 到日，那就看你的能力了。如果每 3 天为一个中间性阶段进行控制，延迟的时 间可以通过加班来弥补。计划最好根据一天工作 8 小时进行。如果要去用户所在地进行工作，还要准备相应的办公工具，人手一台笔记 本电脑（电源插座及网络互连线也要考虑）是比较好的资源配置。2 需求调研2.1 第一日本次所说的第一日是开发商系统开发人员到用户处正式需求调研过程的第 一日。如果是异地调研，那么在第一日前一日开发商系统开发人员应到达用户 所在地，住宿，了解住宿地周边情况。最好是早些休息，为第一日工作开始做 好准备。一般第一日的上午是开发商系统分析

5、人员和用户业务需要者进行整体介绍， 了解办公环境，建立需求调研过程办公环境。如果是小型项目涉及人员不多 （双方人员共同不多于 3人），一般上午可以进行调研工作 1到 2小时，不然 下午才能正式开始工作（也就说做计划时第 1天一般只有半日的工作时间） 。2.2 调研过程调研的过程推荐开发商系统开发人员有专人进行会议记录，并在每日会议 结束后，当场宣布本次会议的结果，并由参加会议人员进行签字。第二日复印 或发送电子文件给参加会议人员及相关人员。以便做到有据可查，明确过程。开发商系统开发人员每周对用户提供开发周报，告诉用户当前开发的进展、 是否有问题、是否用户协助等，这是一个好的加强双方沟通的方法。

6、注意：在调研过程的中系统开发人员的变更会对计划产生重大的影响，不 要简单认为是人员更换的问题。因为在调研过程中对业务的理解，不是通过看 看文档就可以达到。 3 天通过讨论达到对需求理解的程序， 9 天对文档的学习也 不一定能达到。2.3 三个阶段分析的初期，即总体分析阶段，需要得到整体意义上的轮廓需求，此时， 应与客户方总工以上层次的人员进行交流，这一层次的人，对未来的系统会有 完整的描绘，可以划分出子系统、及其之间的关系，这也是高级管理层对系统 的期望。可以以此作为纲领性的文档指导进一步的分析，并约束后续的分析过 程，避免需求范围漫无边际的扩大；专业系统分析阶段，通常，客户单位都会有专业分工

7、，彼此之间既相互独 立，又会在某些点上发生联系。此阶段应与客户方专业人员进行深入的讨论。 这一层次的人，对自己的专业相当熟悉，对专业内的需求会非常到位，大都年 富力强，有相当的阅历和理解能力，甚至自己都可以绘制业务流图，总结业务 功能点。对他们应充分鼓励，尽量调动其积极性；系统关联分析阶段，在各专业系统得到充分分析的基础上，紧接着就要理 清它们之间的关系，这是提升需求档次的关键阶段，也是高级领导层和专业人 员都关心的阶段。通常，客户单位都会有一些零散的软件，如财务软件，部颁 软件等，这些专业软件都发挥着重要的作用，但都是些信息孤岛，客户会很自 然的希望能把这些信息融合到整个系统中来，为更多的人

8、所共享。同时，也希 望数据能够在各专业系统间顺畅的流动，从而减少重复劳动，提高工作效率。 此阶段应把总工层和专业人员召集到一起，共同理清系统间的接口。经过这三个阶段，对需求的描述将比较准确和完整。3 一般情况下需明确的问题当前整体业务需求的目的 要求提供的需求功能列表将来发展的设想 明确服务器、客户机的软、硬件及性能要求（容量、速度、可操作性等） 用户目前相关的技术人员和业务人员情况 将来最终系统操作人员的技术及业务人员情况 用户需求的系统及用户本身或其它系统的接口要求用户的其它要求4 需求完全明确情况对于整体调研过后就要进行各个具体业务需求的调研，对于具体需求调研 如果是用户提供的现有文档，

9、开发商的系统分析人员只是对业务进行了解及进 行修改为系统分析人员及业务人员全可以看懂的需求说明书，那么这个过程就 比较容易。只要系统分析人员把业务文档看懂看明白，并且对于一些难理解的业务描 述修改为易懂（有些业务名词有一定的专业性就要进行额外的说明） 、明确进 出的单据（数据项）就可以。当然编写需求说明书具体的细节可以参见其他的 众多的书籍及文件模版。5 需求不完全明确情况如果用户对于自己的需求在调研开始并没有完全明确，需要进行引导及细 化，那么这个过程就比较麻烦了。对于用户本身需求不明情况下，对于业务要先从基本业务进行细化，对于 不明业务或不确定业务在后面进行。对于进出的单据一般在这种情况下

10、用户当 没有现存文档，这个过程只需明确单据进出的必须数据源就可以，如果做到细 节，由用户在需求调研期确定单证，是不太可能的 只是设计单据的样式、风格就不是短时间可以完成的。对于报表也只能明确基本报表要求及数据项。 一般这种情况使用原型法进行，先做一个简单的，在简单的上面再进行完善。对于用户本身需求不明情况下的调研要做每日（或 2到3天,最多 3天为间 隔）的工作（分析进展）记录，由双方签字，因为调研过程会出现为用户要求添加一支新业务，对新业务进行分析后，因某些原因发现不能添加。这个过程 的结果是一个 0，但为证明是 0 这结果可能花了很长的时间。要记录这个过程， 说明调研过程中做了什么事情，有

11、时有些人可能会说为什么这么长时间才出这 点点东西，到时以便说明原因。6 需求分析的方法1. 绘制系统关联图，这种关联图是用于定义系统与系统外部实体间的界限和接 口的简单模型。同时它也明确了通过接口的信息流和物质流。2. 创建用户界面原型，当开发人员或用户不能确定需求时，开发一个用户界面 原型一个可能的局部实现，这样使得许多概念和可能发生的事更为直观 明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。3. 分析需求可行性，在允许的成本、性能要求下，分析每项需求实施的可行性， 明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的 依赖和技术障碍。4. 确定需求的优先

12、级别，应用分析方法来确定使用实例、产品特性或单项需求 实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。 当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中 作出需要的变更。5. 为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。 它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和 冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框 图、对象类及交互作用图。6. 依据分析阶段确定合适的客户方配合人员。7. 多方位描述同一需求 有一些需求贯穿了从基层人员到高层领导，对此需求应该从各个角度、 各个方位给以描述，总结

13、之后才能得到完整的表达，否则可能会漏掉一些 信息。这也为后续的设计工作打好基础。比如，在设备管理类软件中，有一个概念叫 缺陷 ，指由于材料老化或 外力作用，使得设备处于不正常的运行状态，但还没有到立刻就酿成 事故 的程度，但如不及时检修，就可能出事。对于设备缺陷业务，就涉及到从 班组人员到领导，上上下下对此都非常关心，但各层次的人关心的侧重点 却不尽相同：领导关心 消缺率（即缺陷消除率）、消缺及时率 ；专业人 员关心缺陷类型和处理方法；班组人员关心消缺工作的人员安排及时间地 点。缺陷的业务处理流程依赖于 设备缺陷单 （用于记录缺陷及消除情况） ， 如果仅仅局限于从由基层得到的设备缺陷单上的数据

14、结构（设备名称、缺 陷发现人、发现时间、二级单位确认时间、缺陷性质、安排消缺时间、消 缺人员、消除日期、处理方法） ，无法满足专业人员的分析要求：对设备 的缺陷情况按类型、零部件、型号、生产厂家等分类统计，为设备采购时 作为选型参考、调整设备及其零部件的检修周期以减少缺陷发生的频率等， 因此需要在原来的设备缺陷单上增加一些相关信息。8. 清晰化每一数据项 由于需求将作为设计的基础，弄清所有的数据项的来龙去脉对于设计 是必不可少的。不能有模糊不清的地方，同时通过对数据项来源的分析， 可以让分析人员更清楚的看到数据的流动情况，也会发现一些新的需求点。9. 充分挖掘潜在需求 由于分析人员对软件技术非

15、常熟悉，一些由于技术所带来的潜在需求 对于客户来说，一般很难被发现。不实现这些需求，对整个系统也没什么 实质性的影响；实现这些需求，则会锦上添花。对这些潜在需求，会有两种处理方式：告诉客户，客户会得到启发， 可能进一步提出新的需求，会有一些更大胆的想法，从而扩大了需求范围， 增加了工作量，甚至会影响到工期；不告诉客户，等客户想到了再说。这些需求如果对于产品软件，可能会是一个卖点，要尽可能的去挖掘。 但对项目软件，考虑各种风险，有时候可能会回避，或对客户隐瞒。10. 积累领域知识领域知识对于分析人员很重要，这些知识的广度和深度影响分析结果的准确性和分析进度。分析人员应该通过各种途径去获取这些，不

16、断积累，并进行比较和总结。11. 抱着学习与指导并存的态度面对一个新的客户时，分析人员首先必须抱着谦逊的学习的态度，把 这看成是丰富领域知识的机会。但并非客户单位的任何层次的人都有值得 学习的东西，随着分析人员接触的领域客户不断增多，分析人员对该领域 的理解也会越来越深，逐渐会成长为领域专家，会有很多地方超过客户对 领域的理解，此时，要以自己的深入理解去指导客户，说服客户，甚至纠 正客户的一些错误的认识，得到客户的信任与尊敬，这对迅速顺利的完成 需求分析会很有帮助。7 完成需求确认对于需求最终的确认需求先由系统开发人员对编写的文档进行内部审核及 修订，然后交由用户业务人员进行确认，明确系统开发

17、人员已经了解业务需求， 并进行签字确认。8 误区在进行需求分析的时候，容易陷入一些误区，导致分析结果不理想。8.1 分析结果越复杂越好这是技术型分析人员经常碰到的情况，认为分析出错综复杂的关系，花哨 的图表才能显示出分析水平高。其实，分析经常要经历 简单-复杂 -简单的过程， 前一个简单表现为分析人员 认为简单 ；随着分析的深入，原以为简单的问题 会越来越复杂；最后，经过概括、消化、分解，使得需求简单明了。8.2 必须一次到位由于项目工期紧，或者客户单位地理位置偏远，不想反复去现场，希望通 过一次需求分析就能得到完整的、不再改变的结果。有这种情况时，表现为分 析人员对客户方配合人员穷追猛问，或坚持要求配合人员做出保证，承诺需求 范围不再扩大等等。结果往往是双方关系紧张，配合人员怕担责任，提出过多 的灵活的、可配置的一些要求，无端增加了后续设计和编码的工作量。一次到 位的想法是不现实的，随着开发工作的进行，用户经常会提出以前没想到的需 求，或者更改已有的需求。需求必然有一个迭代的过程，变是不可避免的，关 键是对于变