软件开发需求分析怎么做

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

1到用户前的准备 (2)

1.1组织队伍 (2)

1.2准备相应文档 (2)

1.3联系及了解用户方 (2)

1.4编写计划 (3)

2需求调研 (3)

2.1第一日 (3)

2.2调研过程 (3)

2.3三个阶段 (4)

3 一般情况下需明确的问题 (4)

4需求完全明确情况 (5)

5需求不完全明确情况 (5)

6需求分析的方法 (6)

7完成需求确认 (8)

8误区 (8)

8.1分析结果越复杂越好 (8)

8.2必须一次到位 (8)

8.3客户的需求必须全部满足 (9)

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这结果可能花了很长的时间。要记录这个过程,说明调研过程中做了什么事情,有时有些人可能会说为什么这么长时间才出这点点东西,到时以

相关文档
最新文档