需求规格说明书模板样本

软件需求规格阐明书模版目录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 用例1 73.3 特性1（不采用用例模型） 83.3.1 <需求N> 84 非功能性需求 114.1 性能需求 114.1.1 性能需求1 114.2 可靠性需求 114.2.1 可靠性需求1 114.3 安全需求 114.3.1 安全需求1 114.4 其她需求 114.4.1 其她需求1 115 外部接口需求 125.1 顾客接口 125.1.1 <顾客接口需求M> 125.2 硬件接口 135.2.1 <硬件接口需求M> 135.3 软件接口 145.3.1 <软件接口需求M> 145.4 通信接口 155.4.1 <通信接口需求M> 156 附录 16

简介[提出对《软件需求规格阐明书》纵览，协助读者理解文档如何编写并且如何阅读和解释。]编写目[对产品（也也许是项目，但是咱们统称为产品）进行定义，在该文档中详尽阐明这个产品需求，涉及修正或发行版本号。如果这个《产品需求规格阐明书》只与整个系统一某些关于，那么只定义文档中阐明某些或子系统。举例：本文目是为了清晰地阐明产品要实现所有功能，产品设计、编码和测试都要以本文内容为基本。同步，本文拟定内容还作为产品验收基准。客户、项目组要共同协商本文内容。]预期读者和阅读建议[列举本文档所针对不同读者，例如开发人员、市场人员、测试人员、客户等。描述文档中剩余某些内容及其组织构造，提出最适合每一类型读者阅读文档建议。]术语、定义、符号及缩略语[按字母或拼音顺序列出所有定义和缩略语，以便读者可以对的地理解《产品需求规格阐明书》，涉及词头和缩写。注意：只需要列出对理解本文有用术语。举例：PRS：ProductRequirementSpecification（产品需求规格阐明书）。]参照资料[列举编写《软件需求规格阐明书》时所参照资料或其他来源。也许涉及顾客界面风格指引、合同、原则、系统需求规格阐明书、顾客需求、有关产品产品需求规格阐明书。这里应当给出参照资料详细信息，涉及标题名称、作者、版本号、日期、出版单位或资料来源，以以便读者查阅这些文献。]综合描述[这一某些概述了正在定义产品以及它所运营环境、使用产品顾客和已知限制、假设和依赖。]项目背景[描述产品需求规格阐明书中所定义产品背景和来源。阐明该产品与否是产品系列中下一种成员，与否是成熟产品所改进下一代产品、与否是既有应用程序代替品，或者与否是一种全新产品。]产品功能[概述产品必要具备重要功能，本文档在第三章对产品功能进行详细描述，在此仅作概括总结，重点在系统层次上描述产品功能需求和功能分类，还也许涉及保证产品与外部组件对的连接需求。可以使用列表办法给出，也可使用图形表达重要需求分组以及它们之间联系，例如数据流程图顶层图或类图。以使描述更加有效。]应用模型[运用场合、环境、组网、应用举例。绘制产品构造图示、与系统相交互外部对象之间关系。如果该某些内容与《市场需求分析报告》中“产品组网与应用分析”内容完全相似，请直接引用（例如：请参见《市场需求分析报告》中“产品组网与应用分析”）。]运营环境[描述产品运营环境，涉及为支持产品工作所需其他组件或者与其共存产品；对于软件产品还应涉及硬件平台、操作系统和版本、必要安装软件部件和其她应用软件等。]假设和依赖[列出所有会影响需求实现假设因素（相对于已知事实而言），也许涉及打算要用商业组件或关于开发或运营环境问题。例如，本项目产品筹划要使用某些第三方软件产品或商业软件产品，虽然当前尚未得到这些软件，但咱们可以假设这些软件一定可以得到。如果这些假设不对的、或发生变化，会影响项目开发，因而，这些假设往往又是一种风险。此外，拟定项目对外部因素存在依赖。例如，如果项目开发或项目产品使用要依托其他外部因素，例如与其他产品共用软件包、准备重用软件构件等，也要在此阐明。]功能需求[本章将详细解释产品所有功能需求。功能需求是依照系统特性即产品所提供重要服务来组织。你也许更喜欢通过用例、运营模式、顾客类、对象类或功能级别来组织这某些内容，你还可以使用它们组合。总之，你必要选取一种使读者易于理解预期产出组织方案。如果使用老式需求分析办法，本章每一节描述一种功能需求，每个功能需求又从编号、名称、优先级、输入、解决、输出、验收准则7项来阐明。如果使用UML模型描述需求分析成果，本章每一节采用“使用用例”描述一种功能需求，并在此阐明参照“使用用例”文献名；如果你采用模型工具绘制用例视图，你应在此注明所用工具名称、版本等信息。本章中所列出需求，规定细化到如下限度：（1）设计人员可以根据该需求设计并实现系统；（2）系统测试人员可以根据该需求编写测案并对系统进行验证。]包构造模型/模块关系模型[使用UML模型描述需求分析成果时，在本节划分出系统包构造，用图表达出顾客机构与本系统各个包之间关系和本系统各包某些之间关系。使用老式需求分析办法时，在本节划分出系统各功能模块构造，用图表达出顾客机构与本系统各个功能模块之间关系和本系统各功能模块之间关系。]用例包1（采用用例模型）用例模型图重要信息【对于每个包应当阐明如下信息：名称简要阐明该包所拥有用例列表该包所拥有角色列表直属该包包列表】用例1优先级[该需求优先级，按高、中、低优先级分类。对高、中、低解释如下：高：核心功能特性，必选，不能实现意味着无法满足客户需求。所有“高”优先级需求必要在本次项目开发中实现。中：重要功能，必选，不能实现也许会影响产品销售和客户满意度。所有“中”优先级需求都应当作为产品功能点，但在时间、资源压力下，可以考虑在产品下一种版本中实现。低：有用功能或性能提高，可选，不能实现不会对产品产生实质性影响，但也许会在特定应用场合增长产品卖点，在时间、资源容许状况下，可以考虑在产品某一版本中实现。]简要阐明【用例简要阐明应反映用例角色和目。在撰写阐明时，应参照用例中所涉及主角、词汇表，并依照需要定义新概念。如下是回收机系统中“回收贮藏物品”用例简要阐明示例：回收贮藏物品：顾客使用本机器来自动记录所有回收物品（瓶子、罐子以及箱子），并得到一张收据。收据将在收银机处兑现。】参加者事件流【用例事件流包括用例建模工作所得到最重要信息。应当清晰地阐明用例事件流，让外行也能很容易地理解它。请记住，事件流应当阐明系统做什么，而不是阐明为了执行所需行为而对系统进行设计。事件流两个重要某些是主事件流和扩展事件流。主事件流应涉及在执行用例时“普通”会发生事件。扩展事件流涉及与正常行为有关可选或异常特性行为，同步也涉及正常行为各种变形。您可以将扩展事件流看作是主事件流“绕行道”，有些扩展事件流将返回到主事件流，而有些将结束此用例执行。】主事件流扩展事件流前置条件【前置条件或后置条件所阐明状态应当是顾客可以观测到状态。“顾客已经登录系统”或“顾客已经打开文档”都是可观测状态示例。前置条件是对用例何时开始约束。它并不是使用例开始事件。例如自动柜员机中“提取钞票”用例前置条件为：客户拥有一张个人专用卡，这张卡正好可以塞进读卡器，并且该卡已经分到一种PIN号，还向银行业务系统进行了登记。】触发条件【触发条件是阐明触发用例执行条件。例如“预定客房”用例触发条件是客户申请预定客房，其前置条件是当前有空客房。】后置条件【例如，自动柜员机中“提取钞票”用例后置条件为：当用例结束时，所有帐户和交易日记都已收支平衡，与银行业务系统通信已重新初始化，并且银行卡已经返还给客户。】特性1（不采用用例模型）[在此对<特性1>进行概要性阐明，例如：此模块中包括实现预付费业务所需所有功能。]<需求N>[本节标题<需求N>需以实际需求名代替。]编号[为需求定义一种唯一编号，便于需求跟踪。]名称及阐明[需求名称，如果需要可以在此对需求内容作简要描述。]优先级[该需求优先级，按高、中、低优先级分类。对高、中、低解释如下：高：核心功能特性，必选，不能实现意味着无法满足客户需求。所有“高”优先级需求必要在本次项目开发中实现。中：重要功能，必选，不能实现也许会影响产品销售和客户满意度。所有“中”优先级需求都应当作为产品功能点，但在时间、资源压力下，可以考虑在产品下一种版本中实现。低：有用功能或性能提高，可选，不能实现不会对产品产生实质性影响，但也许会在特定应用场合增长产品卖点，在时间、资源容许状况下，可以考虑在产品某一版本中实现。]输入[列出本需求所有输入（触发条件、输入参数）。对每项输入，也许属性如下：输入名阐明类型[例如：Int、String]输入值范畴输入来源格式]解决[描述为了满足该项功能应进行哪些事务解决。可以用文本方式、伪指令或流程图来描述。]输出[列出本需求所有输出（输出参数、解决成果）。对每项输出，也许属性如下：输出名阐明类型输出值范畴输出值目的格式]非功能性需求性能需求性能需求1编号名称及阐明优先级验收准则可靠性需求可靠性需求1编号名称及阐明优先级验收准则安全需求安全需求1编号名称及阐明优先级验收准则其她需求其她需求1编号名称及阐明优先级验收准则外部接口需求表三：外部接口需求分类表需求类别编号需求名称优先级描述顾客接口[陈述产品中所需要顾客界面。描述每个顾客界面逻辑特性。如下是也许要涉及某些特性：将要采用图形顾客界面原则或整个产品系列风格；屏幕布局；将出当前每个屏幕原则按钮（如协助）、功能或导航链接；键盘快捷键；错误信息显示原则。如果必要，顾客接口需求细节可在独立顾客接口规格文献中描述。]<顾客接口需求M>[本节标题需以实际需求名代替。]编号[为需求定义一种唯一编号，便于需求跟踪。]名称及阐明[需求名称，如果需要可以在此对需求内容作简要描述。]优先级[该需求优先级，按高、中、低优先级分类。对高、中、低解释如下：高：核心功能特性，必选，不能实现意味着无法满足客户需求。所有“高”优先级需求必要在本次项目开发中实现。中：重要功能，必选，不能实现也许会影响产品销售和客户满意度。所有“中”优先级需求都应当作为产品功能点，但在时间、资源压力下，可以考虑在产品下一种版本中实现。低：有用功能或性能提高，可选，不能实现不会对产品产生实质性影响，但也许会在特定应用场合增长产品卖点，在时间、资源容许状况下，可以考虑在产品某一版本中实现。]验收准则[阐明用于验证满足需求验收准则。]硬件接口[描述系统中软件和硬件每一接口特性，也许涉及软件所支持设备类型、软硬件之间交流数据和控制信息性质、通讯合同等。]<硬件接口需求M>[本节标题需以实际需求名代替。]编号[为需求定义一种唯一编号，便于需求跟踪。]名称及阐明[需求名称，如果需要可以在此对需求内容作简要描述。]优先级[该需求优先级，按高、中、低优先级分类。对高、中、低解释如下：高：核心功能特性，必选，不能实现意味着无法满足客户需求。所有“高”优先级需求必要在本次项目开发中实现。中：重要功能，必选，不能实现也许会影响产品销售和客户满意度。所有“中”优先级需求都应当作为产品功能点，但在时间、资源压力下，可以考虑在产品下一种版本中实现。低：有用功能或性能提高，可选，不能实现不会对产品产生实质性影响，但也许会在特定应用场合增长产品卖点，在时间、资源容许状况下，可以考虑在产品某一版本中实现。]验收准则[阐明用于验证满足需求验收准则。]软件接口[阐明本产品与其他外部组件（涉及数据库、操作系统、工具、运营库、集成商业部件等，要指明它们名字和版本）连接。明确并描述在软件组件之间互换数据或消息目。描述所需要服务以及内部组件通信性质。拟定将在组件之间共享数据。如果必要用一种特殊办法来实现数据共享机制，例如在多任务操作系统中一种全局数据区，那么就必要把它定义为一种实现上限制。]<软件接口需求M>[本节标题需以实际需求名代替。]编号[为需求定义一种唯一编号，便于需求跟踪。]名称及阐明[需求名称，如果需要可以在此对需求内容作简要描述。]优先级[该需求优先级，按高、中、低优先级分类。对高、中、低解释如下：高：核心功能特性，必选，不能实现意味着无法满足客户需求。所有“高”优先级需求必要在本次项目开发中实现。中：重要功能，必选，不能实现也许会影响产品销售和客户满意度。所有“中”优先级需求都应当作为产品功能点，但在时间、资源压力下，可以考虑在产品下一种版本中实现。低：有用功能或性能提高，可选，不能实现不会对产品产生实质性影响，但也许会在特定应用场合增长产品卖点，在时间、资源容许状况下，可以考虑在产品某一版本中实现。]验收准则[阐明用于验证满足需求验收准则。]通信接口[描述与产品所使用通信功能有关需求，例如电子邮件、WEB浏览器、网络通信原则或合同及电子表格等。定义有关信息格式，指明要遵守通讯原则，如FTP，HTTP等。阐明在通讯中安全和加密问题、数据传播速率、同步机制等。]<通信接口需求M>[本节标题需以实际需求名代替。]编号[为需求定义一种唯一编号，便于需求跟踪。]