软件项目需求调研总结

转载 2011年01月13日 17:27:00

一、需求调研准备:

在需求调研过程中,应该做好三种准备,保持两种心态,做到五种提高:

三种准备

1) 调研前应该将所有项目前期资料进行汇总,与相关的前期销售人员进行交流,以便对项目有一个基本轮廓的认识。

2) 做好调研前使用资料的准备,如需求调研模板,需求调研问题列表等。

3) 做好不怕一切困难的准备。

两种心态

1) 保持一种和客户平等合作的心态,确定需求调研是为了给客户解决问题,探讨问题,而不是接受问题,更不是来指导工作的。

2) 平静面对需求变更的心态,在需求调研过程中,往往双方对需求理解不一致,造成需求调研前后矛盾,应当心平气和的去引导客户,达到需求理解基本一致。

三种提高

1) 首先提高自己业务知识,对于人力资源的标准业务应该基本熟悉。

2) 其次应该努力的去熟悉用户的行业,学习用户使用的术语,标准,以便能够准确的理解用户。这就需要我们阅读用户所在行业的资料、文章,尽量多选取一些整体性介绍的文章,这样可以在短时间内能够对该行业有一个全面的认识,这样我们就能够较好的和用户进行交流了。

3) 需求调研中,学会尽量不使用IT行业的术语,而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语,以便用户能够很好的理解,提高自己的沟通交流能力。

4) 提高自己的速记能力,文字表述能力以及归纳,能迅速的记录需求调研核心的问题,总结归纳形成原始的需求调研资料。

5) 提高自己的总结能力,书写一份完整的、前后一致的、可追踪的需求报告。

二、需求调研过程的总体流程

需求调研中应遵循一定的流程,而且在调研过程中表现出规范,调研有条不紊,对客户有理有据,调研中资料做好备份,做到有备无患:




三、需求调研过程中注意问题

四、需求报告书写要求及标准

编写优秀的需求是没有公式化的方法的。这需要大量的经验,要从你在过去的文档中发现的问题学习。请在组织软件需求文档时,严格遵从这些方针。

句子和段落要简练。使用正确的语法,拼写,标点。使用术语,要保持一致性,并在术语表或数据字典中定义它们需求编写者还要努力正确地把握粒度。多个需求尽可能拆分开。

整个需求文档细节上要保持一致。

避免在需求报告中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读,但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新,避免不一致性。

需求调研对于系统的构造,系统测试以及最后的客户满意,都会成为好的奠基石。并且要记住,没有高质量的需求,软件就象一盒巧克力,你永远不知道你会得到什么。我希望我们能得到一块“德芙”。

 

调研概要情况:X项目需求调研开始于2006-3-23结束于2006-6-15,内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个开发骨干,编写需求规格说明书字数95.4万。

  1.把二期项目当作一个新项目来做调研,避免需求细节遗漏。在调研的初期我们曾经有过疑虑,这是一个二期的项目,那么调研的内容是否只针对二期的新需求,对需求内容二期和一期一致的部分就不必调研了?

  经过讨论我们还是决定把二期项目当作一个新项目来做调研,即使二期和一期需求内容一致,我们也在调研会上讨论,并记录在调研笔记及以后的需求文档上。这样的好处是最大限度地避免了需求细节的遗漏。在现场调研时,发现有不少地方原来以为是二期不必修改的,经过讨论后发现还是需要修改。(往往危险的需求描述就在于“这部分做的和某个系统或某个版本的旧系统一样就可以了”)

  2.调研团队参加所有子系统的调研会议,可以相互补充避免需求遗漏。这个项目规模比较大,根据业务的类型不同,分成了6个子系统,各个子系统的业务信息互有接口。我们安排每个人至少负责一个子系统的需求,但是在调研时,只要可能,我们都尽量让每个人都参与所有系统的调研会议。对项目经理和技术经理则进一步要求了解所有系统的业务需求。这样做的好处是,对于子系统之间的业务关系,调研团队都可以有全面的了解,对业务的理解比较透彻全面,并且还可以相互补充遗漏。

  3.多人调研,在会议后应该立刻回顾整理统一的会议笔记,消除歧义,避免遗漏。在开调研会时,全体与会人员都各自记自己的会议笔记,会后没有强调当天整理会议笔记(会议进度很紧,每天开会到晚上8、9点钟)。这导致以后阅读会议笔记发现一些描述很简单理解上有歧义的内容,或者同一份需求在几个笔记上记录的内容细节上有差异,事后难以追溯正确的信息。给编写需求文档带来了一些困难,需要再次讨论需求。

  4.需求文档编写完成后,在开发阶段也应该做检查和更新,避免文档错误对开发的误导。我们在完成大量的需求文档编写工作后,在开发阶段有部分文档没有做内容检查和及时更新。后期测试时才发现少数需求内容的矛盾和错误,导致需要重新修改。

  建议:
  1、如果在编写需求文档后,开发阶段应该做一边阅读需求文档,一边做需求文档的检查,对于保证需求质量效果会更好。

  2、应该指定人负责需求追踪和更新,在开发阶段、测试阶段要保持和用户的需求沟通,这不是一个可有可无的简单工作,很重要,并且会占用责任人50%的工作时间。

  3、企业业务管理信息系统的需求调研方法:我认为对调研的组织安排是非常重要的,好的调研安排虽然未必产生质量高的需求,但是一个不遵循调研规律的调研活动,必然是低效的。下面是H项目调研组采取的调研流程,供参考:

  4、第一步不是立刻和用户当面讨论需求细节,而是要业务关键用户编写初步的需求报告,提供给开发团队阅读分析。需求报告的内容是,对业务流程的描述,对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系,经常在没有面对面沟通时,关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础,一定要做,有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通,让用户编写。

相关文章推荐

ERP5.0项目管理需求调研说明书.pdf

  • 2013年03月27日 11:37
  • 332KB
  • 下载

项目管理——需求调研

  • 2008年12月12日 09:39
  • 50KB
  • 下载

要像管理咨询一样去做软件需求调研

有感于做软件的辛苦,特撰一文。       一般软件公司接到了软件实施案子,第一步是急吼吼的去做需求调研。首先集中要使用软件的一帮人在一起开座谈会,有使用部门的,有间接使用的部门,有计算机管理部门,...

项目需求调研计划

  • 2014年12月17日 12:30
  • 301KB
  • 下载

软件需求调研规范

  • 2017年11月09日 15:24
  • 430KB
  • 下载

DW项目需求调研方法论

1。总体思想 l         总结交流分析和用户进行充分的沟通、了解,包括项目背景、业务流程、系统用户、业务需求点等。 l         根据用户提供的各种信息,分析具体业务需求的价值...
  • Baple
  • Baple
  • 2011年10月25日 09:31
  • 709

管理信息系统需求调研分析指南-软件工程-www.knowsky.com

摘要: 本文是在治理信息系统需求调研实践和学习中的一些经验总结,有些是自己的体会,有些来自专家的书本或文章,希望与大家分享,并起到一个抛砖引玉的作用,如有不妥之处欢迎指正。 要害字:需求、调研 一...

电信运营商系统集成项目需求调研日志

最近正在负责一个套产品的实施工作,虽然我们的产品在功能上已经覆盖的相对比较完善了,但是在某些地方还是不能满足个别客户个性化的需求,因此得对这种具有个性化需求的客户展开额外的需求调研工作。我们的产品实施...

项目管理 之 关于需求调研这件事

需求调研是一个需求分析人员,或者一个项目经理都应该很熟悉的工作内容。 关于需求调研,很多人会出现两个极端。一个极端是,客户说什么就是什么,什么都行;另一个极端是,客户说什么都抵制,什么都说不行。...

从一次需求调研会议看项目经理的能力

本篇随笔说一说从一次需求调研会议看项目经理的能力,需求调研的内容是银行名单库系统的红、白、灰、黑名单定义、判断和处理规则、应用场景。但由于行内多个系统已经有名单库且各个系统的定义和应用场景不一,这些名...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:软件项目需求调研总结
举报原因:
原因补充:

(最多只允许输入30个字)