用户需求分析报告.docx

文件编号：ZH_CJ_XX_XX_BG_2012XXXX_VX北京市轨道交通指挥中心二期工程ACC生产系统扩容、TCC系统扩容、信息中心系统工程子项目名称需求分析报告总页数正文附录生效日期编制批准变更履历修改编号版本修改内容修改人修改日期目录1简介11.1目的11.2范围11.3参考资料11.4概述12相关干系人信息13用户需求23.1系统定位23.1.1用户面临的问题23.1.2系统定位说明23.2系统范围23.3系统用户信息23.4系统功能及业务流程33.5系统运行环境33.5.1系统环境33.5.2支撑系统环境33.6约束43.6.1政治约束43.6.2经济约束43.6.3环境约束43.6.4技术约束43.6.5可行性约束43.6.6系统约束43.7质量属性需求43.8文档需求43.8.1联机帮助43.8.2系统安装手册、配置文件、自述文件44附录51 简介此文档的目的是收集、分析和定义系统的高层次需求和特性。它侧重于相关干系人和目标用户所需的功能以及这些需求存在的原因。需求文档的简介应提供整个文档的概述。它应包括此需求文档的目的、范围、术语、首字母缩写词、缩略语、参考资料和概述。文档的蓝色提示性语言请在报告完成时删除。1.1 目的说明用户需求分析报告的目的。1.2 范围简要说明此需求文档的范围：它的相关项目，以及受到此文档影响的任何其他事项。1.3 参考资料本小节应完整列出此需求文档中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。1.4 概述此小节应说明需求文档中其他部分所包含的内容，并解释此文档的组织方式。2 相关干系人信息为有效地提供可满足相关干系人实际需要的产品和服务，有必要在用户需求分析过程中确定并包括所有相关干系人，及其对应的系统的用户，确保相关干系人能够充分代表这些系统用户。 相关干系人可能会有许多不同的类型，例如用户、策略部门和技术开发人员等等。用户也可能有许多不同的类型，例如专业用户和入门用户等。专业用户可能会需要复杂、灵活并具备跨平台支持的工具；而入门用户则会需要使用方便、界面友好的工具。此处提供所有已确定的相关干系人类型的一览表。序号相关干系人类型相关干系人类型说明系统用户3 用户需求3.1 系统定位简要说明待建系统面临的商机，可以解决的业务问题，能够达到的业务目标，高度概括待建系统将要在市场上占据的位置。3.1.1 用户面临的问题提供一段说明，总结此项目需要解决的问题(这里的问题指用户面临的问题，是需求的来源)。可以采用以下格式；如果使用表格不方便描述，可以用文字的形式描述问题，但需要突出说明影响范围及解决问题的价值。根据项目情况，这里可以只列出关键问题。序号问题描述影响范围解决价值3.1.2 系统定位说明产品定位说明用于向所有相关人员传达应用程序的目的和项目的重要性。此处提供一段总体说明，高度概括产品将要在市场上占据的独特位置。如：针对于（目标用户）的（说明需要或机会）要求 ，该（产品名）属于（产品类别），（陈述主要优点，即促使人们购买的原因）功能不同于（主要的竞争产品），我们的产品（陈述主要的区别）。（）内为需要填写的内容，最后形成完整通顺的语言。3.2 系统范围本节将系统放在其他相关系统环境和用户环境中进行介绍。如果该系统自成一体，应在此处说明。如果该系统是较大系统的组件，此节则应说明这些系统如何进行交互，并确定系统之间的相关接口。要显示较大系统的主要组件、互连情况和外部接口，给出系统的边界图。3.3 系统用户信息本节说明系统的所有用户的信息。画出系统用户关系图（可选），然后依次介绍各个用户，说明用户的名称，职责，权限。序号名称职责权限3.4 系统功能及业务流程本节说明系统的功能及其业务流程，这里推荐画出业务流程图，然后结合流程图，参考下表说明每条需求，包括：需求标识、需求分类、需求描述、需求优先级及相关需求。项目组可根据实际情况确定适合的需求标识原则。业务流程描述记录在“需求描述”中，包括：功能性描述；性能描述；数据描述；业务规则等。优先级是指调研时用户指定的需求优先级。相关需求可以填写相关的需求标识根据用户需求，业务流程图和需求描述表格可以是多个，也可以采用分册的形式进行描述需求标识需求分类用户需求描述优先级相关需求项目自定义，建议采用两级以上的标识，如*00-000，其中*用英文字母表示用户需求的含义，00-000表示需求的序号项目自定义，建议从用户的业务角度分类，如对于一个银行取款系统应该有：储户/柜台/管理/服务等需求分类功能性描述；性能描述；数据描述；业务规则等高中低相关需求标识3.5 系统运行环境3.5.1 系统环境根据需要详细说明环境需求。对于软件应用系统，环境因素可以包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。3.5.2 支撑系统环境确定支持该应用程序所必需的任何系统需求。其中可能包括所支持的主机操作系统及网络平台、配置、内存、外围设备和配套软件。3.6 约束记录所有设计约束、外部约束或其他依赖关系。根据实际业务需要，如果没有以下分类约束可以删除该分类。3.6.1 政治约束说明影响系统运行的潜在的组织内部或外部的政治问题，如同业竞争回避等问题。3.6.2 经济约束说明财务或预算方面的约束。3.6.3 环境约束说明环境、规章制度、行业标准或法律等方面的约束3.6.4 技术约束说明技术方面的限制3.6.5 可行性约束3.6.5.1 时间约束说明项目及各相关干系人的时间约束，如相关干系人提供依赖的时间，最重要的是产品的理想发布时机。3.6.5.2 资源约束说明开发产品的资源约束（人员、设备、开发工具、技术支持等）。3.6.6 系统约束说明是否与现有系统的兼容，平台方面的限制等3.7 质量属性需求这里的质量属性主要来自用户的原始需求，可以是：正确性要求、可靠性要求、健壮性要求、性能要求、易用性要求、可移植性要求、互操作性要求、可重用性要求、可扩展性要求、安全性要求和可维护性要求等。3.8 文档需求此节说明用户的文档需求，根据业务需要，以下文档说明可以增、删、改。3.8.1 联机帮助许多应用程序提供了联机帮助系统来协助用户。这些系统的性质对于应用程序开发来说独特的，因为它们综合了编程（如超链接）和技术写作（组织、演示）的各个方面。3.8.2 系统安装手册、配置文件、自述文件在提供全套的解决方案时，提供包括安装说明和配置指南的文档是非常重要的。此外，自述文件通常也要作为一个标准构件包括在内。自述文件可以包括一个“本发布版中的新特性”部分，并讨论与以前发布版的兼容性问题。多数用户也希望在自述文件中列出任何已知的错误和变通方法。4 附录附上收集、整理的所有“需求调研卡”及“需求调研提纲”。