软件项目需求调查研究报告材料-实用模板.doc

. .
[XXXX]技术XX[公司名称]

[XXXX]公司[客户名称]
[XXXX]软件工程[工程或产品名称]
需求调研报告

文件信息

文件状态：
[ √ ] 草稿文件
[ ] 正式文件
[ ] 更改正式文件
当前版本：
V1.0.0

完成日期：

文档编号：

文档标题：
软件工程需求调研报告
文档类别：

提交人员：

文件名：

文件摘要：

工程名称：

当前阶段：
需求调研阶段
所有：

. .word.zl.
. .
修改历史
日期
版本
作者
修改容
评审号
更改请求号
2021 -06-29
V1.0.0
虎
定义文件模板

. .word.zl.
. .
目录
文件信息1
修改历史2
目录2
一、引言2
1.1、编写目的2
1.2、文档围2
1.3、预期读者和阅读建议2
1.4、参考资料2
二、工程描述2
2.1、工程背景2
2.2、工程名称2
2.3、工程概述2
2.4、工程关联性2
2.5、设计和实现上的限制2
2.6、假定和约束2
2.7、名词/术语解释2
三、用户环境描述2
3.1、用户单位组织构造2
3.2、用户部门设置与职责2
3.3、用户业务关系描述2
3.4、系统面向的用户群2
3.5、关键计算机资源2
3.6、用户环境中的其他应用系统分布2
四、功能性需求描述2
4.1、用户各部门当前的工作模式2
4.2、构建该系统的目标2
4.3、功能构造图2
4.4、功能点需求2
4.5、接口需求2
五、非功能性需求描述2
5.1、系统环境需求2
5.2、易用性和用户体验需求2
5.3、软硬件技术需求2
5.4、平安性需求2
5.5、可维护性需求2
5.6、对培训的需求2
六、其他2
6.1、软件应当遵循的标准或规2
6.2、定义、首字母缩写词和缩略语2
6.3、附件2

. .word.zl.
. .
一、 引言
1.1、 编写目的
编写提示：说明编写该文档的目的；本节容是读者接触到本文的第一段正式文字，建议通过简短文字描述简明扼要的告诉他们编写本文档的目标。
例如：
1、 本文档是 [工程名称] [系统属性] 客户需求调研报告，供需求分析人员进展工程需求分析时使用；
2、 本文档可以作为工程验收标准之一；
3、 本文档可以作为软件维护的参考资料；

1.2、 文档围
编写提示：对本文当所涉及到所有容的高度概括，简要说明即可。
例如：
1、 本文档包括 [工程描述]、[用户环境描述]…等几个章节，并：
a) 在 [工程描述] 章节中描述了…信息；
b) 在 [用户环境描述] 章节中描述了…信息；
c) …

1.3、 预期读者和阅读建议
编写提示：描述本文档可能涉及到的各类读者对象以及不同的读者应该注意的侧重点；

1.4、 参考资料
编写提示：列出本文档的所有参考文献〔可以是非正式出版物、客户的规章制度和流程文件、相关法律法规文件等〕，格式如下：
名称
日期
作者
版本

并且，请在本文档最后附上所有列出的参考资料的附件。

二、 工程描述
2.1、 工程背景
编写建议：描述该工程的建立背景；
例如：
1、 工程立项时的环境描述；
2、 工程立项的政策性支持；
3、 工程需求提出的初衷目的等。

2.2、 工程名称
编写建议：描述该工程的名称，格式为：[客户名称]-[软件名称]。
例如：
XX集团信息通讯分公司-调运检一体化智能联动管理平台

2.3、 工程概述
编写建议：描述该工程的概要情况。应包括如下信息：
1、 工程的委托单位；
2、 工程主要功能或解决问题描述；
可以用列举式进展描述，例如：
1、 工程委托单位：[单位名称]；
2、 比较委托单位原有系统与完整系统构造进展比照等，或进展详细的系统构造概述；
3、 针对工程的特色功能进展根本描述；
4、 …

2.4、 工程关联性
编写建议：描述该工程与其他相关事物的关联性。应包括如下信息：
1、 与其他现有软件系统的关联性；
2、 对现有客户环境〔IT环境、管理措施等〕造成的影响；
3、 对以后可能建立的其他系统造成的长期影响；
4、 其他认为应该包括的信息…

2.5、 设计和实现上的限制
编写建议：描述该工程的需求调研和分析、设计以及开发实现过程中可能会遇到的技术性限制；
例如：
1、 软件实现技术上的要求；
2、 与其他关联系统的对接要求；
3、 预留接口或扩展性的要求；
4、 其他认为应该包括的信息…

2.6、 假定条件和约束
编写建议：描述该工程的需求调研和分析、设计以及开发过程中可能会遇到的非技术性条件和限制，例如：
假定性条件：
1、对目标用户文化程度和计算机操作水平、财务知识水平等面的假设；
限制性条件：
1、 工程建立时间上的要求；
2、 团队人员或人资条件上的限制和要求；
3、 其他认为应该包括的信息…

2.7、 名词/术语解释
编写建议：列出本文档所涉及到的关于客户需求领域的行业或专业技术特有的(专用)名次/和术语并给出符合实际情况的解释说明；编写格式如下：
中文全称
中文简称
英文全称
英文简称
解释说明

三、 用户环境描述
3.1、 用户单位组织构造
编写信息：利用表格或框图(建议)形式画出委托单位的组织构造图；应包括委托单位的所有分支构造和部门名称，以及各个分支机构/部门间的上下级关系。

3.2、 用户部门设置与职责
编写建议：按业务组织构造划分成不同的职责部门或分支机构，分别对每个部门或分支机构进展描述。描述的容包括：
1、 用户组、分支构造或部门的名称
2、 每个用户组、分支构造或部门的描述，主要描述他们的职责，及用户组或分支构造/部门的考核指标；
3、 每个用户组、分支构造或部门相关人员的职责，及考核指标。
[可以使用下面的格式，也可以根据实际的需要使用其他格式]
例如：
用户组/机构/部门名称
职责描述
考核指标
备注

3.3、 用户业务关系描述
编写建议：以关系图的式加文字说明的式，描述该软件系统所方案完成的系统业务，以及该业务在部的工作流情况，还有该业务的相关部门的接口情况。注意本图示需要说明业务关联关系而非数据关联关系。

3.4、 系统面向的用户群
编写建议：描述该系统建立以后的目标用户群体以及他们的专业知识水平〔例如计算机操作能力、财务知识水平等〕、各类用户的主要使用容和工作职责等。

3.5、 关键计算机资源
编写建议：列出该软件所涉及到的所有部门和机房的软硬件资源情况、设备要求等；

3.6、 用户环境中的其他应用系统分布
编写建议：列出该软件所涉及到的用户环境中的其他所有应用系统的分布情况；应该包括：
1、 其他应用系统的名称；
2、 责任部门；
3、 应用系统功能概述；
4、 部署的效劳器以及机房；
5、 其他认为应该包括的信息…

四、 功能性需求描述
4.1、 用户各部门当前的工作模式
编写建议：该章节描述调研过程中发现的，客户业务实际的操作情况，建议以表格、流程图等形式进展说明。并且按照如以下出的格式分部门分层面进展描述：

4.1.1、 部门一[部门名称]
4.1.1.1、 工作容
编写建议：描述该部门之前〔未用软件进展工作管理〕的主要工作容和工作职责。

4.1.1.2、 工作流程
编写建议：描述该部门相关工作的处理流程，建议以流程图形式进展描述；

4.1.1.3、 涉及到的表单
编写建议：描述该部门各项工作处理过程中，可能涉及到的各种单据，描述的容应包含如下信息：
1、 每项单据的名称和用途；
2、 单据流转的流程；
3、 单据牵涉到的相关人员；
4、 单据的标准填写格式。
建议提供相关单据的附件。

4.1.1.4、 与其他部门的关系
编写建议：描述该部门各项工作在执行处理过程中可能会牵涉到的其他部门，以及其他部门的处理容；

4.1.1.5、 存在的问题
编写建议：描述该部门各项工作之前执行过程中存在的各项问题；以及为什么要用软件管理的式来体改之前的执行操作式。

4.1.2、 部门二
[参考部门一]

4.1.3、 部门N…
[参考部门一]

4.2、 构建该系统的目标
编写建议：介绍本软件系统的建立目的，从用户的角度描述该系统建立后应该到达的预期目标。可以从以下几个面进展描述：

4.1.4、 管理目标
编写建议：描述客户领导层/管理层对本软件系统的建立要求：
例如：
1、 客户希望该系统建立后能在管理上、业务流程上规解决的问题；
2、 希望能够通过该软件系统到达什么样的使用效果和目标；
3、 系统该软件系统能出什么报表数据，或者用该软件系统能提高哪些工作效率等等；

4.1.5、 使用目标
编写建议：对具体业务上来说，客户系统通过该系统能够实际解决的问题。该容的编写应参考具体每个使用部门的意见。

4.1.6、 业绩目标
编写建议：描述该软件系统上线应用前方案实现的业绩目标：
例如：
1、 减少多少行政办公时间工作时的计算；
2、 减少多少办公耗材资源的计算；
3、 对行政效率提升的具体计算；
4、 对数据统计效率提升的具体计算；
5、 对产能提高的具体计算；
6、 其他…

4.3、 功能构造图
编写建议：描述软件系统中各个模块以及模块下功能/子模块的划分；整体展示系统中所具备的功能模块，以及各个模块之间的关联情况。建议以构造图的形式进展描述；
该功能构造图仅描述客户对功能模块的意向需求，而不是根据客户需求分析后的功能模块设计。

4.4、 功能点需求
编写建议：该章节描述调研过程中发现的，客户对软件具体功能点的要求，建议以表格、流程图加文字的形式进展说明，按照不同的功能点进展列举式描述。格式建议如下：

4.4.1、 功能点一
4.4.1.1、 业务描述
编写建议：描述该功能点实际处理的业务情况，以及在这个业务中应该注意的细节、要点,以及工作目标等等。

4.4.1.2、 用例及关键数据
编写建议：以用例图加文字说明的形式，呈现该业务所有参与者及其用例的执行过程，以及他们之间的关系，还应该包括每个用例所涉及处理的数据以及所涉及到的单据。

4.4.1.3、 业务流程图
编写建议：以流程图加文字说明的形式，描述该功能点的业务流程，明确各个业务流程的节点，对象和容。

4.4.1.4、 与其他功能点的关系
编写建议：描述该功能点与其他功能点的关系，例如需要从其他功能模块调去数据，根据其他功能点的执行构造进展条件判断处理等等。

4.4.1.5、 子功能点
编写建议：描述该功能点可能存在的子功能点，以便对整体功能进展更加明确的划分；格式直接参照上面的四项容即可。

4.4.2、 功能点二
[参考功能点一]

4.4.3、 功能点N…
[参考功能点一]

4.5、 接口需求
编写建议：描述该软件所涉及到的部接口和外部接口需求。

4.5.1、 部接口需求
编写建议：描述各个模块或者功能点之间的业务接口，可以采用图表加文字的式进展展示；每个接口间列出详细的接口要素及其说明。

4.5.2、 外部接口需求
编写建议：描述该软件系统与其他软件系统之间的业务接口，可以采用图表加文字的式进展展示；每个接口间列出详细的接口要素及其说明，并且对具体的调用式进展描述。

五、 非功能性需求描述
5.1、 系统环境需求
编写建议：描述客户对软件系统的系统环境需求，即客户要求在什么样的环境下使用该系统；包括网络环境、人员环境、使用频率和期等等。

5.2、 易用性和用户体验需求
编写建议：描述客户对软件系统在易用性和用户体验面的需求，例如客户对界面布局的要求，对软件各项表单操作提醒的要求、对帮助文档的要求等等。

5.3、 软硬件技术需求
编写建议：描述客户对该软件系统开发和部署面的软硬件环境和技术的要求：
例如：
1、 软件开发过程中使用到的开发语言、根底框架等；
2、 软件开发和部署的操作系统、WEB 浏览器等面的要求；
3、 软件部署的硬件效劳器的性能配置要求等；
4、 其他认为应该包含的信息…

5.4、 平安性需求
编写建议：描述客户对该软件在平安面的要求；
例如：
1、 数据库平安性；
2、 备份和容灾策略；
3、 数据出错时的回滚机制；
4、 系统平安性；
5、 密码平安性；
6、 防止XSS和SQL注入攻击等；
7、 其他认为应该包含的信息…

5.5、 可维护性需求
编写建议：描述客户或者我维护人员对该软件系统在可维护性面的需求。
例如：
1、 远程维护的需求；
2、 备份的需求；
3、 对系统维护的要求〔对管理人员专业水平的要求〕等；
4、 其他认为应该包含的信息…

5.6、 对培训的需求
编写建议：描述客户和我实施/售后人员对该软件系统在培训面的需求。
例如：
1、 对客户领导的培训；
2、 对客户管理人员/系统管理员的培训；
3、 对客户普通操作人员的培训；
4、 对我技术实施和售后人员的培训；
5、 其他认为应该包含的信息…

六、 其他
6.1、 软件应当遵循的标准或规
编写建议：列出本软件在需求调研和分析、设计以及开发等过程中应当遵循的各项规。
例如：
1、 本软件所涉及到的行业在该软件所涉及到的业务领域的相关行业执行标准；
2、 在该软件所涉及到的业务领域的相关法律法规和执行标准；
3、 客户自身对于软件所涉及到的业务领域的管理制度和错误以及相关标准；
4、 其他同类型软件产品的相关规和定义；
5、 本次软件研发所应该遵循的标准/规/要求等等；
6、 其他认为应该包含的资料…
列出所有的参考资料文档〔可以是非正式出版物〕，格式如下：
[标识符] [作者]，[文档名称]，[出版单位(或归属单位)]，日期

6.2、 定义、首字母缩写词和缩略语
编写建议：记录在需求调研过程中所记录/识别的所有专业词汇和缩略语(可能和业务无关的)，并给出解释说明。格式如下：
缩写、术语
解释说明

6.3、 附件
6.3.1、 用户需求调研表
需求标题：

调查式：
□访谈□□□即时通讯
调查人：

调查时间：

调查地点：

参加人员：

调研容：

取得的原始材料：

调查人签字：

客户代表签字：

6.3.2、 参考文档资料
编写建议：本处用于附加在“1.4、参考资料〞和“6.1、软件应当遵循的标准或规〞中所设计到的所有资料和文档。

教育之通病是教用脑的人不用手，不教用手的人用脑，所以一无所能。教育革命的对策是手脑联盟，结果是手与脑的力量都可以大到不可思议。

. .word.zl.