文档编号:X X X X-D P-x x x x x-1C-x x x 需求分析模版(版本v1.0.0 2016年6月8日 成文信息 主题词:需求分析 作者:技术部文档类别: 审核: 批准:文档性质:正式稿主送:存档日期: 抄送:发布日期: 变更信息
版本原因作者日期 目录
需求分析模板 11.1 安全保密 11.2 维护服务 示例： 1、应用安装更新过程的错误处理 2、日志分析
第2篇：软件项目需求调研报告_
---WORD格式--可编辑--
word 格式文档
文件信息
文件状态： [ √]
[ ] [ ]
[XXXX]
[XXXX]技术有限公司 [ 公司名称 ]
[XXXX]公司 [ 客户名称 ] 软件项目 [ 项目或产品名称 ]
需求调研报告
草稿文件
正式文件 更改正式文件
文档编号： 文档类别： 文件名： 文件摘要： 项目名称：
当前阶段： 需求调研阶段 版权所有：
当前版本： V1.0.0 作 者：
审 核：
完成日期：
文档标题： 软件项目需求调研报告
提交人员：
专业整理
----
---WORD格式--可编辑--
word 格式文档
作者 陈建伟
专业整理
修改内容
评审号 更改请求号
定义文件模板
----
修改历史
9 日期 2013-06-2
版本 V1.0.0
---WORD格式--可编辑--
word 格式文档
目录
文件信息 1 修改历史 2 目录...3 一、引言...4 1.1、编写目的...4 1.2、文档范围...4 1.3、预期读者和阅读建议..4 1.4、参考资料...4 二、项目描述 4 2.1、项目背景...4 2.2、项目名称...5 2.3、项目概述...5 2.4、项目关联性..5 2.5、设计和实现上的限制..5 2.6、假定和约束..6 2.7、名词 / 术语解释......6 三、用户环境描述....6 3.1、用户单位组织结构...6 3.2、用户部门设置与职责..6 3.3、用户业务关系描述...7 3.4、系统面向的用户群...7 3.5、关键计算机资源......7 3.6、用户环境中的其他应用系统分布.........7 四、功能性需求描述.7 4.1、用户各部门当前的工作模式...7 4.2、构建该系统的目标...8 4.3、功能结构图..9 4.4、功能点需求..9 4.5、接口需求.10 五、非功能性需求描述.........11 5.1、系统环境需求.......11 5.2、易用性和用户体验需求.......11 5.3、软硬件技术需求....11 5.4、安全性需求..........11 5.5、可维护性需求.......11 5.6、对培训的需求.......12 六、其他.12 6.1、软件应当遵循的标准或规范.12 6.2、定义、首字母缩写词和缩略语..........12 6.3、附件.......13
专业整理
----
---WORD格式--可编辑--
一、2.1、项目背景
编写建议： 描述该项目的建设背景；
专业整理 1.1、编写目的引言
word 格式文档
编写提示：阐明编写该文档的目的； 本节内容是读者接触到本文的第一段正式文字，建议通过简短文字描述简明扼要的告诉他们编写本文档的目标。例如：
1、本文档是 [ 项目名称 ] [ 系统属性 ] 客户需求调研报告，供需求分析人员进行项目
需求分析时使用； 2、本文档可以作为项目验收标准之一； 3、本文档可以作为软件维护的参考资料；
1.2、文档范围
编写提示： 对本文当所涉及到所有内容的高度概括，简要说明即可。例如：
1、本文档包括 [ 项目描述 ]、[ 用户环境描述 ] ⋯ 等几个章节，并：
a)在 [ 项目描述 ] 章节中描述了⋯信息； b)在 [ 用户环境描述 ] 章节中描述了 ⋯ 信息； c)⋯
1.3、预期读者和阅读建议
编写提示： 描述本文档可能涉及到的各类读者对象以及不同的读者应该注意的侧重点；
1.4、参考资料
编写提示：列出本文档的所有参考文献（可以是非正式出版物、客户的规章制度和流程文件、相关法律法规文件等），格式如下：
名称
日期
作者
版本
出版社
并且，请在本文档最后附上所有列出的参考资料的附件。
二、项目描述
----
---WORD格式--可编辑--
例如：
1、项目立项时的环境描述； 2、项目立项的政策性支持；
word 格式文档
3、项目需求提出的初衷目的等。
2.2、项目名称
编写建议： 描述该项目的名称，格式为： [ 客户名称 ]-[ 软件名称 ]。例如：
江西省电力集团信息通讯分公司-调运检一体化智能联动管理平台
2.3、项目概述
编写建议： 描述该项目的概要情况。应包括如下信息：
1、项目的委托单位；
2、项目主要功能或解决问题描述； 可以用列举方式进行描述，例如：
1、项目委托单位： [ 单位名称 ] ；
2、比较委托单位原有系统与完整系统结构进行对比等，或进行详细的系统结构概述； 3、针对项目的特色功能进行基本描述； 4、⋯
2.4、项目关联性
编写建议： 描述该项目与其他相关事物的关联性。应包括如下信息：
1、与其他现有软件系统的关联性；
2、对现有客户环境（IT 环境、管理措施等）造成的影响； 3、对以后可能建设的其他系统造成的长期影响； 4、其他认为应该包括的信息⋯
2.5、设计和实现上的限制
编写建议：描述该项目的需求调研和分析、设计以及开发实现过程中可能会遇到的技术性限制； 例如：
1、软件实现技术上的要求； 2、与其他关联系统的对接要求； 3、预留接口或扩展性的要求； 4、其他认为应该包括的信息⋯
专业整理
----
---WORD格式--可编辑--
3.1、用户单位组织结构 2.6、假定条件和约束
word 格式文档
编写建议：描述该项目的需求调研和分析、设计以及开发过程中可能会遇到的非技术性条件和限制，例如： 假定性条件：
1、对目标用户文化程度和计算机操作水平、财务知识水平等方面的假设； 限制性条件：
1、项目建设时间上的要求；
2、团队人员或人资条件上的限制和要求； 3、其他认为应该包括的信息⋯
2.7、名词 / 术语解释
编写建议： 列出本文档所涉及到的关于客户需求领域的行业或专业技术特有的(专用)名次 / 和术语并给出符合实际情况的解释说明；编写格式如下： 中文全称
中文简称
英文全称
英文简称
解释说明
三、用户环境描述
编写信息：利用表格或框图(建议)形式画出委托单位的组织结构图； 应包括委托单位的所有分支结构和部门名称，以及各个分支机构 / 部门间的上下级关系。
3.2、用户部门设置与职责
编写建议：按业务组织结构划分成不同的职责部门或分支机构，分别对每个部门或分支机构进行描述。描述的内容包括：
1、用户组、分支结构或部门的名称
2、每个用户组、分支结构或部门的描述，主要描述他们的职责，及用户组或分支结构
/ 部门的考核指标； 3、每个用户组、分支结构或部门相关人员的职责，及考核指标。
[ 可以使用下面的格式，也可以根据实际的需要使用其他格式 ] 例如： 用户组 / 机构 / 部门名称
职责描述
考核指标
备注
专业整理
----
---WORD格式--可编辑--
3.3、用户业务关系描述
word 格式文档
编写建议：以关系图的方式加文字说明的方式，描述该软件系统所计划完成的系统业务，以及该业务在内部的工作流情况，还有该业务的相关部门的接口情况。注意本图示需要表明业务关联关系而非数据关联关系。
3.4、系统面向的用户群
编写建议：描述该系统建设以后的目标用户群体以及他们的专业知识水平（例如计算机操作能力、财务知识水平等）、各类用户的主要使用内容和工作职责等。
3.5、关键计算机资源
编写建议： 列出该软件所涉及到的所有部门和机房的软硬件资源情况、设备要求等；
3.6、用户环境中的其他应用系统分布
编写建议： 列出该软件所涉及到的用户环境中的其他所有应用系统的分布情况；应该包括：
1、其他应用系统的名称； 2、责任部门；
3、应用系统功能概述； 4、部署的服务器以及机房； 5、其他认为应该包括的信息⋯
四、功能性需求描述
4.1、用户各部门当前的工作模式
编写建议：该章节描述调研过程中发现的，客户业务实际的操作情况，建议以表格、流程图等形式进行说明。并且按照如下列出的格式分部门分层面进行描述：
4.1.1、4.1.1.1、部门一 [ 部门名称 ] 工作内容
编写建议： 描述该部门之前（未用软件进行工作管理）的主要工作内容和工作职责。
专业整理
----
---WORD格式--可编辑--
word 格式文档
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、客户希望该系统建立后能在管理上、业务流程上规范解决的问题；
专业整理
----
---WORD格式--可编辑--
word 格式文档
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、功能点一 业务描述
编写建议： 描述该功能点实际处理的业务情况，以及在这个业务中应该注意的细节、要点 , 以及工作目标等等。
专业整理
----
---WORD格式--可编辑--
word 格式文档
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、外部接口需求
编写建议：描述该软件系统与其他软件系统之间的业务接口，可以采用图表加文字的方式进行展示；每个接口间列出详细的接口要素及其说明，并且对具体的调用方式进行描述。
专业整理
----
---WORD格式--可编辑--
五、5.1、系统环境需求
非功能性需求描述
word 格式文档
编写建议：描述客户方对软件系统的系统环境需求，即客户要求在什么样的环境下使用该系统；包括网络环境、人员环境、使用频率和周期等等。
5.2、易用性和用户体验需求
编写建议：描述客户方对软件系统在易用性和用户体验方面的需求，例如客户对界面布局的要求，对软件各项表单操作提醒的要求、对帮助文档的要求等等。
5.3、软硬件技术需求
编写建议： 描述客户方对该软件系统开发和部署方面的软硬件环境和技术的要求： 例如：
1、软件开发过程中使用到的开发语言、基础框架等；
2、软件开发和部署的操作系统、WEB浏览器等方面的要求； 3、软件部署的硬件服务器的性能配置要求等； 4、其他认为应该包含的信息⋯
5.4、安全性需求
编写建议： 描述客户方对该软件在安全方面的要求； 例如：
1、数据库安全性； 2、备份和容灾策略； 3、数据出错时的回滚机制； 4、系统安全性； 5、密码安全性；
6、防止 XSS和 SQL注入攻击等； 7、其他认为应该包含的信息⋯
5.5、可维护性需求
编写建议： 描述客户方或者我方维护人员对该软件系统在可维护性方面的需求。例如：
1、远程维护的需求； 2、备份的需求；
专业整理
----
---WORD格式--可编辑--
6.1、软件应当遵循的标准或规范 4、其他认为应该包含的信息⋯
word 格式文档
3、对系统维护的要求（对管理人员专业水平的要求）等；
5.6、对培训的需求
编写建议： 描述客户方和我方实施 / 售后人员对该软件系统在培训方面的需求。例如：
1、对客户方领导的培训；
2、对客户方管理人员 / 系统管理员的培训； 3、对客户方普通操作人员的培训； 4、对我方技术实施和售后人员的培训； 5、其他认为应该包含的信息⋯
六、其他
编写建议： 列出本软件在需求调研和分析、设计以及开发等过程中应当遵循的各项规范。例如：
1、本软件所涉及到的行业在该软件所涉及到的业务领域的相关行业执行标准； 2、国家在该软件所涉及到的业务领域的相关法律法规和执行标准；
3、客户方自身对于软件所涉及到的业务领域的管理制度和错误以及相关标准； 4、其他同类型软件产品的相关规范和定义；
5、本次软件研发所应该遵循的标准 / 规范/ 要求等等； 6、其他认为应该包含的资料⋯
列出所有的参考资料文档（可以是非正式出版物），格式如下：
[ 标识符 ] [ 作者]，[ 文档名称 ]，[ 出版单位(或归属单位)]，日期
6.2、定义、首字母缩写词和缩略语
编写建议： 记录在需求调研过程中所记录 / 识别的所有专业词汇和缩略语(可能和业务无关的)，并给出解释说明。格式如下：
缩写、术语
解释说明
专业整理
----
---WORD格式--可编辑--
6.3、附件 6.3.1、用户需求调研表
word 格式文档
需求标题：
调查方式： □访谈 调查人： 调查地点： 参加人员：
□电话
□邮件
□即时通讯
调查时间：
调研内容：
取得的原始材料：
调查人签字： 客户代表签字：
专业整理
----
---WORD格式--可编辑--
6.3.2、参考文档资料
word 格式文档
编写建议：本处用于附加在“ 1.4、参考资料”和“ 6.1、软件应当遵循的标准或规范”中所设计到的所有资料和文档。
宁可累死 在路上，也不 能闲死 在家里
！宁可
去碰壁
牙，腿
斗？奋
斗就是
一年一 年却越 来越容易。不奋斗就是每天都很容易，可一年一年越来越难。能干的人，不在情绪上计较，只在 做事上 认真； 无能的 人！不 在做事上认真，只，也不在情绪
能面壁上计较。是狼。拼一 就要练个春夏 好秋冬！是羊就赢一个 要练好无悔人 生。什！早 么是奋安！—————献给所有 每天很努力的 难，可人
专业整理
----
第3篇：软件项目需求调研报告
--考试--学资学习网--押题---
[XXXX]技术有限公司[公司名称]
[XXXX]公司[客户名称]
[XXXX]软件项目[项目或产品名称] 需求调研报告
文件信息
修改历史
目录
引言
编写目的编写提示：阐明编写该文档的目的；本节内容是读者接触到本文的第一段正式文字，建议通过简短文字描述简明扼要的告诉他们编写本文档的目标。
例如：
本文档是 [项目名称] [系统属性] 客户需求调研报告，供需求分析人员进行项目需求分析时使用；
本文档可以作为项目验收标准之一；
本文档可以作为软件维护的参考资料；
文档范围
编写提示：对本文当所涉及到所有内容的高度概括，简要说明即可。
例如： 本文档包括 [项目描述]、[用户环境描述]… 等几个章节，并：
在 [项目描述] 章节中描述了…信息；
1 / 1
3在 [用户环境描述] 章节中描述了 … 信息；
…
预期读者和阅读建议
编写提示：描述本文档可能涉及到的各类读者对象以及不同的读者应该注意的侧重点；
参考资料
编写提示：列出本文档的所有参考文献（可以是非正式出版物、客户的规章制度和流程文件、相关法律法规文件等），格式如下：
并且，请在本文档最后附上所有列出的参考资料的附件。
项目描述
项目背景
编写建议：描述该项目的建设背景；
例如：
项目立项时的环境描述；
项目立项的政策性支持；
项目需求提出的初衷目的等。
项目名称
编写建议：描述该项目的名称，格式为：[客户名称]-[软件名称]。例如：
江西省电力集团信息通讯分公司-调运检一体化智能联动管理平台
项目概述
2 / 1
3编写建议：描述该项目的概要情况。应包括如下信息：
项目的委托单位；
项目主要功能或解决问题描述；
可以用列举方式进行描述，例如：
项目委托单位：[单位名称]；
比较委托单位原有系统与完整系统结构进行对比等，或进行详细的系统结构概述；
针对项目的特色功能进行基本描述；
…
项目关联性
编写建议：描述该项目与其他相关事物的关联性。应包括如下信息：
与其他现有软件系统的关联性；
对现有客户环境（IT环境、管理措施等）造成的影响；
对以后可能建设的其他系统造成的长期影响；
其他认为应该包括的信息…
设计和实现上的限制
编写建议：描述该项目的需求调研和分析、设计以及开发实现过程中可能会遇到的技术性限制；
例如：
软件实现技术上的要求；
与其他关联系统的对接要求；
3 / 1
3预留接口或扩展性的要求；
其他认为应该包括的信息…
假定条件和约束
编写建议：描述该项目的需求调研和分析、设计以及开发过程中可能会遇到的非技术性条件和限制，例如：
假定性条件：
1、对目标用户文化程度和计算机操作水平、财务知识水平等方面的假设；
限制性条件：
项目建设时间上的要求；
团队人员或人资条件上的限制和要求；
其他认为应该包括的信息…
名词/术语解释
编写建议：列出本文档所涉及到的关于客户需求领域的行业或专业技术特有的(专用)名次/和术语并给出符合实际情况的解释说明；编写格式如下： 用户环境描述
用户单位组织结构
编写信息：利用表格或框图(建议)形式画出委托单位的组织结构图；应包括委托单位的所有分支结构和部门名称，以及各个分支机构/部门间的上下级关系。
用户部门设置与职责
编写建议：按业务组织结构划分成不同的职责部门或分支机构，分别对每个部门或分支机构进行描述。描述的内容包括：
4 / 1
3用户组、分支结构或部门的名称
每个用户组、分支结构或部门的描述，主要描述他们的职责，及用户组或分支结构/部门的考核指标；
每个用户组、分支结构或部门相关人员的职责，及考核指标。
[可以使用下面的格式，也可以根据实际的需要使用其他格式] 例如：
用户业务关系描述
编写建议：以关系图的方式加文字说明的方式，描述该软件系统所计划完成的系统业务，以及该业务在内部的工作流情况，还有该业务的相关部门的接口情况。注意本图示需要表明业务关联关系而非数据关联关系。
系统面向的用户群 编写建议：描述该系统建设以后的目标用户群体以及他们的专业知识水平（例如计算机操作能力、财务知识水平等）、各类用户的主要使用内容和工作职责等。
关键计算机资源
编写建议：列出该软件所涉及到的所有部门和机房的软硬件资源情况、设备要求等；
用户环境中的其他应用系统分布
编写建议：列出该软件所涉及到的用户环境中的其他所有应用系统的分布情况；应该包括：
其他应用系统的名称；
责任部门；
应用系统功能概述；
5 / 1
3部署的服务器以及机房；
其他认为应该包括的信息…
功能性需求描述
用户各部门当前的工作模式
编写建议：该章节描述调研过程中发现的，客户业务实际的操作情况，建议以表格、流程图等形式进行说明。并且按照如下列出的格式分部门分层面进行描述：
部门一[部门名称] 工作内容
编写建议：描述该部门之前（未用软件进行工作管理）的主要工作内容和工作职责。
工作流程
编写建议：描述该部门相关工作的处理流程，建议以流程图形式进行描述；
涉及到的表单
编写建议：描述该部门各项工作处理过程中，可能涉及到的各种单据，描述的内容应包含如下信息：
每项单据的名称和用途；
单据流转的流程；
单据牵涉到的相关人员；
单据的标准填写格式。
建议提供相关单据的附件。
6 / 1
3与其他部门的关系
编写建议：描述该部门各项工作在执行处理过程中可能会牵涉到的其他部门，以及其他部门的处理内容；
存在的问题
编写建议：描述该部门各项工作之前执行过程中存在的各项问题；以及为什么要用软件管理的方式来体改之前的执行操作方式。部门二
[参考部门一] 部门N…
[参考部门一] 构建该系统的目标
编写建议：介绍本软件系统的建设目的，从用户的角度描述该系统建立后应该达到的预期目标。可以从以下几个方面进行描述：
管理目标
编写建议：描述客户领导层/管理层对本软件系统的建设要求：
例如：
客户希望该系统建立后能在管理上、业务流程上规范解决的问题；
希望能够通过该软件系统达到什么样的使用效果和目标；
系统该软件系统能出什么报表数据，或者用该软件系统能提高哪些工作效率等等；
使用目标
7 / 1
3编写建议：对具体业务上来说，客户系统通过该系统能够实际解决的问题。该内容的编写应参考具体每个使用部门的意见。
业绩目标
编写建议：描述该软件系统上线应用后计划实现的业绩目标：
例如： 减少多少行政办公时间工作时的计算；
减少多少办公耗材资源的计算；
对行政效率提升的具体计算；
对数据统计效率提升的具体计算；
对产能提高的具体计算；
其他…
功能结构图
编写建议：描述软件系统中各个模块以及模块下功能/子模块的划分；整体展示系统中所具备的功能模块，以及各个模块之间的关联情况。建议以结构图的形式进行描述；
该功能结构图仅描述客户对功能模块的意向需求，而不是根据客户需求分析后的功能模块设计。
功能点需求
编写建议：该章节描述调研过程中发现的，客户对软件具体功能点的要求，建议以表格、流程图加文字的形式进行说明，按照不同的功能点进行列举方式描述。格式建议如下：
功能点一
业务描述
8 / 1
3编写建议：描述该功能点实际处理的业务情况，以及在这个业务中应该注意的细节、要点,以及工作目标等等。用例及关键数据
编写建议：以用例图加文字说明的形式，呈现该业务所有参与者及其用例的执行过程，以及他们之间的关系，还应该包括每个用例所涉及处理的数据以及所涉及到的单据。
业务流程图
编写建议：以流程图加文字说明的形式，描述该功能点的业务流程，明确各个业务流程的节点，对象和内容。
与其他功能点的关系
编写建议：描述该功能点与其他功能点的关系，例如需要从其他功能模块调去数据，根据其他功能点的执行结构进行条件判断处理等等。
子功能点
编写建议：描述该功能点可能存在的子功能点，以便对整体功能进行更加明确的划分；格式直接参照上面的四项内容即可。
功能点二
[参考功能点一] 功能点N…
[参考功能点一] 接口需求
编写建议：描述该软件所涉及到的内部接口和外部接口需求。
内部接口需求
9 / 1
3 编写建议：描述各个模块或者功能点之间的业务接口，可以采用图表加文字的方式进行展示；每个接口间列出详细的接口要素及其说明。
外部接口需求
编写建议：描述该软件系统与其他软件系统之间的业务接口，可以采用图表加文字的方式进行展示；每个接口间列出详细的接口要素及其说明，并且对具体的调用方式进行描述。
非功能性需求描述
系统环境需求
编写建议：描述客户方对软件系统的系统环境需求，即客户要求在什么样的环境下使用该系统；包括网络环境、人员环境、使用频率和周期等等。
易用性和用户体验需求
编写建议：描述客户方对软件系统在易用性和用户体验方面的需求，例如客户对界面布局的要求，对软件各项表单操作提醒的要求、对帮助文档的要求等等。
软硬件技术需求
编写建议：描述客户方对该软件系统开发和部署方面的软硬件环境和技术的要求：
例如：
软件开发过程中使用到的开发语言、基础框架等；
软件开发和部署的操作系统、WEB 浏览器等方面的要求；
软件部署的硬件服务器的性能配置要求等； 其他认为应该包含的信息…
安全性需求
10 / 1
3编写建议：描述客户方对该软件在安全方面的要求；
例如：
数据库安全性；
备份和容灾策略；
数据出错时的回滚机制；
系统安全性；
密码安全性；
防止XSS和SQL注入攻击等；
其他认为应该包含的信息…
可维护性需求
编写建议：描述客户方或者我方维护人员对该软件系统在可维护性方面的需求。
例如：
远程维护的需求；
备份的需求；
对系统维护的要求（对管理人员专业水平的要求）等；
其他认为应该包含的信息…
对培训的需求 编写建议：描述客户方和我方实施/售后人员对该软件系统在培训方面的需求。
例如：
11 / 13
对客户方领导的培训；
对客户方管理人员/系统管理员的培训；
对客户方普通操作人员的培训；
对我方技术实施和售后人员的培训；
其他认为应该包含的信息…
其他
软件应当遵循的标准或规范
编写建议：列出本软件在需求调研和分析、设计以及开发等过程中应当遵循的各项规范。
例如：
本软件所涉及到的行业在该软件所涉及到的业务领域的相关行业执行标准；
国家在该软件所涉及到的业务领域的相关法律法规和执行标准；
客户方自身对于软件所涉及到的业务领域的管理制度和错误以及相关标准；
其他同类型软件产品的相关规范和定义；
本次软件研发所应该遵循的标准/规范/要求等等； 其他认为应该包含的资料…
列出所有的参考资料文档（可以是非正式出版物），格式如下：
[标识符] [作者]，[文档名称]，[出版单位(或归属单位)]，日期
定义、首字母缩写词和缩略语
12 / 1
3编写建议：记录在需求调研过程中所记录/识别的所有专业词汇和缩略语(可能和业务无关的)，并给出解释说明。格式如下：
附件
用户需求调研表
参考文档资料
编写建议：本处用于附加在“1 4、参考资料”和“6
1、软件应当遵循的标准或规范”中所设计到的所有资料和文档。
13 / 13
第4篇：将军项目需求调研报告
需求调研报告
一、调研目的主要对将军集团现有安全业务运行情况、安全管理制度、组织机构等内容进行调研；结合招标要求，了解各级领导、安全管理人员对于信息系统的真实想法，以方便需求分析、原型设计。
二、调研对象
实地调研将军集团本部、烟辅中心、包材、莱州印务，其它公司在需求介绍会上征求意见。
三、调研情况 (一)组织机构
目前将军集团由集团本部、13家分公司组成，其中有3家中心归属集团本部管理。
(二)安全人员
不一定都有安保部，但都会有专兼职安全员。
(三)OA情况
OA系统账号管理比较严格，下属单位账号只有公司领导和办公室有，导致安全部门的一些文件通告等不能及时传达给下属单位的安全相关人员。
(四)计划使用人员
安全系统主要由安全线人员使用，包括各部门、公司主管领导等也可以操作。(五)集团安保处在系统中作用
集团安保处主要进行监督、管理，具体业务在各公司内部完成。(六)集团安保处希望必须具备的功能
1、增加日报功能
2、增加文件查阅日志功能
3、增加集团培训计划下发，各公司上报人员功能 (七)关于系统流程情况的说明
经过调研，考虑到人员操作水平、快捷性，只有公司级隐患涉及流程操作，其它业务线下走处理。
四、业务功能
1、目标考核
各个部门每年分别依据上级目标，建立自己的安全生产目标；
集团每季度对各公司进行考核；
公司每月对各部门进行考核。
2、安全费用
各部门每年初制定安全生产费用计划，按照费用类别录入；
当有对应项目时，需要选择计划，并将支出内容进行填报。
3、培训、证书管理
各部门每年自行制定培训计划，并依据计划执行。
集团安保处会安排组织有上级部门、集团、政府组织的培训，需要下级公司部门根据计划提交参加培训人员，集团安保处对培训结果进行登记。人劳部门负责证书的管理。
4、设备设施
各公司实行设备信息由设备管理部门自行登记的方式管理维护，设备检查要具体到某个设备。
5、交通安全管理
一般有各公司办公室统一管理，只针对普通车辆管理，需要包括车辆的年审、保险等信息。驾驶员也需要进行登记。
6、职业健康管理
公司安保部门根据国家职业病相关法规和标准对有危害因素的场所进行识别，并联系相关检测部门对场所进行检测，检测结果存在危害因素的纳入危害因素场所进行管理，检测结果达标的场所将不在系统内进行管理（危害因素检测信息由公司安保部门录入系统）。同时，安保部门需要针对危害因素的场所定期进行检测，或者定期进行重新识别有危害因素的场所。危害因素的场所的危害因素由检测报告的结果进行确定。
危害场所内工作的人员要进行统计，并根据要求定期进行体检。人员的体检工作由公司人劳部门进行管理。在有危害因素场所工作的人员在上岗前、上岗中和离岗前都要进行针对相关危害因素的体检，确保没有因为工作环境而得职业病。其进行体检的相关人员信息由公司人劳部门建立档案进行长期管理（管理年限和档案相同）。各部门安全员从人劳部统一领取涉及本部门的所有劳防品（该领取记录不在系统中体现），然后再由部门安全员将其发放到具体岗位、人员，发放时具体领取人员需签字确认，发放完成后由部门安全员将发放记录登记建档，签字确认单以照片附件形式上传，不在系统中按人员逐条录入。
7、消防安全管理
公司安保部负责对公司消防安全进行统一管理，主要包括建筑物消防台账、重点部位台账、设施器材和消防队伍的管理与登记。其中设施器材日常要进行保养工作；每个公司至少有一支消防队伍。
8、法规标准与资料
集团安保处安全员负责法律法规、国家标准信息的统一发布和管理。全集团所有角色可以对其进行查看。
公司安保处安全员、部门安全员可以发布适用自己部门特点的管理制度与相关资料，并对其进行管理。
9、安委会管理
公司安保部维护自己所在公司的安委会相关信息，安委会信息包括安委会基本信息和安委会成员信息两部分。
公司安保部对各自的安委会日常活动进行管理，主要包括定期召开安委会会议并纪录会议纪要并跟踪会议确定的决议后续工作。
10、危险作业管理
由于危险作业涉及重大责任问题，约定保留纸质档案材料，线下走审批流程，安保部需要将最终审批通过的信息进行登记。
危险作业分为：动火、高处、有限空间、临时用电。
安保部对不同阶段的危险作业进行检查工作，并将结果进行登记。
11、危险源管理
每年年初，公司各部门会对所辖区域内的所有危险源做一次辨识，辨识结果上报至公司安保部进行审核，通过后公司安保部汇总、上报公司分管领导审批。经过沟通，安保部将审批通过的危险源登记，并发布作为当年度确认的危险源。
在管理过程中如出现技术改造等，可通过撤销发布，进行删除、修改危险源。只有当年度辨识的未发布的危险源可进行发布；只有当年度的危险源可进行撤销、修改；已经发布的非当年度危险源不能进行撤销。
危险源所在部门以及公司安保部门在日常工作过程中需定期对其进行检查。
12、隐患管理
部门级隐患在系统中不涉及流程；公司级隐患按照正常流程处理。公司级隐患的闭环管理包括：问题登记、隐患核准、隐患整改通知书下发、隐患整改措施制定、隐患整改实施、隐患验收。上级检查登记后，受检部门进行整改，自行在系统中进行处理，需在全部整改完毕后，进行反馈，上级部门再进行复查。经过沟通，这一过程在系统中不涉及流程，仅以结果进行登记。公司级隐患管理流程经过沟通，流程图如下： 隐患管理流程（web）问题登记公司级-隐患发现部门公司级-安保部门公司级-责任部门开始[安全员]问题登记[安全员]提交隐患核准[安全员]隐患核准否是否通过是整改通知[安全员]下发整改意见整改措施[安全员]是撤回整改意见书[安全员]是否接受否[安全员]填写申诉理由是[安全员]不撤回[安全员]是否申诉反馈否[安全员]填写整改措施实施整改实施整改签收前可撤回[安全员]填写整改实施情况整改验收[安全员]签收[安全员]整改验收否是否验收通过是结束
13、事故管理
事故管理主要包括未遂事件、事故台账.事故调查完成之后，形成最终事故报告。
每家公司每季度需要形成一份安全生产报告。
14、车间班组管理
各部门自行维护各自的班组信息，并对班组活动计划、记录进行管理。
15、沟通协商
主要针对日常安全工作中由安保部门牵头的不同部门、人员协商沟通的活动纪要。主要包括会议、电话沟通、口头沟通等形式的记录。
16、三同时
主要针对需要报政府部门备案的三同时项目建立台账。要求安保部门参与，基建部门是主要责任部门。
17、信息交流
主要包括消息中心、集团发布的资讯信息、日报提交与查看、互动信息等。
18、安全知识
安全文化建设是企业文化建设中的一部分内容，通过建立安全文化园地实现安全文化建设，内容包括：问题建议查看、安全知识分享，其中问题建议通过手机端实现。
19、应急演练
各公司安保部录入经过确定的应急预案，针对各预案每年年初制订演练计划，各部门依据演练计划实施演练，最后会对演练的效果、预案的情况进行评价。20、危险物品管理
危险物品动态的台账由仓储或者生产之类的业务部门管理，由于危险物品领用在日常工作中比较频繁，并且每日均有变化，故在系统中不实现危险物品的领用量、库存量的动态管理，不做领用记录。在系统中危险物品的管理统一由公司安保部管理。
21、相关方管理
相关方管理有各部门(归口部门)自行登记管理。
主要包括相关方信息、相关方协议、相关方评价、相关方交底教育。
22、移动端
(1)标准版：
应用对象为WEB端有账号的人员，需通过平台账号登录； 主要功能包括“移动巡检、消息中心、问题建议、安全知识分享、集团资讯、日报提交”。
(2)全员版
应用对象为全员员工，安装后无需账号即可使用，主要目的为推进全员参与；
功能包括“集团资讯、安全知识分享、问题建议”；首次进入时需要设定所在公司。
上一篇：创文宣传工作汇报（共6篇）
下一篇：岗位职责情况自我评价（共12篇）
