软件项目需求调研报告-模板

《软件项目需求调研报告-模板》由会员分享，可在线阅读，更多相关《软件项目需求调研报告-模板（17页珍藏版）》请在装配图网上搜索。

1、XXXX技术有限公司公司名称XXXX公司客户名称XXXX软件项目项目或产品名称需求调研报告文件信息文件状态：V草稿文件正式文件更改正式文件当前版本：V1.0.0作者：审核：完成日期：文档编号：文档标题：软件项目需求调研报告文档类别：提交人员：文件名：文件摘要：项目名称：当前阶段：需求调研阶段版权所有：修改历史日期版本作者修改内容评审号更改请求号2013-06-29V1.0.0陈建伟定义文件模板-可编辑修改-目录文件信息 修改历史 目录1.2.3.引言 1.1、 编写目的 1.2、 文档范围 预期读者和阅读建议 参考资料 项目描述 项目背景 项目名称 项目概述 项目关联性 设计和实现上的限制 假

2、定和约束 名词 / 术语解释 用户环境描述 用户单位组织结构 用户部门设置与职责 用户业务关系描述 系统面向的用户群 关键计算机资源 用户环境中的其他应用系统分布 功能性需求描述 用户各部门当前的工作模式 . 构建该系统的目标 功能结构图 功能点需求 接口需求 非功能性需求描述 系统环境需求 易用性和用户体验需求 软硬件技术需求 安全性需求 可维护性需求 对培训的需求 其他 软件应当遵循的标准或规范 . 定义、首字母缩写词和缩略语 附件 1.3、1.4、2.1、2.2、2.3、2.4、2.5、2.6、2.7、3.1、3.2、3.3、3.4、3.5、3.6、 四、4.1、4.2、4.3、4.4、

3、4.5、五、5.1、5.2、5.3、5.4、5.5、5.6、六、6.1、6.2、6.3、.4.4.4.4.4.5.5.5.5.5.5.6.6.6.6.6.7.7.7.7.7.7.8.9.9.1.0.1.1.1.1.1.1.1.1.1.1.1.2.1.2.1.2.1.2.1.2.1.3.-可编辑修改 -引言1.1、编写目的编写提示：阐明编写该文档的目的；本节内容是读者接触到本文的第一段正式文字， 建议通 过简短文字描述简明扼要的告诉他们编写本文档的目标。例如：1、本文档是项目名称系统属性客户需求调研报告，供需求分析人员进行项目需求 分析时使用；2、本文档可以作为项目验收标准之一；3、本文档可以作

4、为软件维护的参考资料；1.2、文档范围编写提示：对本文当所涉及到所有内容的高度概括，简要说明即可。 例如：1、本文档包括项目描述卜用户环境描述等几个章节，并:a）在项目描述章节中描述了 信息；b）在用户环境描述章节中描述了信息；c）1.3、预期读者和阅读建议编写提示：描述本文档可能涉及到的各类读者对象以及不同的读者应该注意的侧重点;1.4、参考资料编写提示：列出本文档的所有参考文献（可以是非正式出版物、客户的规章制度和流程文件、 相关法律法规文件等），格式如下：名称日期作者版本出版社并且，请在本文档最后附上所有列出的参考资料的附件项目描述2.1、项目背景编写建议： 描述该项目的建设背景； 例如

5、：1、项目立项时的环境描述；2、项目立项的政策性支持；3、项目需求提出的初衷目的等。2.2、项目名称编写建议： 描述该项目的名称，格式为： 客户名称 -软件名称。 例如：江西省电力集团信息通讯分公司 -调运检一体化智能联动管理平台2.3、项目概述编写建议： 描述该项目的概要情况。应包括如下信息：1、项目的委托单位；2、项目主要功能或解决问题描述； 可以用列举方式进行描述，例如：1、项目委托单位： 单位名称 ；2、比较委托单位原有系统与完整系统结构进行对比等，或进行详细的系统结构概述；3、针对项目的特色功能进行基本描述；4、2.4、项目关联性编写建议： 描述该项目与其他相关事物的关联性。应包括如

6、下信息：1、与其他现有软件系统的关联性；2、对现有客户环境（ IT 环境、管理措施等）造成的影响；3、对以后可能建设的其他系统造成的长期影响；4、其他认为应该包括的信息 2.5、设计和实现上的限制编写建议：描述该项目的需求调研和分析、 设计以及开发实现过程中可能会遇到的技术性限 制；例如：1、软件实现技术上的要求；2、与其他关联系统的对接要求;3、预留接口或扩展性的要求；4、其他认为应该包括的信息2.6、假定条件和约束编写建议：描述该项目的需求调研和分析、设计以及开发过程中可能会遇到的非技术性条件 和限制，例如：假定性条件：1、对目标用户文化程度和计算机操作水平、财务知识水平等方面的假设; 限

7、制性条件：1、项目建设时间上的要求；2、团队人员或人资条件上的限制和要求;3、其他认为应该包括的信息2.7、名词/术语解释编写建议：列出本文档所涉及到的关于客户需求领域的行业或专业技术特有的（专用）名次/和术语并给出符合实际情况的解释说明；编写格式如下：中文全称中文简称英文全称英文简称解释说明三、用户环境描述3.1、用户单位组织结构编写信息：利用表格或框图（建议）形式画出委托单位的组织结构图；应包括委托单位的所有 分支结构和部门名称，以及各个分支机构/部门间的上下级关系。3.2、用户部门设置与职责编写建议：按业务组织结构划分成不同的职责部门或分支机构， 分别对每个部门或分支机构 进行描述。描述

8、的内容包括：1、用户组、分支结构或部门的名称2、每个用户组、分支结构或部门的描述，主要描述他们的职责，及用户组或分支结构/部门的考核指标;3、每个用户组、分支结构或部门相关人员的职责，及考核指标 可以使用下面的格式，也可以根据实际的需要使用其他格式 例如：用户组/机构/部门名称职责描述考核指标备注3.3、用户业务关系描述编写建议：以关系图的方式加文字说明的方式，描述该软件系统所计划完成的系统业务，以 及该业务在内部的工作流情况，还有该业务的相关部门的接口情况。注意本图示需要表明业 务关联关系而非数据关联关系。3.4、系统面向的用户群（例如计算机操作编写建议：描述该系统建设以后的目标用户群体以及

9、他们的专业知识水平 能力、财务知识水平等）、各类用户的主要使用内容和工作职责等。3.5、关键计算机资源编写建议：列出该软件所涉及到的所有部门和机房的软硬件资源情况、设备要求等;3.6、用户环境中的其他应用系统分布编写建议：列出该软件所涉及到的用户环境中的其他所有应用系统的分布情况；应该包括:1、其他应用系统的名称；2、责任部门；3、应用系统功能概述；4、部署的服务器以及机房；5、其他认为应该包括的信息四、功能性需求描述4.1、用户各部门当前的工作模式编写建议：该章节描述调研过程中发现的，客户业务实际的操作情况，建议以表格、流程图 等形式进行说明。并且按照如下列出的格式分部门分层面进行描述：4.

10、1.1、部门一部门名称 4.1.1.1、工作内容编写建议： 描述该部门之前（未用软件进行工作管理）的主要工作内容和工作职责。4.1.1.2、工作流程编写建议： 描述该部门相关工作的处理流程，建议以流程图形式进行描述；4.1.1.3、 涉及到的表单编写建议： 描述该部门各项工作处理过程中， 可能涉及到的各种单据， 描述的内容应包含如 下信息：1、每项单据的名称和用途；2、单据流转的流程；3、单据牵涉到的相关人员；4、单据的标准填写格式。 建议提供相关单据的附件。4.1.1.4、 与其他部门的关系 编写建议：描述该部门各项工作在执行处理过程中可能会牵涉到的其他部门， 以及其他部门 的处理内容；4.

11、1.1.5、 存在的问题 编写建议：描述该部门各项工作之前执行过程中存在的各项问题； 以及为什么要用软件管理 的方式来体改之前的执行操作方式。4.1.2、部门二参考部门一 4.13部门N参考部门一 4.2、构建该系统的目标编写建议：介绍本软件系统的建设目的， 从用户的角度描述该系统建立后应该达到的预期目标。可以从以下几个方面进行描述：4.1.4、 管理目标编写建议： 描述客户领导层 / 管理层对本软件系统的建设要求： 例如：1、客户希望该系统建立后能在管理上、业务流程上规范解决的问题；2、希望能够通过该软件系统达到什么样的使用效果和目标；3、系统该软件系统能出什么报表数据，或者用该软件系统能提

12、高哪些工作效率等等；4.1.5、 使用目标编写建议： 对具体业务上来说， 客户系统通过该系统能够实际解决的问题。 该内容的编写应 参考具体每个使用部门的意见。4.1.6、业绩目标编写建议： 描述该软件系统上线应用后计划实现的业绩目标： 例如：1、减少多少行政办公时间工作时的计算；2、减少多少办公耗材资源的计算；3、对行政效率提升的具体计算；4、对数据统计效率提升的具体计算；5、对产能提高的具体计算；6、其他4.3、功能结构图编写建议： 描述软件系统中各个模块以及模块下功能 / 子模块的划分；整体展示系统中所具 备的功能模块，以及各个模块之间的关联情况。建议以结构图的形式进行描述；该功能结构图仅

13、描述客户对功能模块的意向需求， 而不是根据客户需求分析后的功能模 块设计。4.4、功能点需求编写建议： 该章节描述调研过程中发现的，客户对软件具体功能点的要求，建议以表格、流程图加文字的形式进行说明，按照不同的功能点进行列举方式描述。格式建议如下：4.4.1、功能点一4.4.1.1、 业务描述编写建议： 描述该功能点实际处理的业务情况，以及在这个业务中应该注意的细节、要点 , 以及工作目标等等。4.4.1.2、 用例及关键数据编写建议： 以用例图加文字说明的形式， 呈现该业务所有参与者及其用例的执行过程， 以及 他们之间的关系，还应该包括每个用例所涉及处理的数据以及所涉及到的单据。4.4.1.

14、3、业务流程图编写建议： 以流程图加文字说明的形式， 描述该功能点的业务流程， 明确各个业务流程的节 点，对象和内容。4.4.1.4、 与其他功能点的关系编写建议： 描述该功能点与其他功能点的关系， 例如需要从其他功能模块调去数据， 根据其 他功能点的执行结构进行条件判断处理等等。4.4.1.5、 子功能点编写建议： 描述该功能点可能存在的子功能点， 以便对整体功能进行更加明确的划分； 格式 直接参照上面的四项内容即可。4.4.2、功能点二参考功能点一 443功能点N参考功能点一 4.5、接口需求编写建议： 描述该软件所涉及到的内部接口和外部接口需求。4.5.1、内部接口需求编写建议：描述各个

15、模块或者功能点之间的业务接口， 可以采用图表加文字的方式进行展示； 每个接口间列出详细的接口要素及其说明。4.5.2、外部接口需求 编写建议：描述该软件系统与其他软件系统之间的业务接口， 可以采用图表加文字的方式进 行展示；每个接口间列出详细的接口要素及其说明，并且对具体的调用方式进行描述。五、非功能性需求描述5.1、系统环境需求编写建议：描述客户方对软件系统的系统环境需求， 即客户要求在什么样的环境下使用该系 统；包括网络环境、人员环境、使用频率和周期等等。5.2、易用性和用户体验需求编写建议：描述客户方对软件系统在易用性和用户体验方面的需求， 例如客户对界面布局的要求，对软件各项表单操作提

16、醒的要求、对帮助文档的要求等等。5.3、软硬件技术需求编写建议： 描述客户方对该软件系统开发和部署方面的软硬件环境和技术的要求： 例如：1、软件开发过程中使用到的开发语言、基础框架等；2、软件开发和部署的操作系统、 WEB 浏览器等方面的要求；3、软件部署的硬件服务器的性能配置要求等；4、其他认为应该包含的信息5.4、安全性需求编写建议： 描述客户方对该软件在安全方面的要求； 例如：1、数据库安全性；2、备份和容灾策略；3、数据出错时的回滚机制；4、系统安全性；5、密码安全性；6、防止XSS和SQL注入攻击等；7、其他认为应该包含的信息 5.5、可维护性需求编写建议： 描述客户方或者我方维护人

17、员对该软件系统在可维护性方面的需求。 例如：1、 远程维护的需求；2、备份的需求；3、对系统维护的要求（对管理人员专业水平的要求）等；4、其他认为应该包含的信息5.6、对培训的需求编写建议： 描述客户方和我方实施 / 售后人员对该软件系统在培训方面的需求。 例如：1、对客户方领导的培训；2、对客户方管理人员 / 系统管理员的培训；3、对客户方普通操作人员的培训；4、对我方技术实施和售后人员的培训；5、其他认为应该包含的信息 六、其他6.1、软件应当遵循的标准或规范编写建议： 列出本软件在需求调研和分析、设计以及开发等过程中应当遵循的各项规范 例如：1、本软件所涉及到的行业在该软件所涉及到的业务

18、领域的相关行业执行标准；2、国家在该软件所涉及到的业务领域的相关法律法规和执行标准；3、客户方自身对于软件所涉及到的业务领域的管理制度和错误以及相关标准；4、其他同类型软件产品的相关规范和定义；5、本次软件研发所应该遵循的标准 /规范/ 要求等等；6、其他认为应该包含的资料 列出所有的参考资料文档（可以是非正式出版物） ，格式如下：标识符 作者，文档名称，出版单位（或归属单位），日期6.2、定义、首字母缩写词和缩略语编写建议： 记录在需求调研过程中所记录 / 识别的所有专业词汇和缩略语 （可能和业务无关 的），并给出解释说明。格式如下：-可编辑修改 -缩写、术语解释说明6.3、附件631、用户需求调研表需求标题：调查方式：访谈电话邮件即时通讯调查人：调查时间：调查地点：参加人员：调研内容：取得的原始材料：调查人签字：客户代表签字：632、参考文档资料编写建议：本处用于附加在“1.4、参考资料”和“ 6.1、软件应当遵循的标准或规范”中所 设计到的所有资料和文档。-可编辑修改-Welcome ToDownload !欢迎您的下载，资料仅供参考！