总体需求规格说明书范例.doc

(完整word)总体需求规格说明书范例【项目名称】需求股(文档版本号:V1.)XXXX有限公司XXXX年XX月修订历史版本号更新日期修订作者主要修订摘要0。12009-425刘波初始文档生成.目 录1。综述41.1文档说明41.2编写目的41。3适用范围41。4名词、术语、缩略语定义51。5参考资料52。项目概述52。1项目背景52.2项目目标53.需求调研的目标64.需求调研的思路64。1调研的核心问题64。2围绕的关键点74。3业务调研访谈思路74。4现有系统调研思路75.需求调研的方式76.需求调研的内容86.1功能分类调研内容86。1.1功能性需求调研86.1.2非功能性需求调研86.2业务分类调研内容86。2。1对信息部门的调研内容86.2。2对业务部门的调研内容97.需求调研使用表格98。调研访谈时间安排129.需求调研成果提交13概述目的说明编写这份报告的目的，指出预期的读者。背景指出待开发的软件系统的名称;行业情况；本项目的提出背景、任务提出者、开发者、用户;该软件系统同其他系统的相互关系。参考资料列出编写本报告时参考的文件（如经批准的计划或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。编号资料名称简介作者日期出版单位列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。网点简介术语和缩略语列出本报告中用到的专门术语、缩略语的定义，对于重要的或是有特殊意义的名词进行解释。任务概述目标叙述该项软件开发的意图、应用目标、作用范围.解释被开发软件与其他有关软件之间的系.项目产品体系结构图说明本项目产品与其它产品的关系,可以用图表的形式。比如，本项目产品是否是一个大的产品的组成部分，是否要替换已有的产品，或者是一个独立的产品。如果与其它产品有关系，它们之间的关系要在此描述。项目产品功能描述说明项目产品必须具备的主要功能（仅作简单介绍）.如果使用了建模技术，用高层的数据流图或用例图（Use Case Diagram）来描述会更加有效。系统特点如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处,与市场上同类软件（如果有的话）的比较。如果是针对合同开发，则应列出本软件的最终特点。约束条件用户情况介绍本项目的用户（或潜在用户）的情况，包括：1 用户的技术水平；2 最终使用部门、技术支持部门、参与测试验收的部门；运行环境说明项目产品将在什么样的环境下操作,包括硬件平台、操作系统及版本、必须安装的软件部件和应用软件等.硬件环境列出满足系统需求所必须的最低硬件配置、推荐硬件配置(如主机、显示器、存储设备、外部设备等)以及其它特殊设备。或列出用户期望或现有的设备环境。以及与其他系统的硬件接口。软件环境列出满足系统需求或用户期望或现有的操作系统、网络软件、数据库系统、中间件以及其它特殊软件要求.以及与其他系统的软件接口。限制条件描述项目产品可能存在的限制条件以及与其它受影响的组和个人的约定，包括硬件条件、软件限制、交付产品、人力资源、交付日期、里程碑等。举例:项目产品必须在IBM PC或100兼容的计算机上运行，计算机最低内存64M、最小硬盘空闲空间10G。操作系统是WIN2000及更高版本.软件源代码必须用C/C+编写。假设和依赖列出所有会影响项目需求实现的假设因素（相对于已知的事实而言）。例如，本项目产品计划要使用某些第三方软件产品或商业软件产品,虽然目前还未得到这些软件,但我们可以假设这些软件一定能够得到。如果这些假设不正确、或发生改变，会影响项目的开发，因此，这些假设往往又是一种风险。如果项目的开发或项目产品的使用要依靠其它外部因素,比如与其它产品共用的软件包、准备重用的软件构件等，也要在此说明.用户原系统情况如果用户存在原有系统，介绍用户原来使用系统的主要情况,包括主要的不足。如果用户不存在或不关心原有系统，本章节可省略。运行环境用户存在原有系统的运行环境。体系结构用户存在原有系统的体系结构。业务处理方式用户存在原有系统的业务处理方式。系统特点用户存在原有系统的特点.业务流程描述系统实现的业务流程，包括角色、业务处理过程。功能需求功能需求1（以实际的需求名代替）简要描述简明描述该需求点的作用和目的。事件流程描述参与者的操作和系统的响应，重点指明需要做什么事情，而不是如何完成这些事情。基本流程描述正常情况下的处理流程。异常流程描述异常情况下的处理流程特殊需求描述用户要求的不符合流程的要求.前置条件描述触发该事务的必要条件.后置条件描述该事务完成时,必需满足的条件。功能需求2（以实际的需求名代替)按照需求1的格式依次描述，直到所有的需求。数据描述描述系统输入、输出涉及的数据情况说明，如外部数据接口、界面展示或打印的数据、表项等。非功能需求适用性需求描述系统被预想的不同级别用户（如文盲用户、初学者、普通用户、高级用户等）的学习和可操作能力。建议从以下方面（不限于）进行描述：指明为了使用户能够完成简单任务以及完成普通日常工作所需要的培训时间;指明典型终端用户可能的典型任务的可度量时间;比较新系统与目前用户团体熟悉的或正在使用的系统的适用性；指明是否制作在线帮助系统、向导、工具说明、用户手册以及其它形式的文档和帮助，以及所需特征；人机界面开发的要求或规范。可靠性需求描述用户能够接受的或期望系统运转程度,建议从以下几个方面(不限于）阐述： 可用性:如58,724; 平均修复时间； 准确性； 最大错误或缺陷率（如:错误数/千行代码）； 错误分类原则; 故障处理原则。安全性需求描述客户要求的或者应该满足的安全性.性能需求性能需求通常包括以下几类（不限于）: 事务的响应时间或效率：平均值、最大值； 吞吐量：每秒事务数； 容量：系统可容纳的客户总数或事务总数； 数据精度; 容错能力; 可恢复能力； 退化模式：当系统被降级时，可接受的运转模式。可支持性需求可支持性是指为了升级或修复，软件的被修改能力。即对系统设计的灵活性和拓展性的要求。辅助部分未确定问题说明目前尚未确定的问题及处理的计划。需求的优先级将所有的功能需求或用例（如果需求分析结果是使用用例),按高、中、低的优先级分类。列出章节号即可，例如6。2需求2(以实际的需求名代替）功能需求/使用用例优先级高/中/低对高、中、低的解释如下：优先级解释高关键的功能，必须在本次项目开发中实现。中增强性功能，可以在下一个项目版本中实现.低功能或性能的提高，属于美化性质的功能，如果有时间，可以实现.开发成本估算以列表的方式估算出各功能需求所需的开发人时和费用。功能需求/用例工时费用风险分析根据需求，分析风险。包括,需求可实现性、需求变动、时间压力、技术复杂度、人力资源不足等。功能需求/用例风险风险级别高/中/低遵循的法律法规变更记录序号修改单号页号条款号修改人/日期批准人/日期实施日期注:对该文件内容增加、删除或修改均需填写此变更记录,详细记载变更信息，以实现追溯。