软件开发需求分析报告

软件开发需求分析报告（精选6篇）

篇1：软件开发需求分析报告

软件需求分析

软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。

需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。近来，我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们开发完这个工具后，发现这个工具不能打印出源代码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。事实上，需求文档在开发过程中一直起指导作用。需求的类型

下面这些定义是需求工程领域中常见术语的定义。软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。1．业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。2．用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本说明中予以说明。3．功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反

映产品功能。多角度描述产品对用户和开发人员都极为重要。下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。

篇2：软件开发需求分析报告

1.1 编写目的：阐明编写需求说明书的目的，指明读者对象。1.2 项目背景：应包括

● 项目的委托单位、开心单位和主管部门；

● 该软件系统与其他系统的关系。

1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。

1.4 参考资料：可包括

● 项目经核准的计划任务书、合同或上级机关的批文

● 文档所引用的资料、规范等

● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源 2 任务概述 2.1 目标 2.2 运行环境 2.3 条件与限制 3 数据描述 3.1 表态数据

3.2 动态数据：包括输入数据和输出数据。3.3 数据库描述：给出使用数据库的名称和类型。3.4 数据词典 3.5 数据采集 4 功能需求 4.1功能划分 4.2功能描述 5 性能需求 5.1 数据精确度

5.2 时间特性：如响应时间、更新处理时间、数据转换与传输时间、运行时间等。

5.3 适应性：在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。6 运行需求

6.1 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。6.2 硬件接口 6.3 软件接口 6.4 故障处理 7 其他需求

如可使用性、安全保密、可维护性、可移植性等。

需求分析的格式 需求分析要对目标系统提出完整的、准确的、清晰的和具体的要求。

1．综合需求： 项目 说明 备注

1）功能要求 描述软件用来做什么

能够进行度量衡的相互转换，如：长度公制之间的转换，公制和英制的转换等。能够添加或创建新的度量衡。能够按照用户自己的需要进行排序。能够作为其他软件的插件或辅助工具使用。能够知道度量衡所应用的范围，如：国家，行业等。

2）性能要求 软件能达到什么性能

数据的最大存储量，数据的转换要有连续性，软件对每项操作的响应时间，更新处理时间，数据转换和传送时间，软件的输入输出数据精度，软件失败和成功的定义。

3）运行要求

软件能正常运行在微软中文版WINDOWS系列的可以独立运行的安装包或可执行文件

开发软件的开发工具清单。是否需要外部存储器和数据通信接口。

4）升级要求

是否可以升级，是否可以进行扩充。是否容易进行维护。能够作为什么软件的插件或辅助工具使用。如何添加新的公式

5）对应关系

用户需求和软件功能的对应关系 说明每一个模块对应实现什么功能。

2．数据要求： 项目 说明 备注

1）数据输入

来源、准确性、取值范围、格式、非法值的处理、出错信息

2）数据输出 目的地、准确性、数值范围、格式、非法值的处理、出错信息

输出的数据可以修改，如：1米=100厘米=1000毫米，将100厘米改为90厘米时，相应的1米就自动改为0.9米，1000毫米变为900毫米。

3）数据存储 最大存储量

4）数据的安全性 访问的权限

5）数据备份 能否导入和导出

可以将输出的数据保存为文本格式

6）数据流图

在分析过程中得出的数据流图

7）数据筛选

能够将选择的几个度量单位进行汇总

8）主要算法

简要描述软件的主要算法

3．界面要求：请参照“界面样式图” 项目 说明 备注

1）软件名称 为软件起一个名字 可以发挥自己的想象力

2）功能模块

有几个功能模块，分别是什么

3）颜色

采用什么底色，窗口是什么颜色

4）字体

字型、大小，字间距，颜色

5）按钮

颜色、字型、大小、样式

4．软件描述：从用户的角度来描述软件，相当于一份初步的用户手册。项目 说明 备注

1）功能描述

能实现，不能实现什么需求 应用范围。什么人员可以使用

2）性能描述

最低配置，操作系统，需要安装什么辅助软件

3）操作步骤 如何使用软件 主要步骤和方法

4）用户责任

用户在操作过程中的注意事项 出现问题时如何解决 如何写需求分析报告

近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下，写到这里。本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。

在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。所以还是看情况来对待文档的深度和标准。

一、目录： 目录要用word的 “引用”—>”目录”，自动生成目录，一般都是要三级目录。通常这部分基本都不需要改结构，直接更新页码即可。

二、内容部分。国家标准软件需求说明书G856T-88下载 1引言 1.1编写目的

说明编写这份软件需求说明书的目的，指出预期的读者。（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果）

1.2背景 说明：

a． 待开发的软件系统的名称； b． 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；

c． 该软件系统同其他系统或其他机构的基本的相互来往关系。

（这部分可以将a,b,c分为2部分，例子如下： 1.2.1项目概况

本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。1.2.2任务分配

a.任务提出者：xxx b.软件开发者：xx c.产品使用者：xx d.文档编写者：xx e.预期产品使用者：xx）1.3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

（这部分很简单，就是描述专业词汇，比如

1.XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。2.Word2, 解释。。）

1.4参考资料

列出用得着的参考资料，如：

a． 本项目的经核准的计划任务书或合同、上级机关的批文； b． 属于本项目的其他已发表的文件；

c． 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。2任务概述 2.1目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|（本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。具体描述：B1，来完成B11功能；B2，来完成B22功能； 等等。本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。图

图1.该系统的组成同其他各部分的联系和接口）

2.2用户的特点

列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束

（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。

xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。提供给这部分用户操作手册即可。预期这部分使用者主要是来简单的xx操作。

维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。这部分用户主要是采用了本系统之后的后期工作维护者。等等）

2.3假定和约束

列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。）3需求规定 3.1对功能的规定

用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。（例如： INPUT输入 PROCESS处理 OUTPUT输出 LOAD负载量

A 预处理,做怎样的动作，AA CC B BBBB Bb v C CCCC cc v

表

一、xx模块IPO表 对IPO表的简单文字描述。）

3.2对性能的规定 3.2.1精度

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。（例如：

Xx目标处理：1Byt–10M，包括左右边界值。yy精度范围：„.ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。）

3.2.2时间特性要求

说明对于该软件的时间特性要求，如对： a． 响应时间； b． 更新处理时间；

c． 数据的转换和传送时间； d． 解题时间；等的要求。(这部分只要一一列举就可以：

由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求，如下： a． xx响应时间：xxms左右； b． yy更新处理时间：yy；

c． zz数据的转换和传送时间：zz； d． vv解题时间：vv。等等)3.2.3灵活性

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a． 操作方式上的变化； b． 运行环境的变化；

c． 同其他软件的接口的变化； d． 精度和有效时限的变化； e． 计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

（这部分按列举来即可，由于本模块第一目的是用于xxx，其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时，该软件对这些变化的适应能力。具体情况如下： f． 操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。

g． 运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。；

h． 同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。但接口的命名规则是统一的；

i． 精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。

j． 计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。等等）3.3输人输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

（这部分可以把输入输出分为 3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。XXX输出

数据名称：XXX输出数据 实际含义：用于XX,表示XXXX 数据类型：Character(字符串)数据格式：XX 数据约束：由于xxx,，大小在xx以内）

3.4数据管理能力要求

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。（根据实际系统要求列举即可 Name名称 Number数量 Size大小 Increase增长

词典xx xx xxxx 并行执行，其大小依据实际xx大文本而增长）

3.5故障处理要求

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

（包括软件压力，内存不足，硬件损坏等，这部分可以根据百度到其常见故障。）3.6其他专门要求

如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

（例如安全保密性：密钥更换等； 预期扩展：扩展兼容等；OS更换：Slackware转SUSE等）

4运行环境规定 4.1设备

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：

a． 处理器型号及内存容量；

b． 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；

c． 输入及输出设备的型号和数量，联机或脱机； d． 数据通信设备的型号和数量； e． 功能键及其他专用硬件（列举说明即可）4.2支持软件

列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。（操作系统和版本：xxxx 支撑环境和版本：xxxx 备用IDE环境和版本：xxxx 与该软件有关的软件组件：xxxx 后续可能扩展环境：xxxx）4.3接口

说明该软件同其他软件之间的接口、数据通信协议等。(例如：

a．用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件，以xxxx方式调用函数。如下图2所示。图2.软件接口调用图 b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx)4.4控制

说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。(例如：

下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下： 图3.控制流程图

图3的具体说明情况如下表所示： Name模块名称 Method运行方式 Signal控制信号 Forward控制去向

主程序模块 运行框架 用户调用或运行 1.调用xx模块 2.调用xx方法 3.调用标准输出模块

篇3：软件开发的需求风险分析综述

在软件项目的开发过程中,项目风险几乎无处不在。如何有效地识别、控制和管理风险,对项目的成功起着至关重要的影响。本文在结合自己多年从事软件项目开发工作的基础上,针对需求分析引起的项目风险进行探讨总结,整理出其预防措施,期望以后软件项目风进行风险预防、控制等提供参考。

1 需求风险

在应用软件开发过程中,由于软件需求本身的隐含性、用户与开发者之间的沟通障碍,以及需求随着时间、用户的变化而变更等原因,可能使需求分析偏离实际需求而最终导致软件开发的失败,这种可能性称为需求风险。需求分析是软件开发过程中最初始、最基础的工作,也是最重要的工作之一,其成败将直接并最终决定软件开发的成败,并且呈倍增效应。因此,需求分析工作往往面临着一些潜在的风险,这些风险主要表现在:

(1)用户不能正确表达自身的需求。在实际开发过程中,常常碰到用户对自己真正的需求并不是十分明确的情况,他们认为计算机是万能的,只要简单地说说自己想干什么就是把需求说明白了,而对业务的规则、工作流程却不愿多谈。这种情况往往会增加需求分析工作难度,分析人员需要花费更多的时间和精力与用户交流,搞清用户的真实需求。

(2)业务人员配合力度不够。有的用户日常工作繁忙,他们不愿意付出更多的时间和精力向分析人员讲解业务,这样会加大分析人员的工作难度和工作量,也可能导致因业务需求不足而使系统无法使用。

(3)用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因,需求在项目的整个生命周期都可能发生变化。因此,软件开发的过程实际上是同变化做斗争的过程,需求变化是每个开发人员、项目管理人员都会遇到的问题,也是最头痛的问题。一旦发生了需求变化,就不得不修改设计、重写代码、修改测试用例、调整项目计划等等。

(4)需求的完整程度。需求如何做到没有遗漏,这是一个大问题,大的系统要想穷举需求几乎是不可能的,即使小的系统,新的需求也总会不时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来,这会导致开发人员在项目进展中去不断完善需求,造成返工的可能性很大,会给开发人员带来挫折感,降低他们完成项目的信心。

(5)需求的细化程度。虽然国家标准有需求说明的编写规范,但具体到某一个需求上,很难给出一个具体的指标,并没有定论。需求越细,周期越长,可能的变化越多,对设计的限制越严格,对需求的共性提取要求也越高。相反,需求越粗,开发人员在技术设计时不清楚的地方就越多,影响技术设计。

(6)需求描述的多义性。需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解;另一方面是指同一读者能用不同的方式来解释某个需求说明。多义性会使用户和开发人员等项目参与者产生不同的期望,也会使开发、测试人员为不同的理解而浪费时间,带来不可避免的后果便是返工重做。

(7)忽略了用户的特点分析。分析人员往往容易忽略了系统用户的特点,系统是由不同的人使用其不同的特性,使用频繁程度有所差异,使用者受教育程度和经验水平不尽相同。如果忽略这些的话,将会导致有的用户对产品感到失望。

(8)需求开发的时间保障。为了确保需求的正确性和完整性,项目负责人往往坚持要在需求阶段花费较多的时间。但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑,需求开发人员也会被需求的复杂和善变折腾的筋疲力尽,他们也希望尽快结束需求阶段。

2 需求风险控制

很多项目在确定需求时都面临着一些不确定性和混乱。当在项目早期容忍了这些不确定性,并且在项目进展过程当中得不到解决,这些问题就会对项目的成功造成很大威胁。

下面按需求工程中获取、分析、编写规格说明、验证和管理等阶段进行分析,推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。

2.1 需求调研

开发方通过走访、角色扮演、电话联络咨询、电子邮件、需求调查表等方式充分理解、挖掘各省用户的需求,尽可能覆盖所有用户的需求。

2.2 需求启发

由于许多省市还停留在手工建档阶段,电子档案不仅要移植手工廉政档案,而且要改革现有档案管理流程中的不合理成分,进行业务流程重组,采取的方式有座谈、需求启发问卷、设计需求用例等方法。

2.3 需求变更及控制

由于各省的廉政档案信息结构不尽相同,同一个省也随着时间的推移而不断变更。为了使软件满足不同省市、不同时期的需要,采用了灵活通用的数据结构,即将系统的数据结构设计成灵活可变的形式,真正做到“将变更交给用户,将实现留给自己”,具体做法如下所述。

2.3.1 标准模板

标准模板,即一套标准的功能、表格名称、数量、结构,及与此相关联的输入、处理、输出三大块,它包含了所有用户都需要的公共功能,供标准用户和公共用户使用;对于非标准用户,则成为自定义和修改的基础模板。这里的标准用户是指使用标准功能及数据结构的用户,如本省用户;非标准用户是指系统结构和功能与标准用户有出入的用户,如外省用户。

2.3.2 可变表格

表格名称、结构由用户自定义,用字段表示,保存于结构扩展表中,称为控制表。控制表的初始默认值为标准模板。用户可根据自身的需要在此基础上进行自定义,包括增加表格、定义其结构、修改现有表格的名称及结构等,从而满足不同用户的个性化需求。

2.3.3 系统的处理过程

由于数据结构的灵活定义,使得输入、处理、输出需随之变化。处理流程是:在初始化模块中进行数据结构定义;在输入模块中输入、编辑、修改、存储数据;在处理模块中对数据进行查询、分析、统计、汇总;在输出模块中将数据以所需要的格式进行屏幕输出或打印输出。由于系统的表格较多(标准模板中有24个),数据项较多(平均每个表格有15项左右),这些表都由公共键(人员编号)关联在一起,并且都以此为关键字段建立了索引,以便在处理过程中使用快速定位的功能。即先根据条件快速定位到相关记录,然后再实施相应操作(如修改某个人的某张表格)。

2.4 需求获取

(1)明确产品范围。项目成员要尽快对产品功能达成一个清晰的共识,在项目早期写一份项目视图与范围将业务需求涵盖在内,并将其作为新的需求及修改需求的指导。

(2)确定需求分析的时间。一般需求开发工作应占全部工作量的15%。分析人员在分析过程中应记录实际需求开发的工作量,以便改进将来项目的工作计划。

(3)需求规格说明的完整性和正确性。为确保需求是客户真正需要的,要以用户的任务为中心,使用实例技术获取需求。根据不同的使用情景编写需求测试用例,建立原型,使需求对用户来说更加直观,同时获取用户的反馈信息。

(4)明确非功能性需求。需求分析人员在分析过程中常注重产品的功能性要求,而容易忽略产品的非功能性的需求。因此应注意产品性能、使用性、完整性、可靠性等质量特性,并编写非功能需求文档和验收标准。

(5)避免需求二义性。如果不同的用户对产品有不同的意见,那最后必将使有些用户会不满意。因此应确定出主要的用户,并采用产品代表的方法来确保用户代表的积极参与,确保在需求决定权上有正确的人选。

(6)尽可能挖掘用户隐含的期望要求。未加说明的需求客户可能会有一些隐含的期望要求,要尽量识别并记录这些假设。在分析过程中应提出大量的问题来提示客户以充分表达他们的想法、主意和应关注的一切。

(7)产品升级的需求。对已有产品进行升级或重做的项目中,需求分析人员有时很有可能将已有的产品作为需求说明的来源,通过现有产品的逆向工程来获取需求。但是,逆向工程对收集需求是一种既不充分也不完整的方法。可能导致新系统会有一些与现有系统同样的缺陷。因此通过逆向工程中收集的需求编写的文档,必须通过用户评审来确保其正确性。

(8)给出期望的解决办法。在某些业务领域中,用户推荐的解决方法往往掩盖了用户的实际需求,导致业务处理的低效。因此分析人员应尽力从客户叙说的解决方法中提炼出其本质核心。

(9)建立良好的沟通渠道。项目建设之初就和项目各干系方约定好沟通的渠道和方式,项目建设过程中多和项目各干系方交流和沟通,注意培养和锻炼自身的沟通技巧。

2.5 需求分析

(1)划分需求优先级。划分出每项需求、特性或使用实例的优先级并安排在特定的产品版本或实现步骤中。评估每项新需求的优先级并与已有的工作主体相对比以做出相应的决策。

(2)特性分析。对每项需求进行可行性分析以确定是否能按计划实现,运用项目状态跟踪的办法来管理那些落后于计划安排的需求,尽早采取措施纠正。

(3)对于不熟悉的技术、方法、语言、工具或硬件平台,要明确那些高风险的需求并留出一段充裕时间,从错误中学习、实验及测试原型。

2.6 需求规格说明

(1)需求理解。开发人员和客户对需求的不同理解会带来彼此间的期望差异,将导致最终产品无法满足客户的要求。尽量使用需求模型和原型方法,从不同角度说明需求,这样可使一些模糊的需求变得清晰。

(2)规定具有二义性的术语。建立一本术语和数据字典,用于定义所有的业务和技术词汇,以防止它被不同的读者理解为不同的意思。特别是要说明清楚那些既有普通含义又有专用领域含义的词语。

(3)需求评审。仔细评审需求说明以确保它是在强调解决业务问题需要做什么,而不是在说怎么做。对需求文档进行正式评审的团队应包括开发人员、测试人员和客户。

2.7 需求验证

(1)在设计开始之前验证需求分析的正确性及其质量,将大大减少项目后期的返工现象。在项目计划中应为这些保证质量的活动预留时间并提供资源,尽早且通过非正式的评审逐渐到正式评审来找出其存在的问题。

(2)审查的有效性。如果评审人员不懂得怎样正确地评审需求文档和怎样做到有效评审,那么很可能会遗留一些严重的问题。故要对参与需求文档评审的所有团队成员进行培训,请组织内部有经验的评审专家或外界的咨询顾问来讲课、授教以使评审工作更加有效。

2.8 需求管理

(1)变更需求。将项目视图与范围文档作为变更的参照可以减少项目范围的无休止化。用户的积极参与和良好合作精神可把需求变更减少近一半。为了减少需求变更的影响,将那些易于变更的需求用多种方案实现,并在设计时更要注重其可修改性。

(2)需求变更约束。需求变更的风险来源于未曾明确的变更过程、无效变动机制、不按计划的过程来做出变更。预防这种需求变更风险的办法是项目建设之初就和用户书面约定好需求变更控制流程,记录并归档用户的需求变更申请。

2.9 功能的进一步完善

软件开发完成后,接到有关指示,要求廉政档案信息系统必须提供原件管理功能及廉政信息预警功能,这两项功能与廉政信息管理系统的接口比较简单,加上开发时留下了二次开发接口,两大功能采用了先开发再外挂的方式,实现了与原系统的无缝连接。

综上所述,控制廉政档案系统的需求变更,开发方采用了管理手段和技术手段,一方面通过挖掘用户的个性化需求使需求明确,另一方面通过灵活的表格及其结构定义、二次开发接口等技术手段来解决。此外,领域专家的全程参与(软件开发自如至终均有用户负责人参与),面向对象的开发工具也为其助了一臂之力。

3 结束语

需求分析的关键是使隐含的需求明确,使变更的需求可控,有效的沟通、需求调查表、需求启发、角色扮演等方法可以使需求明确化;采用面向对象的方法及UML工具、领域专家的全程参与、需求分级、二次开发接口等方法可以使需求变更处于可控范围内。实践证明,这些都是控制需求风险的有效方法。

在应用软件项目开发过程中,需求分析是最初始、最基础的,然而却是最重要的工作之一,其成功与否直接影响了软件开发的成败。由于需求的隐含性,以及需求的永恒变更等原因会导致需求难以凝固,需求风险时时存在。需求分析实质上是一种需求工程,包括需求开发和需求管理两部分,前者发现需求,后者使需求变更处于掌控之中。科学的需求分析应使需求明确、完整、一致、可测试、可跟踪、可修改,这就需要采取相应的方法和手段来实现。如面向对象的分析(OOA)方法,采用统一建模语言(UML)、领域专家的全程参与、需求分层、预留二次开发接口等都是降低需求风险的有效方法,它们使软件开发以最小的风险顺利进入下一阶段系统分析。

摘要：本文介绍了在软件项目开发过程中存在的需求风险以及需求风险的控制方法。

关键词：软件项目,需求分析,需求风险,需求变更

参考文献

[1]http://www.pubchina.com《软件需求与风险管理》.

[2]李师贤,张骆玲.需求分析常见问题及对策研究.

篇4：浅谈软件工程之软件需求分析

【关键词】软件工程 软件需求 需求工程 需求开发 需求管理

【中图分类号】TP311.5【文献标识码】A 【文章编号】2095-3089（2015）06-0181-02

软件工程师所需解决的问题往往十分复杂，了解问题的性质可能是非常困难的，尤其当系统是全新的时候。

1.综述

软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。本文以企业人事信息管理系统为例详细介绍了需求工程的构成和进行方法。

2.需求的标准

定義需求标准有所不同，但在思想上是相同的，都是为了保证项目的顺利进行。一般的标准为：明确（Clear）、完整（Complete）、一致（Consistent）、可测试（Testable），还有可跟踪、可修改等等。

明确：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性。所以对需求分析中采用的语言应该做某些限制尽量采用主语+动作的简单表达方式。还有，不要使用计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

完整：需求的完整性是非常非常重要的，要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。

一致：用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

可测试：需求的几项标准都是为了保证需求的可测试性，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。

需求工程分为了需求开发和需求管理两个阶段：下面就以这两个阶段说明：

3.需求开发

需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。

3.1需求获取：

这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动。

了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。

对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。

需求分析人员对收集到的用户需求做进一步的分析和整理。

需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。

3.2需求分析

需求分析是软件定义时期中很重要的一个阶段，它的基本任务是准确地回答“系统必须做什么？”这个问题。在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。

用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。

ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。

3.3编写规格说明书

项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。

采用软件需求规格说明模版：采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。

3.4需求验证

需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，要按以下步骤进行需求验证：

1）审查需求文档；2）依据需求编写测试用例；3）编写用户手册；4）确定合格的标准。

4.需求管理

需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。

5.企业人事管理系统

5.1企业人事管理系统概述

企业人事管理系统是针对企业人事方面的大量业务处理工作而开发的管理软件。根据用户的要求，实现人员基本情况管理、工资管理、和考勤管理等几个方面的功能。用户通过输入工资、考勤、职工履历等基本信息，由系统自行生成相应的统计数据及各类统计报表以供用户查询、打印。

5.2系统功能分析

系统开发的总体任务是实现企业人事信息关系的系统化、规范化和自动化。

系统功能分析是在系统开发的总体任务的基础上完成的。经过按照以上分析过程进行分析，分析出企业人事信息管理需要完成功能。

6.总结

以上详细介绍了软件需求分析过程。软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，要想做好一个项目，必须先做好需求分析，需求工程分为了需求开发和需求管理两个阶段：需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。需求管理就是对需求变更控制的过程。通过介绍企业人事信息管理系统的需求分析阶段，更好地说明了需求分析过程。

参考文献：

篇5：软件工程需求分析报告

本文中，主要针对工程机械出租的各项步骤、以及设计系统的广义意义进行了分析，从而根据各部分不同的需求阐明了本系统使各个功能模块相连接并实现工作、统计的作用。

1.1 编写目的

在计算机科技的飞速发展的21世纪，软件系统以及英特网也在不断融入我们的生活。然而在工程机械出租领域，设备的种类、数量越来越多，设备管理所涉及的是巨大的系统工程，由于企业出租规模大、管理涉及面广，又是造成统计、管理不到位都将给企业的正常经营带来一定的影响，所以如何利用先进的网络技术和优异的计算机软件系统更有效的收集、处理这些设备的租借，同时建立以现代信息化为核心的管理体制，减轻相关人员人工对租借管理及数据处理的负担，完成一个工程机械设备管理系统就变得尤为重要。

1、 信息交互要求

软件系统要求利用一一切租赁操作作为输入，通过数据收集计算达到处理的目的。

2、 附加影响要求

在系统正常工作过程中，需要达到最好的人际结合效果，对其他设备的正常工作不可以有太大的影响，设计人员需要根据用户的需要做出相应的调整;

3、功能的实现要求;

在满足客户的要求下，设计人员、开发人员需要根据本文参考相关需求程度，做出相应的软件系统设计。

1.2 项目来源

本设计的初步设想来源于宏达软件体验中心。宏达软件主要从事各行业的管理软件开发和应用推广，宏达体验中心拥有多支精干、稳定的软件技术开发队伍，这些队伍不仅具有一流的专业素质和研发能力，同时还拥有丰富的系统开发经验，且具有良好的职业道德修养和综合分析能力。 随着时代的发展，宏达公司也在不断开发、完善宏达系列软件，严把质量关，用一流的软件回报用户，受到了用户的好评，宏达系列管理软件以其功能强大、

操作简便、价格低廉的特性赢得了全国广大用户的青睐。目前用户已遍及全国所有省份、自治区、直辖市;用户遍及电子、电器、医药、服装、建筑、物资、化工、商贸、超市、旅游、机械、建材、科技、通讯等各类企业公司，同时拥有大量机关、事业单位、学校、研究所等机关事业型单位用户。

随着管理自动化的程度越来越高，大部分任务都直接由各种设备来完成，因此利用先进的计算机技术来管理，提高人机工作的效率成为了一项重要手段。

1.3项目风险

本项目中，不同身份的工作人员需要对各自负责的工作及出发点等承担一定的风险。

任务提出者需要对项目的完成进度以及设计需求的整体方向负责，产品是否为大众所接将成为任务提出者所要负担的风险。

软件开发者需要对统计、收集、计算的相关程序编码是否正确承担责任，对运行软件后的一切技术上的风险承担一定的风险。

产品使用者在完成交易过后的使用过程中，需要对自己的一切操作负责，相应的需要承担软件系统在使用过程中因操作不当崩溃的风险等。

1.4 文档约定

本文的正文部分以宋体、小四为主要格式，行间距为1.5倍行距，各个主要题头的格式为黑体、四号。

本文档所涉及的一些专业术语及英文缩写如下：

Acess: Microsoft Office Access(前名 Microsoft Access)是由微软发布的关联式数据库管理系统。它结合了 Microsoft Jet Database Engine 和 图形用户界面两项特点，是 Microsoft Office的成员之一。其实Access 也是微软公司另一个通讯程序的名字，想与 ProComm 以及其他类似程序来竞争。可是事后微软证实这是个失败计划，并且将它中止。数年后他们把名字重新命名于数据库软件。Access在的时候成为了计算机等级考试中的计算机二级的一种数据库语言并且因为它的易学易用的特点正逐步取代传统的VFP成为二级中最受欢迎的数据库语言。

Visual Foxpro：Visual FoxPro简称VFP，是Microsoft公司推出的数据库开发软件，用它来开发数据库，既简单又方便。Visual FoxPro源于美国Fox Software公司推出的数据库产品FoxBase，在DOS上运行，与xBase系列相容。FoxPro原来是FoxBase的加强版，最高版本曾出过2.6。之后，Fox Software被微软收购，加以发展， 使其可以在 Windows 上

运行， 并且更名为 Visual FoxPro。目前最新版为 Visual FoxPro 9.0，而在学校教学和教育部门考证中还依然延用经典版的 Visual FoxPro 6.0。在桌面型数据库应用中，处理速度极快，是日常工作中的得力助手。

数据：泛指表示一个指定的值或条件的数字、符号(或字母)等。数据是表示信息的，但这种表示要适合传输、分析和处理。此处，常把数据当作信息的同义词。

Container：Container类是IContainer 接口的默认实现。容器是封装和跟踪零个或更多个组件的对象。在此上下文中,包容是指逻辑包容,而不是直观包容。

数据源：提供某种所需数据的原始媒体。

C/S 结构：即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。

1.5 预期读者和阅读建议

本软件产品需求分析报告所针对的预期读者包括：

开发人员

用户

项目经理

租赁方

开发人员需要根据本文详细计划产品的开发，并且以达到最好的人机结合和为企业创造一定的经济效益为主要目的;用户需要熟知本文所描述的产品计划，以对产品有一定的了解，在之后的操作过程中才能有一定的熟练度，不以至于出现错误操作;项目经理则可以按照此文档安排项目进度以及工作经费等相关、租赁方需要对本文有一定的.了解，至少熟悉工作流程以及系统需要达到的目的，从而更好地配合出租厂商做好统计、记账、处理数据的相关方面的工作。

1.6产品范围

本产品适用于为工程项目出租机械设备的相关公司，由于大型施工设备租赁市场处于发展过程中存在着租赁企业数量多且规模小、效益差、恶性竞争严重等问题，本产品意在于协助每个工程机械设备出租公司合理地优化相关工作。

1.7 参考文献

2 产品分析

2.1产品的状况

工程机械设备管理系统提供了对基础信息录入、机械设备出车单录入、挖掘机回车单录入、员工登记录入、加油登记录入等的模式录入和表格界面录入。录入信息时可能会出现相同的信息，为了避免重复录入部分字段设置了辅助录入功能，只需输入几项即可完成录入功能，操作方便快捷，可以很大的提高工作效率。

本系统将不是产品系列中的下一成员，也同时还不是成熟产品所改进的下一代产品，但是现有应用软件却不能成为它的替代品(升级产品)，所以这是一个新型的、自主型的产品。

2.2 产品的功能

根据上述分析，可以将本系统的各项子系统功能陈列如下：

1.基础信息管理系统：

本系统主要负责储存、录入及读取相关资源，这些资源主要包括：机械设备档案、供商信息、客户信息等;

2.机械设备调度管理系统：

本系统主要负责统计工程机械出车单、以及对挖掘机的租赁做相关管理管理(挖掘机回车单、某机械设备期间统计、期间统计查询);

3.压路机管理系统：

本系统主要负责运行压路机回车单、某机械设备期间统计、期间统计查询及相关方面的工作。

4.装载机管理系统：

本系统主要对装载机回车单、某机械设备期间统计、期间统计查询做相关的程序的管理。

5.重型半挂管理系统：

本系统主要对装载机回车单、某机械设备期间统计、期间统计查询做相关的程序的管理。

6.客户管理系统：

本系统主要负责记录并统计、处理客户的还款、组织客户统计表、检查并记录机械设备状态等工作。

7.员工管理系统：

本系统提供一个员工信息服务系统，可以实现员工登记、事故登记、员工考勤、员工生日提醒。

8.加油管理系统：

本系统的作用在于加油登记、加油统计、余油统计;

9.配件管理系统：

本系统主要处理配件信息、配件入库、维护领料、配件库存、旧件回收、采购申请单、采购申请明细。

10.保养审验管理系统：

本系统的作用是对设备做保养登记、对设备审验进行登记、设备审验提醒、对保养期间查询等。

11.企业与产品检索系统：

本系统可以实现在线查询企业和产品信息，可以按多种方式进行查询;

12.在线调查系统：

本系统可以实现在线调查功能，对用户进行各种情况的调查。

2.3 用户类型和特性

本系统的用户主要由以下人员组成：

1、工程机械出租管理部人员：此类人员负责的是对公司内部机械设备出租，并对其出租明细做一个详细的录入，需要时可以读取相关信息。

2、机械设备保管部门人员：负责对公司内出租的工程机械设备做定期的管理与保养，并且负责设备的出纳。

编写本文档所参考的资料如下：

[1]《施工机械信息化管理的研究[J]科技情报开发与经济》王健.11

[2]《工程机械产品图库管理信息系统的研究[J]工程机械》贺尚红.5

[3]《开发新一代设备信息管理系统》龚元明1995.6

[4] 《数据库基础与应用[M]》 成先海..

篇6：软件项目需求分析总结

软件项目需求分析总结

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题： a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论 a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h)最后，需求分析报告一定要双方共同签字确认。