软件项目需求调研报告模板样本.doc

XXXX技术有限公司公司名称XXXX公司客户名称XXXX软件项目项目或产品名称需求调研报告文件信息文件状态: 草稿文件 正式文件 更改正式文件当前版本: V1.0.0作 者: 审 核: 完成日期: 文档编号: 文档标题: 软件项目需求调研报告文档类别: 提交人员: 文 件 名: 文件摘要: 项目名称: 当前阶段: 需求调研阶段版权所有: 修改历史日期版本作者修改内容评审号更改请求号 -06-29V1.0.0陈虎定义文件模板目录文件信息1修改历史2目录3一、 引言41.1、 编写目的41.2、 文档范围41.3、 预期读者和阅读建议41.4、 参考资料4二、 项目描述42.1、 项目背景42.2、 项目名称52.3、 项目概述52.4、 项目关联性52.5、 设计和实现上的限制52.6、 假定和约束62.7、 名词/术语解释6三、 用户环境描述63.1、 用户单位组织结构63.2、 用户部门设置与职责63.3、 用户业务关系描述73.4、 系统面向的用户群73.5、 关键计算机资源73.6、 用户环境中的其它应用系统分布7四、 功能性需求描述74.1、 用户各部门当前的工作模式74.2、 构建该系统的目标84.3、 功能结构图94.4、 功能点需求94.5、 接口需求10五、 非功能性需求描述115.1、 系统环境需求115.2、 易用性和用户体验需求115.3、 软硬件技术需求115.4、 安全性需求115.5、 可维护性需求115.6、 对培训的需求12六、 其它126.1、 软件应当遵循的标准或规范126.2、 定义、 首字母缩写词和缩略语126.3、 附件13一、 引言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、 软件应当遵循的标准或规范”中所设计到的所有资料和文档。