软件需求规格说明书(模板).doc

软件需求规格说明书模板Version 1.0 2011.6.18模板使用要通过本模板创建可以交付的文档请遵循以下指导：1. 删除文档标题页和本页。2. 用你的项目和负责人信息替换封面括号中的文本。3. 用你的项目和负责人信息替换页眉区域括号中的信息。注意：请不要移除或修改页脚区域的信息。4. 完成整个模板。每节包含简短的操作说明，在内容区域中用斜体显示。可交付的文本编写在操作说明下方或模板提供的表格内。注意：交付文档时需要移除斜体的说明。5. 目录内容发生变化时，需要更新文档目录。在目录区右键选择“更新域”就可以更新整个目录。软件需求规格说明书【贪吃蛇】文件状态： 草稿 正式发布 正在修改文件标识：QST-班号-项目代码-DOC-RS当前版本：X.Y作 者：完成日期：Year-Month-Day批 准 人：批准日期：Year-Month-Day签 字：【机构/组织 名称】变更历史序号版本变更日期变更内容变更者123456789101112目 录0. 文档介绍30.1 文档目的30.2 文档范围30.3 读者对象30.4 参考文档30.5 术语与缩写解释31. 项目概述41.1产品介绍41.2 产品范围41.3用户群体及角色41.4 运行环境51.5 假设、依赖和约束52. 产品的功能性需求62.1 整体业务流程图用例图62.2 功能性需求分类62.3 功能类别 A62.3.xf 功能 X62.3.xu 用例 Y72.4 功能类别 B83. 产品的非功能性需求83.1 用户界面需求83.2 性能需求83.3 产品质量需求93.4 其他需求94. 接口9附录A：需求建模与分析报告10A.1 需求模型110A.n 需求模型N10附录B：需求跟踪矩阵11附录C：需求确认120. 文档介绍0.1 文档目的对贪吃蛇游戏进行需求分析，明白用户需求，明确软件具有的功能，性能及界面，为系统设计和编码人员提供依据，方便后期工作。0.2 文档范围贪吃蛇的功能需求，性能需求及界面。0.3 读者对象客户需求分析人员文档编写人员编码人员测试人员项目管理人员0.4 参考文档提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：SPP-PROC-PP SEPG，需求开发规范，机构名称，日期0.5 术语与缩写解释缩写、术语解 释1. 项目概述1.1产品介绍提示：（1）说明产品是什么，什么用途。（2）介绍产品的开发背景。提供关于发起这个软件开发的业务组织的概要，包括业务组织的使命及业务目标1.2 产品范围提示：描述待开发软件产品的范围。在描述中应该包括：l 描述软件产品的特征l 介绍软件的功能，并进行简要说明l 描述软件产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。（做什么，不做什么）l 说明软件应用l 描述软件的相关的收益、目的和目标等此处的描述应与之前的项目文档的类似描述保持一致。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。1.3用户群体及角色提示：（1）描述本产品面向的用户（客户、最终用户）的特征。（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？（3）根据用户的特征，按照功能、位置和设备类型等识别每一类用户。明确每一类型的用户的数量，以及他们使用软件的特点。根据这些特点划分产品中定义的角色及其工作职责，填写在下表中，各种角色的具体行为将在功能性需求中描述。软件产品用户的特征会影响特定的需求。许多人在软件生命周期的运行和维护阶段使用软件。这些人是用户、操作员、系统维护人员。这些人的某些特点，如教育水平，经验和技术专长，可能成为软件的运行环境的重要制约因素。角色名称职责描述系统管理员由程序内部人员担任，负责系统配置，维护，备份及恢复，以及任务管理。普通玩家所有玩家，负责玩游戏。1.4 运行环境提示：描述软硬件运行环境。包括硬件平台、操作系统和版本，以及用户、服务器和数据库的地理位置。列出系统必须和平共存的其他软件组件或应用程序，前景和范围文档中可能包含这样的高层信息。需求名称详细要求硬件软件WINDOW 7操作系统以上1.5 假设、依赖和约束提示：列举软件产品的假设、依赖和约束。但不是每个产品都同时具备这三个条件。 假设 描述那些影响在软件需求说明书描述的需求的假设。假设是那些在项目的生命周期中被认为是真的因素，如果这种假设改变，会对项目产生负面的影响，包括但不限于最终用户的特点，已知的技术基础设施，资源可用性和资金可用性等。依赖 描述那些影响在软件需求说明书中描述的需求的依赖。依赖是指在项目的范围和控制之外，并且为了项目取得成功而必须为真的情况。举例来说，一个依赖可能是一个应用程序依赖于一个不同的应用提供具体的数据或者是一个与第三方应用程序的接口需要购买一个应用程序编程接口（API）。约束 提供各种限制软件的范围和功能的因素的描述，包括但不限于行业标准与规范，业务规则，监管政策，基础设施的限制，资源和许可。约束是通过环境、权利或强制规定施加到解决方案上的限制。约束通过无法改变的边界及限制，制约了解决方案的设计师可供选择的方案。2. 产品的功能性需求2.1 整体业务流程图用例图提示：以结构化或面向对象的方法绘制出产品整体业务的流程图或用例图。2.2 功能性需求分类提示：将功能性需求先粗分再细分，下表中的 功能 A, 功能 A.1等符号应当被替换成有含义的名称。功能类别子功能功能类别 A功能 A.1功能 A.2功能类别 B功能 B.1功能 B.22.3 功能类别 A提示：功能类别的名称与分类表中类别名称应保持一致，它是几个子功能总括名称，形如“采购管理”、“私信系统”。以下提供了每种描述功能需求的子功能的模板。2.3.xf 功能 X提示：当采用功能分解的方式描述功能性需求的时候，可按照2.3.xf的模板描述所有的子功能。需要按照具体的功能标识及命名每一个功能，其中xf是子功能序号，X是功能的名称。2.3.xf.1 描述和优先级 提示：描述功能，并指出该功能的优先级。2.3.xf.2 输入提示：描述功能输入。2.3.xf.3 操作提示：描述在功能中执行的操作。2.3.xf.4 输出提示：描述功能的输出2.3.xu 用例 Y提示：当采用用例的方式描述功能性需求时，使用2.3.xu为模板描述每个用例，按照每一个具体的用例标识以及命名每个用例，其中xu是子功能序号，Y是指定用例的名字。在每个用例子功能中，指定用例信息，包括角色，前置条件，后置条件，操作流程和替代流程等。用例名称进入游戏用例编号Tcs-001用例简介打开程序，进入游戏优先级前置条件打开贪吃蛇程序后置条件游戏开始，蛇开始移动操作流程步骤触发者描述1玩家双击贪吃蛇程序，打开游戏界面点击选项中的开始或者按下S快捷键游戏开始，目标移动扩展流程例外流程包含假设约束条件输入及约束用例名称玩游戏用例编号Tcs-002用例简介进入游并开始游戏优先级前置条件打开贪吃蛇程序后置条件操作流程步骤触发者描述1玩家玩家通过键盘上下左右键来控制蛇的移动，蛇会做出相应的反应。蛇吃到食物：蛇身变长一个，分数加10，速度速度加5。所按键方向与蛇的移动方向相反，命令无效。蛇死亡：蛇与自身相撞或者蛇与墙相撞。扩展流程游戏期间可直接关闭游戏例外流程包含假设约束条件输入及约束用例名称退出游戏用例编号Tcs-003用例简介优先级前置条件游戏正在进行后置条件操作流程步骤触发者描述1扩展流程例外流程包含假设约束条件输入及约束2.4 功能类别 B3. 产品的非功能性需求3.1 用户界面需求提示：描述软件的用户界面需求。用户界面需求用于捕获应用程序的人机界面的预期行为。例如，如果用户通过显示终端操作，说明所需的屏幕内容，任何报告或菜单的内容，输入和输出的相对时间。用户需求可能包括示例的屏幕或报表格式为原型来进行需求的说明。需求名称详细要求3.2 性能需求提示：描述性能条件以及相关的能力。考虑因素包括：l 发生的动态行为或变化（如比率，速率，运动和噪声水平）l 涵盖设备的承受能力的量化标准，用于在规定的环境和其他条件下满足用户的需求，包括最低总寿命。说明了需要的持续运行时间以及计划的可用率。l 运行的阶段和模式的性能需求l 支持的终端数量l 支持的并发用户数量l 在正常以及峰值负载的条件下，特定时间内可以处理的事务和任务以及数据量l 在非正常的工作压力下可接受的性能3.3 产品质量需求提示：描述软件的质量特性的需求。需求的描述应该是可度量、可验证的。描述在特性之间（比如安全性和可移植性）之间的权衡关系。质量特性的定义包括正确性、有效性、灵活性、完整性/安全、互操作性、可维护性、可移植性、可靠性、可重用性、可测试性、易用性。主要质量属性详细要求正确性健壮性可靠性性能，效率易用性清晰性安全性可扩展性兼容性可移植性3.4 其他需求提示：描述不适合放在前面需求章节中的任何其他的需求。如有些软件系统比较强调信息管理需求、安全需求，也可以在此扩展。4. 接口提示：描述应用和其他软件、硬件以及通信协议之间的接口的逻辑特性。每个接口的描述包括：l 该接口的目的l 应用接口对应的系统，包括外部的或内部的l 交换机制附录A：需求建模与分析报告建议用Rational Rose对产品需求进行建模与分析。A.1 需求模型1A.n 需求模型N附录B：需求跟踪矩阵提示：提供指向需求跟踪矩阵的链接，需求跟踪矩阵中说明了在系统需求规格说明中的系统需求、在本软件需求规格说明书中的软件需求以及系统设计中的设计元素之间的对应关系。SRS中的需求跟踪矩阵应该：l 含有用来说明系统需求与系统设计、软件需求、软件设计等元素之间的可追溯性的列l 含有用来说明集成、验收、回归、性能测试等的可追溯性的列l 填入了所有记录在系统需求规格说明中的需求l 填入了所有记录在系统设计中的设计项l 填入了所有记录在需求规格说明书中的需求项l 说明了系统规格说明书中的系统需求与系统设计中的设计项之间的对应关系l 说明了系统设计中的设计项与需求规格说明中的需求的对应关系l 说明了每一个需求的出处及来源附录C：需求确认提示：主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”。在获取责任人（Stakeholders）对需求的承诺之前，该产品需求规格说明书必须先通过需求评审。需求评审报告摘要需求文档输入名称，标识符，版本，作者，完成日期，需求评审报告输入名称，标识符，评审日期，评审结论 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 工作成果基本合格，需要作少量的修改，之后通过审核即可。 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。评审意见评审小组成员输入评审小组成员需求承诺需求文档输入名称，标识符，版本，作者，完成日期客户承诺承诺签字，日期项目经理承诺承诺签字，日期