ZD-软件需求规格说明书-ProductID-Vxx.doc

软件需求规格说明书Version 1.0Document Lending Record Name of Document：Signature of Borrower：Date of lending：Instructions of Principal of Document:Date:Date of Repayment：Signature of Document controller:软件需求规格说明书Version 1.0文档名称：ZD-软件需求规格说明书-ProductID-Vx.x.doc修订历史记录日期版本号修改说明修改人核准人2003/7/111.0首次撰写刘德刚目录1引言41.1目的与范围41.2预期的读者41.3系统的范围41.4参考资料41.5术语、缩写词42当前系统42.1当前系统概述42.2当前系统存在的问题43建议的系统43.1建议系统概述43.2功能性需求概述53.3非功能性需求53.3.1用户界面与人员因素53.3.2硬件考虑53.3.3性能特征53.3.4错误处理与极端情况53.3.5系统接口53.3.6质量要求53.3.7系统变更63.3.8物理环境63.3.9安全问题63.3.10资源问题63.4约束（Constraints）63.5系统模型63.5.1用例模型63.5.2对象模型73.5.3动态模型74变化列表75附录7软件需求规格说明书1 引言1.1 目的与范围本文档的作用与目标的描述，以及本文档内容所覆盖的范围。1.2 预期的读者列举本文档所针对的不同读者，例如开发人员、项目经理、用户、测试人员等。描述文档的组织结构，提出最适合每一类读者阅读的阅读建议。可以用超链接技术把各类读者所需关心的内容列出来，进行方便地跳转。1.3 系统的范围说明所开发系统范围，说明系统的利益和目标，把系统与企业的目标或者业务策略相联系，描述哪些是系统范围之内的，哪些是系统范围之外的。1.4 参考资料对本文档中涉及到的参考资料进行列表描述。对于每份参考资料要指明版本和位置。参考资料可以是合同等。1.5 术语、缩写词对本文件用到的术语、缩写词等进行说明。2 当前系统这一部分可以按照下面的2个小节进行描述，也可以汇总起来单独进行描述。2.1 当前系统概述描述系统当前的状况，包括系统中的数据情况以及业务运作情况。如果新系统将取代现有系统，这一部分就可以描述新系统所支持的任务现在是怎样完成的。2.2 当前系统存在的问题描述当前系统存在的问题。3 建议的系统 按照下面的子标题，描述将要开发的系统的情况。3.1 建议系统概述 对建议的系统做一个概要的高层描述。3.2 功能性需求概述 列出系统的功能性需求（是一种比较简捷的方式）。根据项目具体情况，本节可以裁剪。3.3 非功能性需求非功能性需求如果放在需求追踪矩阵中进行追踪的话，要进行编号，可以利用章节号，也可以自己指定编号规则，对下面的非功能性需求进行标识。3.3.1 用户界面与人员因素在这里要分析系统潜在的用户使用系统的情况。要考虑下面的问题：哪些类型的用户将使用本系统（专家，新手，等等）？将会有多种类型的用户使用本系统吗？对每一种类型的用户将要提供什么样的培训？容易学习是否是一个非常重要的特性？防止用户出错是否是一个非常重要的特性？人机接口会用到哪些输入/输出设备，它们的特性如何？3.3.2 硬件考虑在这里考虑系统面对的硬件问题。考虑下面的一些问题：建议的系统将使用什么样的硬件设备？设备的特性如何？包括内存大小、硬盘容量等等。3.3.3 性能特征在这里考虑系统的性能要求要限制。考虑下面的一些问题：在系统中是否有任何关于速度、吞吐量、响应时间等性能要求或限制？系统所处理的数据是否有容量的限制？等等。3.3.4 错误处理与极端情况在这里要关注系统如何处理可能发生的错误。考虑下面的一些问题：系统对输入错误如何响应？系统对一些极端条件如何响应？等等。3.3.5 系统接口在这里考虑系统的I/O。考虑下面的一些情况：输入是否有来自于外部系统？输出是否有到外部系统？对输入输出是否有要执行的限制格式或者中间格式？等等。3.3.6 质量要求在这里关注可能的质量增强或者妥协情况。考虑下面的一些问题：对可靠性的需求是什么？在一次失败后重起系统的时间是否有限制？每24小时，能够接受的系统当机的次数是多少？可以利用下面的表格的形式进行描述。主要质量属性详细要求正确性可靠性健壮性兼容性3.3.7 系统变更考虑系统需求的哪些部分可能会在以后更改？可能会有什么类型的更改？3.3.8 物理环境系统运行的物理环境，包括：目标设备将在哪里运行？目标设备是在一个还是多个地点？环境条件是否有超出正常的情况（例如：特殊的温度、震动、磁场等）？3.3.9 安全问题在这里关注所有可能的安全问题。考虑：访问任何数据或者系统本身是否必须受控？是否需要物理上的安全性？等等。3.3.10 资源问题在这里，考虑系统管理所需资源。考虑：系统备份的频率如何？谁负责备份？谁负责系统的安装？谁负责系统的维护？3.4 约束（Constraints）在这里考虑系统的各种限制。包括：开发语言的限制、开发环境的限制、数据库系统的限制等等。3.5 系统模型本文档的主体部分，对系统模型进行详细的描述与分析。3.5.1 用例模型3.5.1.1 参与者(Actor)汇总列出系统的所有执行者，并且对其进行简短描述参与者参与者说明3.5.1.2 用例汇总列出系统中的所有用例，说明其优先级，实现难度等信息。建议此处的用例名通过超链接技术与具体的用例描述关联起来。如果用例非常多，可以对其进行分类，分类为多个表格。分类的依据可以是按照参与者、按照开发组、按照主题等等。用例编号可以作为需求追踪矩阵中的需求编号进行追踪。优先级与重要性的定义见公司的相关规范。用例编号用例名称优先级重要性复杂度3.5.1.3 顶层用例图把顶层用例图（UML图，一个或者几个）放在这里。在顶层用例图中，可以清晰的看到系统所有的参与者，系统的主要用例，参与者与用例的关系，参与者之间的关系，系统的边界等，配合上面的2小节，可以给读者在整个系统的层面上有一个比较完整的认识。3.5.1.4 用例描述对系统中的用例，逐一进行描述。用例的格式有多种，根据情况进行选择，具体的事情可以参考ZD-用例编制指南。3.5.2 对象模型利用UML中的类图，对系统中的类，类之间的关系建模。此处不涉及设计的考虑，只是对问题域进行分析，得到一个或者多个类图。3.5.3 动态模型通过对系统的分析，利用UML中的状态图、顺序图、活动图等手段对系统的动态模型进行建模。模型的画法可以参考UML相关书籍。4 变化列表本节主要是针对增强型项目，如果是新型项目，本节可裁剪掉。对于增强型项目，描述新需求相对现存系统的变化。5 附录与需求相关的其他一些