需求调研分析报告怎么写

需求调研怎么写

1. 如何进行需求调研

力，才能真正体现出软件的价值。

4.编写用户需求说明书

需求调研的步骤

需求分析员对收集到的所有需求信息进行分类整理，消除错误，归纳与总结共性的用户需求，然后形成文档，编写《用户需求说明书》。对于《用户需求说明书》要和客户以及相关的行业专家进行共同评审。以前整理的需求记录可以作为附件整理在《用户需求说明书》之后。

《用户需求说明书》与《产品需求规格说明书》的主要区别与联系是：

(1)前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。

(2)后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。

(3)两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。

需求调研的步骤

用户需求说明书的模板

需求调研中的注意事项

对每一次的调研形成正确的文档

需求调研中的注意事项

需求调研是一个漫长的过程。能够正确理解用户的需求，并且将用户的各种需求完整地体现在《软件需求规格说明书》中将更是一个复杂而艰辛的过程，因此在每一次的会谈之后必须将当天的会谈纪录形成文档，可以以备忘录的形式让用户进行确认。

需求调研后形成的文档文档必须是正确的，是经过验证的，是在受控的状态下变更的。而很多开发人员往往会问：“简单的系统就不用写需求了吧？”其实简单的系统未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了。

做好需求变更的控制

需求调研中的注意事项

对每一次的变更要双发进行确认，并进行版本控制，做到有据可依。

2. 需求分析怎么写

参考书《软件工程应用实践教程》清华大学出版社。

1需求获取

1。1用户的权利与义务

1。2制定调研计划

1。3准备调研的资料

1。4访谈用户

填写调研表（那本书里有很好的例子）

1。5编写调研报告

1。6需求的其他来源

2需求分析

3编写需求文档

比如数据流程，软件结构，数据字典等

4需求管理

3. 我们应当怎样做需求调研：初识

很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。

需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。

在一个阳光明媚的下午，项目经理带领着项目组成员，参加了客户组织的见面会，一个新的软件研发项目就这样开始了。双方在一种友好的气氛中进行，相互寒暄，介绍与会人员，拉拉家常。

逐渐地，会议开始进入了正题。初次接触客户，对于项目团队意义重大。

对方对你印象的好坏，今后如何与你交往，都在这个阶段被确定下来。然而，在客户至上的今天，与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。

为什么这么说呢？过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。

最后我们做得很累，结果却不能让客户满意。正确的做法是，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。

如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。

人与人交往，往往在接触的初期就决定了相互的行为方式，与客户交往也是一样。起初的唯唯诺诺，客户说啥就是啥，必然造成客户不再关注你的意见，对你发号施令就可以了。

相反，起初展现出一位技术专家的姿态，能大方而得体地提出自己的意见，会使客户重视你的意见，甚至主动征求你的意见。这一方面要求我们对自己要有足够的自信，另一方面也要有循循善诱的表达能力。

如果我们做到了这些，就会客户心目中形成一种威信，使项目向着一种良性的方向前进。同时，这样的会议又是一个项目启动会议。

客户方领导要在会议上传达给与会代表一个清晰的信号，那就是与会代表今后要积极配合我们完成今后的工作。这时候，我们要弄清，客户方有哪些角色，谁是这些角色的需求提出者与决策者。

这是什么意思呢？在软件项目中，特别是管理型软件项目中，客户都代表的是一个群体，而不是个人。他们代表的可能是一个单位、一个集团，甚至是一系列组织机构。

在这样一个群体中，他们按照职能被划分成了不同的角色。拿一个单位来说，横向可能划分成不同的部门，财务部、销售部、采购部、生产部。

4. 如何做需求分析

一、我们应当如何做需求分析需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。

这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。

只有这样才能及时纠正需求理解的偏差，保证项目的成功。二、我们应当怎样做需求调研1.初识。

我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。

这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。（1）高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析，应当与高层领导谈。

（2）中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节。

（3）基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。

但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。另外，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。

而他们关心的则是每项操作的细节。俗话说：万事开头难。

如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。

2.拜访。需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。

在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。

尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。3.研讨会。

（1）由于业务人员自身的局限，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；（2）集中式的业务研讨形式和分散式的业务研讨形式；（3）有效抑制个性化差异、分模块组织专项研讨会。

4.业务研讨在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：（1）由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。

（2）能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。这类客户，他们能熟练使用电脑，对信息化管理是清楚的。

他们提出的业务需求从整体上应当是八九不离十的。但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。

（3）能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。

但是他们提出的业务需求过于具体，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。解决办法：业务领域分析：客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？（1）我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。

（2）在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。（3）还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。

（4）需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。

5.迭。