《需求规格说明书模板样本.doc》由会员分享，可在线阅读，更多相关《需求规格说明书模板样本.doc（18页珍藏版）》请在金锄头文库上搜索。
1、软件需求规格阐明书模版 目录1简介41.1编写目41.2预期读者和阅读建议41.3术语、定义、符号及缩略语41.4参照资料42综合描述42.1项目背景52.2产品功能52.3应用模型52.4运营环境52.5假设和依赖53功能需求63.1包构造模型/模块关系模型63.2用例包1（采用用例模型）63.2.1用例模型图63.2.2重要信息63.2.3用例173.3特性1（不采用用例模型）83.3.184非功能性需求114.1性能需求114.1.1性能需求1114.2可靠性需求114.2.1可靠性需求1114.3安全需求114.3.1安全需求1114.4其她需求114.4.1其她需求1115外部接口需
2、求125.1顾客接口125.1.1125.2硬件接口135.2.1135.3软件接口145.3.1145.4通信接口155.4.1156附录161 简介提出对软件需求规格阐明书纵览，协助读者理解文档如何编写并且如何阅读和解释。1.1 编写目对产品（也也许是项目，但是咱们统称为产品）进行定义，在该文档中详尽阐明这个产品需求，涉及修正或发行版本号。如果这个产品需求规格阐明书只与整个系统一某些关于，那么只定义文档中阐明某些或子系统。举例：本文目是为了清晰地阐明产品要实现所有功能，产品设计、编码和测试都要以本文内容为基本。同步，本文拟定内容还作为产品验收基准。客户、项目组要共同协商本文内容。1.2 预
3、期读者和阅读建议列举本文档所针对不同读者，例如开发人员、市场人员、测试人员、客户等。描述文档中剩余某些内容及其组织构造，提出最适合每一类型读者阅读文档建议。1.3 术语、定义、符号及缩略语按字母或拼音顺序列出所有定义和缩略语，以便读者可以对的地理解产品需求规格阐明书，涉及词头和缩写。注意：只需要列出对理解本文有用术语。举例：PRS：Product Requirement Specification（产品需求规格阐明书）。 1.4 参照资料列举编写软件需求规格阐明书时所参照资料或其他来源。也许涉及顾客界面风格指引、合同、原则、系统需求规格阐明书、顾客需求、有关产品产品需求规格阐明书。这里应当给出
4、参照资料详细信息，涉及标题名称、作者、版本号、日期、出版单位或资料来源，以以便读者查阅这些文献。2 综合描述这一某些概述了正在定义产品以及它所运营环境、使用产品顾客和已知限制、假设和依赖。2.1 项目背景描述产品需求规格阐明书中所定义产品背景和来源。阐明该产品与否是产品系列中下一种成员，与否是成熟产品所改进下一代产品、与否是既有应用程序代替品，或者与否是一种全新产品。2.2 产品功能概述产品必要具备重要功能，本文档在第三章对产品功能进行详细描述，在此仅作概括总结，重点在系统层次上描述产品功能需求和功能分类，还也许涉及保证产品与外部组件对的连接需求。可以使用列表办法给出，也可使用图形表达重要需求
5、分组以及它们之间联系，例如数据流程图顶层图或类图。以使描述更加有效。2.3 应用模型运用场合、环境、组网、应用举例。绘制产品构造图示、与系统相交互外部对象之间关系。如果该某些内容与市场需求分析报告中“产品组网与应用分析”内容完全相似，请直接引用（例如：请参见市场需求分析报告中“产品组网与应用分析”）。2.4 运营环境描述产品运营环境，涉及为支持产品工作所需其他组件或者与其共存产品；对于软件产品还应涉及硬件平台、操作系统和版本、必要安装软件部件和其她应用软件等。2.5 假设和依赖列出所有会影响需求实现假设因素（相对于已知事实而言），也许涉及打算要用商业组件或关于开发或运营环境问题。例如，本项目产
6、品筹划要使用某些第三方软件产品或商业软件产品，虽然当前尚未得到这些软件，但咱们可以假设这些软件一定可以得到。如果这些假设不对的、或发生变化，会影响项目开发，因而，这些假设往往又是一种风险。此外，拟定项目对外部因素存在依赖。例如，如果项目开发或项目产品使用要依托其他外部因素，例如与其他产品共用软件包、准备重用软件构件等，也要在此阐明。3 功能需求本章将详细解释产品所有功能需求。功能需求是依照系统特性即产品所提供重要服务来组织。你也许更喜欢通过用例、运营模式、顾客类、对象类或功能级别来组织这某些内容，你还可以使用它们组合。总之，你必要选取一种使读者易于理解预期产出组织方案。如果使用老式需求分析办法
7、，本章每一节描述一种功能需求，每个功能需求又从编号、名称、优先级、输入、解决、输出、验收准则7项来阐明。如果使用UML模型描述需求分析成果，本章每一节采用“使用用例”描述一种功能需求，并在此阐明参照“使用用例”文献名；如果你采用模型工具绘制用例视图，你应在此注明所用工具名称、版本等信息。本章中所列出需求，规定细化到如下限度：（1）设计人员可以根据该需求设计并实现系统；（2）系统测试人员可以根据该需求编写测案并对系统进行验证。3.1 包构造模型/模块关系模型使用UML模型描述需求分析成果时，在本节划分出系统包构造，用图表达出顾客机构与本系统各个包之间关系和本系统各包某些之间关系。使用老式需求分析
8、办法时，在本节划分出系统各功能模块构造，用图表达出顾客机构与本系统各个功能模块之间关系和本系统各功能模块之间关系。3.2 用例包1（采用用例模型）3.2.1 用例模型图3.2.2 重要信息【对于每个包应当阐明如下信息：名称简要阐明该包所拥有用例列表该包所拥有角色列表直属该包包列表】3.2.3 用例13.2.3.1 优先级该需求优先级，按高、中、低优先级分类。对高、中、低解释如下：高：核心功能特性，必选，不能实现意味着无法满足客户需求。所有“高”优先级需求必要在本次项目开发中实现。中：重要功能，必选，不能实现也许会影响产品销售和客户满意度。所有“中”优先级需求都应当作为产品功能点，但在时间、资源
9、压力下，可以考虑在产品下一种版本中实现。低：有用功能或性能提高，可选，不能实现不会对产品产生实质性影响，但也许会在特定应用场合增长产品卖点，在时间、资源容许状况下，可以考虑在产品某一版本中实现。3.2.3.2 简要阐明【用例简要阐明应反映用例角色和目。在撰写阐明时，应参照用例中所涉及主角、词汇表，并依照需要定义新概念。如下是回收机系统中“回收贮藏物品”用例简要阐明示例：回收贮藏物品：顾客使用本机器来自动记录所有回收物品（瓶子、罐子以及箱子），并得到一张收据。收据将在收银机处兑现。】3.2.3.3 参加者3.2.3.4 事件流【用例事件流包括用例建模工作所得到最重要信息。应当清晰地阐明用例事件流
10、，让外行也能很容易地理解它。请记住，事件流应当阐明系统做什么，而不是阐明为了执行所需行为而对系统进行设计。事件流两个重要某些是主事件流和扩展事件流。主事件流应涉及在执行用例时“普通”会发生事件。扩展事件流涉及与正常行为有关可选或异常特性行为，同步也涉及正常行为各种变形。您可以将扩展事件流看作是主事件流“绕行道”，有些扩展事件流将返回到主事件流，而有些将结束此用例执行。】3.2.3.4.1 主事件流3.2.3.4.2 扩展事件流3.2.3.5 前置条件【前置条件或后置条件所阐明状态应当是顾客可以观测到状态。“顾客已经登录系统”或“顾客已经打开文档”都是可观测状态示例。前置条件是对用例何时开始约束
11、。它并不是使用例开始事件。例如自动柜员机中“提取钞票”用例前置条件为：客户拥有一张个人专用卡，这张卡正好可以塞进读卡器，并且该卡已经分到一种 PIN 号，还向银行业务系统进行了登记。】3.2.3.6 触发条件【触发条件是阐明触发用例执行条件。例如“预定客房”用例触发条件是客户申请预定客房，其前置条件是当前有空客房。】3.2.3.7 后置条件【例如，自动柜员机中“提取钞票”用例后置条件为：当用例结束时，所有帐户和交易日记都已收支平衡，与银行业务系统通信已重新初始化，并且银行卡已经返还给客户。】3.3 特性1（不采用用例模型）在此对进行概要性阐明，例如：此模块中包括实现预付费业务所需所有功能。3.
12、3.1 本节标题需以实际需求名代替。3.3.1.1 编号为需求定义一种唯一编号，便于需求跟踪。3.3.1.2 名称及阐明需求名称，如果需要可以在此对需求内容作简要描述。3.3.1.3 优先级该需求优先级，按高、中、低优先级分类。对高、中、低解释如下：高：核心功能特性，必选，不能实现意味着无法满足客户需求。所有“高”优先级需求必要在本次项目开发中实现。中：重要功能，必选，不能实现也许会影响产品销售和客户满意度。所有“中”优先级需求都应当作为产品功能点，但在时间、资源压力下，可以考虑在产品下一种版本中实现。低：有用功能或性能提高，可选，不能实现不会对产品产生实质性影响，但也许会在特定应用场合增长产
13、品卖点，在时间、资源容许状况下，可以考虑在产品某一版本中实现。3.3.1.4 输入列出本需求所有输入（触发条件、输入参数）。对每项输入，也许属性如下：输入名阐明类型例如：Int、String输入值范畴输入来源格式3.3.1.5 解决描述为了满足该项功能应进行哪些事务解决。可以用文本方式、伪指令或流程图来描述。3.3.1.6 输出列出本需求所有输出（输出参数、解决成果）。对每项输出，也许属性如下：输出名阐明类型输出值范畴输出值目的格式4 非功能性需求4.1 性能需求4.1.1 性能需求14.1.1.1 编号4.1.1.2 名称及阐明4.1.1.3 优先级4.1.1.4 验收准则4.2 可靠性需求
14、4.2.1 可靠性需求14.2.1.1 编号4.2.1.2 名称及阐明4.2.1.3 优先级4.2.1.4 验收准则4.3 安全需求4.3.1 安全需求14.3.1.1 编号4.3.1.2 名称及阐明4.3.1.3 优先级4.3.1.4 验收准则4.4 其她需求4.4.1 其她需求14.4.1.1 编号4.4.1.2 名称及阐明4.4.1.3 优先级4.4.1.4 验收准则5 外部接口需求表三：外部接口需求分类表需求类别编号需求名称优先级描述5.1 顾客接口陈述产品中所需要顾客界面。描述每个顾客界面逻辑特性。如下是也许要涉及某些特性：l 将要采用图形顾客界面原则或整个产品系列风格；l 屏幕布局；l 将出当前每个屏幕原则按钮（如协助）、功能或导航链接；l 键盘快捷键；l 错误信息显示原则。如果必要，顾客接口需求细节可在独立顾客接口规格文献中描述。5.1.1 本节标题需以实际需求名代替。5.1.1.1
