用户需求编写指导书删节版.docx

1、用户需求编写指导书删节版密级： 用户需求指导书网络优化与设计中心软件开发项目组二一年八月二十七日目 录1. 概述 31.1 编写目的 31.2 用户简介 31.3 项目的目的与目标 31.4 术语定义 41.5 参考资料 41.6 设计与实现的限制 52. 现有系统的描述 52.1 组织机构与职责 52.2 岗位定义 52.3 作业流程 62.4 报表 62.5 存在的问题 62.6 可能的变化 73 功能需求 74 界面与接口需求 84.1 用户的界面需求 84.2 外部的接口 95 性能需求 95.1 时间要求 95.2 空间与数值性能 96 其他需求 106.1 系统的安全性 106.2

2、 系统的可靠性 106.3 系统的灵活性 106.4 其他 101. 概述1.1 编写目的为了使用户与开发人员之间相互了解，对用户需求进行明确定义，使之成为整个开发工作的基础，并提供一个软件系统度量和遵循的基准。该文件可作为前期帮助用户制定适宜的用户需求说明书及后期用于确认软件产品是否满足给定需求的验收标准。 1.2 用户简介在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行关于功能与进度、成本、性能等方面的平衡决策。基本情况举例： 部门性质 规模（员工数量、经营业绩等） 业态 现有维护业务及归属地 维护类别或维护的种类 管理模式 用户使用计算机系统的经历 .1.3 项目的

3、目的与目标项目目的是开发本系统的意图的总概括，目标是将目的细化后的具体的描述，项目目标应是明确的、可度量的、可以达到的,项目的范围应能确保项目的目标可以达到。对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统的目标。在本章节的描述忌使用“开发一套让用户满意的系统”等字句，“让用户满意”的系统是难以度量的，是项目风险的主要来源。项目的目标举例： 人力与设备费用的减少 提高现阶段维护效率 整合基础信息 处理速度的提高 管理信息服务的改进 人员利用率的改进 控制业务中的薄弱环节 解决人力难以解决的计算问题 .1.4 术语定义将该用户需求说明书中的术语、缩写进行定义

4、,包括用户应用维护领域与计算机领域的术语与缩写等。 如: 系统缩写 专有名词 通信术语 维护术语 .1.5 参考资料说明该用户需求说明书使用的参考资料，如： 用户领域的资料 参照的标准 .每一个文件、文献要有标题、索引号或文件号，发布或发表日期以及出版单位。1.6 设计与实现的限制可能的限制包括如下内容： 必须使用或避免的特定技术、工具、编程语言和数据库； 用户虽然没有明示，但规定的用途或已知的预期用途所必需的限制； 所要求的开发规范或标准（如，软件维护后期若以第三方进行，就必须定义转包者所使用的设计符号表示和编码标准）； 硬件限制，如定时需求或存储器限制； 数据转换格式标准。2. 现有系统的

5、描述2.1 组织机构与职责将网络维护部的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个业务部门的职责也应进行简单的描述。组织结构是业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织机构，是需求获取步骤中的基础工作之一。2.2 岗位定义用户环境中的岗位或角色，和组织机构一样，也是分析人员理解业务的基础，是需求获取的基础工作，同时也是分析人员提取对象的基础。每个岗位的职责可以进行详细的描述，建议采用表格的形式：岗位所在部门职责相关的业务 对用户角色的识别也包括使用了计算机系统后的系统管理和维护人员。2.3 作业流程企业的作业流程首先要有一个总的

6、业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的内容，需要用文字进行详细描述。2.4 报表用户正在使用的正式的或非正式报表等可以收集起来，在此章节中进行穷举、分类、归纳。报表是用户系统中信息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。可以将报表的格式画在这里，也可以将原始的材料作为本文档的附件。特别需要对这些信息源中的每个具

7、体的信息项进行详细说明，如: 类型 长度 小数精度 来源 信息项之间的计算关系 计算时的取舍规则（如四舍五入、取整等） 报表发生的频度、高峰期的频度 .2.5 存在的问题在现行的管理体制中，从决策层、管理层、操作层各存在哪些方面的问题需要计算机来解决，尤其是决策层、管理层这些问题中包含了用户的需求与期望，有些问题是新系统可以解决的，有些问题则不是。系统中的问题举例： 业务量太大，处理速度太慢 存在漏洞，给恶意者以可乘之机 对帐太麻烦，查找速度太慢 月底报表工作量太大 操作烦琐 .2.6 可能的变化对于现行的系统，将来可能会有哪些变化，需要在此章节中描述。企业中的变化是永恒的，系统分析员需要描述

8、哪些可能引起系统范围变更的变化。变化举例： 某部门撤销、合并、新增 业务流程改变 处理方法改变 管理的细度加强，增加了信息 .3 功能需求在本章节中描述用户的功能需求。主要的要求：（1） 功能需求是用户的最主要的需求，对用户需求的描述可以采用文字描述也可以采用语言+图形的描述方式，只要能够将用户的需求描述地完整、准确、易于理解即可。描述方式举例： 自然语言 use case图（推荐） .（2） 对功能需求比较复杂的系统（如超过10个功能项），可以先描述一个概要，对简单的系统可以直接进行详细描述。（3） 对于用户的功能需求要进行分类，分类的方法应便于用户理解，如按照用户的部门设置情况，进行描述每

9、个部门的需求，这样也便于组织用户进行评审。以下是分类方法的举例： 按维护业务分类：如基站维护、线路维护、传输设备维护等 按功能类型分类：如成本计算、材料消耗、结算等； .对功能需求的分类在不同的层次可以采用不同的方法。（4） 对每一项功能应有一个功能编号，以便于与产品需求规格说明书中的章节进行对应。（5） 对每一项功能的描述，应指明用户的输入(input)、处理方法（process）、 系统的输出(output)及对此项功能的其他要求。（6） 功能需求应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在此注明，非特殊要求可以在产品需求规格说明书中详细论述。如用户权限可分级，要有操作日志等。

10、（7） 在功能需求的描述中，对于类似的、统一的功能可以单独地进行详细描述，其他地方进行引用，或作为术语进行定义，以简化文档，减少重复。如； 录入功能 打印功能 条件查询功能 排序功能 .4 界面与接口需求4.1 用户的界面需求界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义，某些功能模块的特殊的界面要求。显示风格：图形界面、字符界面、IE界面等；显示方式：1024*768、640*480等；输出格式：显示布局、打印格式等。4.2 外部的接口与其他系统的接口等。与系统特殊外设的接口，如打印机、条码扫描器、扫描仪等。应在此列举出所有的外部接口、接口标准、规范。5 性能需求5.1

11、时间要求 响应时间，如查询的最长等待时间。 更新处理时间，如出账的最长时间。 数据的转换和传送时间，如远程数据传输的时间要求。 .5.2 空间与数值性能 如： 支持的终端数； 支持的并行操作的使用者数； 处理的文件和记录数； 表和文件的大小规模（要按可预见的增长对数据及其分量的存储要求做出估算）； 处理和任务的数量； 在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数； 对输入和输出数据的精度要求； 对处理和传输过程中的精度要求； 6 其他需求6.1 系统的安全性指保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。个别领域的具体需求必须包括： 要求利用的密码技术； 要

12、求对特定的记录或历史数据集的保护方法； 对某些特定的功能的访问权限的限定； 对某些数据的加密传输要求。6.2 系统的可靠性指定一些因素，如检查点、恢复和再启动等，以保证整个系统可用性。6.3 系统的灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如操作方式上的变化，运行环境上的变化，同其他软件的接口变化，精度和有效时限的变化，计划的变化或改进。对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。6.4 其他如： 进度需求：系统的阶段进度要求； 运行环境需求：平台、体系结构、设备要求； 培训需求：用户对培训的需求，如是否提供多媒体教学光盘； 推广需求：推广的要求，如在多个部门推广该系统，是否要有推广的支持软件。