《项目需求开发用户需求报告》由会员分享，可在线阅读，更多相关《项目需求开发用户需求报告（11页珍藏版）》请在金锄头文库上搜索。
1、项目名提示：项目名称：项目番号 项目名称用户需求报告版本：0.0.0xxxxx 股份有限公司文件状态：文件标识：用户需求报告草稿当前版本：0.0.0V 正式发布作者：正在修改完成日期：修改履历版本修订日期修改内容作者0.0.02008-1-15初版邵峰0.0.02008-3-25邵峰目录1.概述31.1 用户简介31.2 项目的目的和目标31.3项目的范围41.4术语定义41.5参考资料42总体描述42.1组织机构与职责42.2岗位定义52.3业务流程52.4 报表52.5 存在的问题62.6可能的变化63 功能需求74 界面与接口需求84.1 用户的界面需求84.2 外部的接口85 性能需求
2、85.1 时间要求85.2 空间与数值性能96 其他需求96.1系统的安全性96.2系统的可靠性96.3系统的灵活性96.4其他97 假设与约束条件10附件 1：待定问题列表111. 概述1.1 用户简介在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围 进行关于功能与进度、成本、性能等方面的平衡决策。基本情况举例：企业性质规模（员工数量、经营业绩等）所在行业地理位置与布局产品或服务的种类管理模式用户使用计算机系统的经历1.2 项目的目的和目标项目目的是开发本系统的意图的总概括，项目目标总体概况细化后的具体的 描述，项目目标应是明确的、可度量的、可以达到的 ,项目的范围应能确保项
3、目 的目标可以达到。对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统 的功能是否覆盖了系统的目标。在本章节的描述忌使用“开发一套让用户满意的系统”等字句，“让用户满 意”的系统是难以度量的，是项目风险的主要来源。项目的目标举例： 人力与设备费用的减少 处理速度的提高 管理信息服务的改进 人员利用率的改进 控制业务中的薄弱环节 解决人力难以解决的计算问题A .1.3 项目的范围项目范围是开发本系统设计的业务、部门、功能以及实现这些业务功能的程 度。1.4 术语定义将该用户需求报告中的术语、缩写进行定义,包括用户应用领域与计算机领 域的术语与缩写等。 如:A 系统缩写A 专有名词
4、A . 1.5 参考资料说明该用户需求报告使用的参考资料，如：A 用户领域的资料A 参照的标准A . 每一个文件、文献要有标题、索引号或文件号，发布或发表日期以及出版单 位。2 总体描述2.1 组织机构与职责将用户的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每 个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载 体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组 织机构，是需求获取步骤中的基础工作之一。2.2 岗位定义用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解企业业 务的基础，是需求获取的基础工作，同时也是分析人员提取对象的
5、基础。每个岗 位的职责可以进行详细的描述，建议采用表格的形式：2.3 业务流程企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关 系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。 业务流程最好采用泳道图的形式。图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务 发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的 内容，需要用文字进行详细描述。2.4 报表现行系统中用户正在使用的正式的或非正式报表等可以收集起来，在此章节 中进行穷举、分类、归纳。报表是用户系统中信息的载体，是进行系统需求分析 的基础，无论采用哪种分析方法
6、，这都是必不可少的信息源。可以将报表的格式画在这里，也可以将原始的材料做为本文档的附件。特别 需要对这些信息源中的每个具体的信息项进行详细说明，如: 类型 长度 小数精度 来源 信息项之间的计算关系 计算时的取舍规则（如四舍五入、取整等） 报表发生的频度、高峰期的频度 2.5 存在的问题在现行的系统中，从决策层、管理层、操作层各存在哪些方面的问题需要计 算机来解决，尤其是决策层、管理层这些问题中包含了用户的需求与期望，有些 问题是新系统可以解决的，有些问题则不是。系统中的问题举例： 业务量太大，处理速度太慢 存在漏洞，给恶意者以可乘之机 对帐太麻烦，查找速度太慢 月底报表工作量太大 操作烦琐
7、2.6 可能的变化对于现行的系统，将来可能会有哪些变化，需要在此章节中描述。企业中的 变化是永恒的，系统分析员需要描述哪些可能引起系统范围变更的变化。变化举 例： 某部门撤销、合并、新增 业务流程改变 处理方法改变 管理的细度加强，增加了信息 本章的裁剪问题： 如果对于所开发系统不适合，可以进行裁剪。本章节最简单的描述形式为： 系统的客户系统的用户使用场景 当前系统存在的问题 可能的变化。3 功能需求在本章节中描述用户的功能需求。主要的要求：（1）功能需求是用户的最主要的需求，对用户需求的描述可以采用文字描述 也可以采用语言+图形的描述方式，只要能够将用户的需求描述地完整、 准确、易于理解即可
8、。描述方式举例： 自然语言 use case 图+use case （2）对功能需求比较复杂的系统（如超过 10个功能项），可以先描述一个概 要，对简单的系统可以直接进行详细描述。（3）对于用户的功能需求要进行分类，分类的方法应便于用户理解，如按照 用户的部门设置情况，进行描述每个部门的需求，这样也便于组织用户 进行评审。以下是分类方法的举例： 按部门分类：如计算机中心、市场部、计划建设部、客户服务中心、 财务部、总经理等； 按功能类型分类：如采集计费、综合统计、结算、营收等；对功能需求的分类在不同的层次可以采用不同的方法。（1）对每一项功能应有一个功能编号，以便于与需求规格说明书中的章 节进
9、行对应。（2）按客户层次进行标注。（3）客户的需要：指系统必须实现的客户的需求，如：业务方针，标准，业 务环境需求，技术，继承的产品和产品构件。（4）客户的期望：指系统中可以不实现的客户的需求，如果实现，则是锦上 添花。（5）对每一项功能的描述，应指明用户的输入（input）、处理方法（process ）、 系统的输出（output）及对此项功能的其他要求。（6）功能需求应注明使用此功能的岗位。对系统管理员要求的特殊功能可以 在此注明，非特殊要求可以在需求分析规格说明书中详细论述。如用户 权限可分级，要有操作日志等。（ 7） 在功能需求的描述中，对于类似的、统一的功能可以单独地进行详细描 述，
10、其他地方进行引用，或作为术语进行定义，以简化文档，减少重复。 如； 录入功能 打印功能 条件查询功能 排序功能 4 界面与接口需求4.1 用户的界面需求界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义 某些功能模块的特殊的界面要求。显示风格：图形界面、字符界面、IE界面等；显示方式： 1024*768、 640*480 等； 输出格式：显示布局、打印格式等。 裁剪原则：可以使用界面原型替代。4.2 外部的接口与其他系统的接口等。 与系统特殊外设的接口，如写码机、条码扫描器、扫描仪等。 应在此列举出所有的外部接口、接口标准、规范。5 性能需求5.1 时间要求 响应时间，如查询的
11、最长等待时间。 更新处理时间，如出帐的最长时间。 数据的转换和传送时间，如远程数据传输的时间要求。 5.2 空间与数值性能如： 支持的终端数； 支持的并行操作的使用者数； 处理的文件和记录数； 表和文件的大小规模（要按可预见的增长对数据及其分量的存储要 求作出估算）； 处理和任务的数量； 在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据 总数； 对输入和输出数据的精度要求； 对处理和传输过程中的精度要求； 6 其他需求6.1 系统的安全性6.2 系统的可靠性6.3 系统的灵活性6.4 其他如： 进度需求：系统的阶段进度要求； 运行环境需求：平台、体系结构、设备要求； 培训需求：用户对培训的需求，如是否提供多媒体教学光盘； 推广需求：推广的要求，如在上百个远程的部门推广该系统，是否 要有推广的支持软件。7 假设与约束条件假设与约定条件是预计的对系统风险的描述,如： 法律、法规和政策方面的限制 硬件、软件、运行环境和开发环境方面的条件和限制 可利用的信息和资源 系统投入使用的最晚时间 附件 1：待定问题列表编号优先级需求来源需求描述初步实现计划需要的配合
