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

. .XXXX技术XX公司名称XXXX公司客户名称XXXX软件工程工程或产品名称需求调研报告文件信息文件状态： 草稿文件 正式文件 更改正式文件当前版本：V1.0.0 完成日期：文档编号：文档标题：软件工程需求调研报告文档类别：提交人员：文件名：文件摘要：工程名称：当前阶段：需求调研阶段所有：. .word.zl. .修改历史日期版本作者修改容评审号更改请求号2021 -06-29V1.0.0虎定义文件模板. .word.zl. .目录文件信息1修改历史2目录2一、引言21.1、编写目的21.2、文档围21.3、预期读者和阅读建议21.4、参考资料2二、工程描述22.1、工程背景22.2、工程名称22.3、工程概述22.4、工程关联性22.5、设计和实现上的限制22.6、假定和约束22.7、名词/术语解释2三、用户环境描述23.1、用户单位组织构造23.2、用户部门设置与职责23.3、用户业务关系描述23.4、系统面向的用户群23.5、关键计算机资源23.6、用户环境中的其他应用系统分布2四、功能性需求描述24.1、用户各部门当前的工作模式24.2、构建该系统的目标24.3、功能构造图24.4、功能点需求24.5、接口需求2五、非功能性需求描述25.1、系统环境需求25.2、易用性和用户体验需求25.3、软硬件技术需求25.4、平安性需求25.5、可维护性需求25.6、对培训的需求2六、其他26.1、软件应当遵循的标准或规26.2、定义、首字母缩写词和缩略语26.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.