软件需求说明书-模板.doc

研制令号研制令号 日期日期 项目 软软 件件 需需 求求 说说 明明 书书 （该文档仅供内部参考）（该文档仅供内部参考） 负责单位： 研发部门名称 协作单位： 协作单位名称 （如有） 作 者： 研发人员签名 批 准： 总工程师签名 修改及签收情况记录： 版本号修改人修改日期修改批准人部门资料室签收 研发人员 签名 研发部门主 任签名 部门资料员存档签 名 *股份有限公司股份有限公司 软件需求说明书 Vm.n 第 1 页 共 46 页 修改记录修改记录 文件编号版本号 拟制人/ 修改人 拟制/修改日 期 更改理由 主要更改内容 （写要点即可） 注 1：每次更改归档文件（指归档到事业部或公司档案室的文件）时，需填写此表。 注 2：文件第一次归档时， “更改理由” 、 “主要更改内容”栏写“无” 。 软件需求说明书 Vm.n 第 2 页 共 46 页 目目 录录 1引言引言.7 1.1编写目的.7 1.2预期的读者和阅读建议.7 1.3文档约定.7 2术语、定义和缩略语术语、定义和缩略语.8 2.1术语、定义.8 2.2缩略语.8 3综合描述综合描述.9 3.1背景.9 3.2功能概述.10 3.3运行环境.11 3.4用户类及其要求.11 4具体需求具体需求.13 4.1功能需求.18 4.1.1 19 5 4.2性能需求.28 4.2.128 9 4.3质量属性需求.29 4.3.1可靠性31 4.3.2安全性32 4.3.3可维护性33 4.3.4可移植性34 4.3.5扩展性34 4.3.6可测试性35 4.4外部接口需求.36 4.5其它需求.36 4.5.1通用化、系列化、模块化需求36 4.5.2设计和实现上的限制37 4.5.3执行标准39 4.5.4国际化需求41 4.5.5杂类需求42 5需求追踪需求追踪.43 6验收准则验收准则.43 7参考文献参考文献.44 软件需求说明书 Vm.n 第 3 页 共 46 页 软件需求说明书 Vm.n 第 4 页 共 46 页 设计和实现，则在继续工作前，需求还需要进一步细化。 2)如果（软件）系统测试人员需要 SRS 的作者额外的解释才能理解需求，并进 而编写（软件）系统测试规程/测试用例，则在继续工作前，需求还需要进一 步细化。 d)在概要甚至详细设计前怎么能描述功能需求的正常过程呢？ 1)首先要明确，软件需求描述的是“被描述系统” （如整个软件或某个软件子系） 对外提供的功能、性能、质量属性、外部接口等，可以将“被描述系统”看 成一个黑盒（如果在需求描述的过程中，涉及到了“被描述系统”内部的组 成，则可以认为该描述不满足要求。当然，也有些例外情况。如对于网管这 种已经很成熟的软件，在描述需求时，可以按终端与服务器分别进行描述） 。 而概要设计是对“被描述系统”内部组成及其相互关系进行设计，此时， “被 描述系统”是一个白盒。 2)功能需求的过程描述是对完成功能的操作/执行步骤（而不是具体的内部实现 流程）进行描述，一方面为后续设计提供基本的处理流程，另一方面（更为 重要）在描述正常过程、可选过程及异常过程（后两个过程在以往的实践中 经常需要到详设、甚至编码时才能部分确定）的过程，揭示各种数据项（详 细定义于数据字典中）及业务规则（如数据合法性、一致性、匹配等） 。 3)除了设计和实现上的限制及标准化相关需求外，SRS 只描述软件“做什么” ， 不应该包括设计、构造、测试或工程管理的细节。而概要设计是讲“如何做” 才能满足“做什么” 。 编制 SRS 时，应考虑以下情况： a)在编制 SRS 前，应熟悉软件需求说明书评审检查单。在编制过程中应注意避免出 现检查单中所列的常见问题。 b)如果不能保证与上游文档间的追踪关系，则 SRS 的编制就是失败的，同行评审将 不能关闭（甚至可以将这个要求列入同行评审的准入条件） 。因此，对于 SRS 的 作者来说，应将需求追踪放到足够重要的位置。作为检查的手段之一，在提交 SRS 进行同行评审前，作者应先进行需求追踪。 c)对于需求主要由协议/标准/规范规定的软件，在编制 SRS 时，为了准确、完整描 述需求，同时为减少文档的规模，可以采用“引用”的方法（建议句式为“ 见” ） ，但“引用”应完整，读者能方便、快速地找到目标内容。这就要求引 用时应列出协议/标准/规范名称、篇/章节号（如果不是整节引用，还应列出“开 始页号及行号、结束页号及行号” ） 。如果是不完全引用，应明确说明并指出异同。 注意：此处未要求列出具体版本， “协议/标准/规范”的版本信息在“执行标准” 中统一列出，这样可避免同时引用一份“协议/标准/规范”的多个版本。这也意味 着，一旦“协议/标准/规范”发生变更，所有的引用可能都得修改。本条要求同样 适用于对文件的引用。 d)为了更好地使用需求追踪工具 RequisitePro（以下简称 RP）进行需求追踪，在描 软件需求说明书 Vm.n 第 5 页 共 46 页 述需求时应注意图与表格的使用。 1)图可以是 Word 图（此处图是指插入的“对象” ） 、PaintBrush 图、 PowerPoint 图、Visio 图等，但应是“嵌入型“的，而不能是“浮于文字上 方”等其它形式。同时，应尽可能将图插在需求描述的中间，这样当图发生 变化时，就可以通过在图前或图后加减空格，使得 RP 知道需求发生了变化。 2)由于 RP 只能识别整表或一个一个的单元格，因此，一条需求要么只占一个 单元格，要么占满整表。 编制本文档时，容易犯的错误有： a)不顾文档上下游之间的关系，先编写设计方案，然后（有些项目拖得非常后）再 编写本文档。这种做法是不对的，容易导致几个问题。一是在没有确定做什么 （需求）的情况下就去描述怎么做（设计） ，极易导致返工。二是在需求文档中大 段大段地描述如何设计与实现。三是在已有设计文档的情况下，写需求文档被认 为是炒冷饭，因此不愿意再完整编写。 b)认为只有在详细设计时才可能把处理过程写清楚。甚至认为功能需求根本无需描 述处理过程，因为那是详细设计要做的事。这种认识无疑是错误的。因为，用户 是通过与软件（系统）交互来完成其任务的，如果设计与实现的交互过程与用户 要求或想象的不一致，则用户就会认为软件（系统）不好。因此，交互过程应最 大限度地被满足，应该尽早在需求说明书中描述。另外，可选、异常及业务规则 （如“只有经理级人员才可查看成本价” ）都隐藏于交互过程中，在需求开发过程 中，如果没有描述交互，则很可能遗漏可选、异常及业务规则。 c)在一段中描述若干条需求，或将若干需求合并在一条需求中描述（常见于“性能 需求”的描述中） 。这种写法比较难以阅读，进行需求追踪时捕获需求也不是很方 便。 d)对于非功能需求（如性能、质量属性需求等） ，只定性描述（如系统要稳定、CPU 占用率低） 。这样的描述无法验证。应该定量描述，且还应描述对应的条件。 本模板在格式上有以下一系列约定： a)用“”括起来的内容，是编写指导，在使用本模板编制的文档中应予以删除或 去掉“”后予以适当沿用。 b)本模板提供的示例，格式上都采用整行的“”框起来，同时还会给例子一个编号和名称，以方 便阅读与引用。 c)为了方便模板使用者删除，对本身保 持黑色。同时，由于示例部分可能会被模板的使用者直接沿用，因此仍然使用黑 色，（即“” 、或者 其它如表格中的例子用黑色）。但如果示例中又插入了一些指导说明文字，则这 软件需求说明书 Vm.n 第 6 页 共 46 页 些文字必须用蓝色。 d)如果某章节内容无需填写，而且本模板又没有特殊要求或说明，则在该章节下写 “无” ，而不要将该章节删除或不填写任何内容（即留白。留白将使评审员或读者 无法判断：是本章节内容无需填写还是因为疏忽而忘了填写？） 。 软件需求说明书 Vm.n 第 7 页 共 46 页 1引言引言 1.1编写目的编写目的 本文通过详细描述软件的功能需求、性能需求、质量属性需求、 外部接口需求以及其它需求，为后续概要设计、软件（系统）测试、用户文档等工作提供 基础与约束。 1.2预期的读者和阅读建议预期的读者和阅读建议 预期的读者和阅读建议参见表 1.1。 表 1.1 读者分类阅读重点及目的备注 1.3文档约定文档约定 软件需求说明书 Vm.n 第 8 页 共 46 页 2：是可能的，它规定了那些有了会更好但没有也没有什么关系的功能，如一些提高效 率的小工具。 1：是备忘的，它规定了我们想象的但目前无法或无需实现的需求。 =Example End= 2术语、定义和缩略语术语、定义和缩略语 2.1术语、定义术语、定义 本文使用的专用术语、定义见表 2.1，通用术语、定义见 术语、 定义和缩略语 。 表 2.1 术语/定义英文对应词含 义 2.2缩略语缩略语 本文使用的专用缩略语见表 2.2，通用缩略语见 术语、定义和缩 略语 。缩略语已按其第 1 个字母顺序排列。 表 2.2 缩略语英文原文中文含义 软件需求说明书 Vm.n 第 9 页 共 46 页 3综合描述综合描述 3.1背景背景 软件需求说明书 Vm.n 第 10 页 共 46 页 图 3.1 “化学制品跟踪系统”上下文图 网网管管终终端端 网网管管服服务务器器 网元 网网管管接接口口机机 命令下发 下发命令 命令下发 命令结果返回 命令结果返回 操作结果显示 主动上报信息 消息上报 命令结果返回 消息上报消息显示 操作界面 命令返回 消息上报 命令下发 图 3.2 上下文图 本网管软件与外界的联系见图 3.2 的文字说明。 =Example End= 3.2功能概述功能概述 软件需求说明书 Vm.n 第 11 页 共 46 页 述时只在功能组这一级罗列（只有 8 行） ，任何具体功能都可归结到这 8 个功能组中，因 此满足了覆盖具体需求的要求。同样，用户需求也未游离于这 8 个功能组之外，因此也覆 盖了其上游文档系统需求论证说明 （规划大师是纯软件项目） 。 3.3运行环境运行环境 运行环境见表 3.1。 表 3.1 名 称硬件(CPU/RAM/HD)操作系统及其版本其它软件环境 3.4用户类及其要求用户类及其要求 软件需求说明书 Vm.n 第 12 页 共 46 页 行分组。不同的用户类其需求是不同的，某些用户类的需求可能更加重要，需要优先考虑。 本节内容对后续的设计会产生一定的约束与限制。 每一个用户类都有自己的一系列功能和非功能需求。如：一个没有经验或偶尔使用电 脑的用户关心软件是否简单易用，因此，菜单、提示符和向导是很重要的。然而，对于那 些一天使用几小时软件的用户，他们更关心软件的易用性和高效性，所以他们喜欢使用快 捷键、宏以及脚本功能(scripting facility)。 有一些受软件影响的人并不一定是软件的直接使用者，而是通过报表或其它应用程序 访问本软件的数据和服务。这些非直接的或次级(secondary )的用户也有自己的需求，可以 将这些人加入“附加的用户类”。 用户类不一定都指人，其它应用程序或系统接口所用的硬件组件也可看成是附加用户 类的成员。以这种方式来看待应用程序接口，可以帮助确定软件中那些与外部应用程序或 组件有关的需求。 在项目中，要尽早为项目确定并描述出不同的用户类，这样，就能从每一个重要的用 户类代表中获取不同的需求。 软件需求说明书 Vm.n 第 13 页 共 46 页 4具体需求具体需求 软件需求说明书 Vm.n 第 14 页 共 46 页 e)划分优先级。给每项需求、特性或 use case 分配一个实施优先级以指明它在特定 产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在需要 调整项目范围时就无法进行取舍。 f)无二义性。对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言 极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避 免二义性的有效方法包括对需求文档的同行评审、编写测试用例、开发原型以及 设计特定的方案脚本等。 g)可验证性。检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用 演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其 实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾、不可行或有二 义性的需求也是不可验证的。 好的需求说明书的描述应具有以下特征。 a)完整性。不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务 而不是系统的功能将有助于提高完整性。如果知道缺少某项信息，用 TBD (“待确 定”)作为标准标识来标明这项缺漏。在通过评审前，必须解决需求中所有的 TBD 项。 b)一致性。一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在评 审通过前必须解决所有需求间的不一致部分。 c)可修改性。在必要时或为维护每一需求变更历史记录时，应该修订 SRS。这就要 求每项需求要独立标出，并与别的需求区别开来；每项需求只应在 SRS 中出现一 次，这样更改时易于保持一致性。 d)可追踪性。应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间 建立起追踪关系，这种可追踪性要求每项需求以一种结构化的，粒度好（fine- grained）的方式编写并单独标明，而不是大段大段的叙述。 编写 SRS 时牢记： a)保持语句和段落的简短。 b)避免将多个需求集中在一个冗长的叙述段落中。 c)避免出现需求冗余。 d)采用主动语态的表达方式。 e)使用正确的语法、拼写、标点。 f)保持术语的一致性，并尽可能编制术语表及数据字典。 g)条件语句描述应完整。如果只出现了“如果” ，而没有“否则” ，则应仔细考虑 “如果”没有发生（即出现了“否则”分支）会怎样。 h)多从设计与开发人员的角度衡量需求是否已被有效定义。如果设计与开发人员需 要 SRS 的作者额外的解释才能理解需求，并进而进行设计和实现，则在继续工作 前，需求还需要进一步细化。 软件需求说明书 Vm.n 第 15 页 共 46 页 i)如果验证某需求需要很多测试用例且测试用例很分散，则可认为需求的粒度太粗， 应继续细化。 j)必须以相同的详细程度描述每个需求。如， “组合键 Control-S 代表保存文件”与 “组合键 Control-P 代表打印文件”的描述粒度是相同的，而“产品必须响应以 语音方式输入的编辑指令”则相对太粗了。 k)鼓励使用确定性词语，如：总是、每一种、所有、没有、从不、应、必须等。 l)特别关注或避免使用如下词语。 1)当然、因此、明显、显然、必然。这些词语意图诱使接受假定情况，当看到 这些词语时，审查员应仔细审查推断或假定是否成立。 2)某些、有时、常常、通常、贯常、经常、大多、几乎、用户友好、容易、简 单、许多、最新技术、可接受的、健壮的。这些词语太过模糊，所描述的功 能无法测试。 3)等等、诸如此类、依此类推。以这样的词结束的功能清单无法测试。功能清 单要绝对或者解释明确，以免让人迷惑，不知如何推论。 4)良好、迅速、廉价、高效、小、稳定。这些是不确定的说法，不可测试。如 果在文中出现，就必须进一步指明含义。 5)已处理、已拒绝、已忽略、已消除。这些说法可能隐藏大量需要说明的功能。 几个需求说明的例子。 例 1 “产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于 60 秒” 。 分析：这个需求是不完整的：什么是状态消息，并且在什么情况下向用户提供这些消 息？显示时间多长？我们所说的是产品的哪一部分？时间间隔也会导致混淆。假定显示状 态消息之间的时间间隔只要求不少于 60 秒，按这样推理，是否可以每隔一年显示一次状 态信息？如果意图是消息之间的时间间隔不多于 60 秒，那么 1 毫秒会不会太短？消息显 示的时间间隔怎样才能一致？“每次”这个词混淆了这一问题。由于这些问题的存在，导 致了需求是不可验证的。 改进：假设本例是描述后台任务管理器（BTM）应该在用户界面的指定区域显示状态 消息。 a)在后台任务启动之后，消息必须每隔 60（10）秒更新一次，并且保持连续的可 见性。 b)如果正在正常处理后台任务，那么后台任务管理器（BTM）必须显示后台任务进 程已完成的百分比。 c)当完成后台任务时，后台任务管理器（BTM）必须显示一个“已完成”的消息。 d)如果后台任务中止执行，那么后台任务管理器（BTM）必须显示一个出错消息。 将原先的需求分割成多个需求，因为每个需求都需要独立的测试用例并且使各个需求 都具有可跟踪性。如果把多个需求都集中在一个段落中，那么在构造软件和测试时就很容 软件需求说明书 Vm.n 第 16 页 共 46 页 易忽略其中某个需求。注意，修改之后的需求并没有精确地说明是怎样显示状态信息的。 这是一个设计问题。 例 2 “产品必须在显示和隐藏非打印字符之间进行瞬间切换” 。 分析：该需求是不完整的，因为它没有说清状态切换的原因。在特定的条件下，软件 产品是否可以进行自动切换或者可否由用户采取某些措施来激发这样转变？还有，在文档 中显示转变的范围是什么？是所选的文本、整个文档或其它内容？这个需求也存在一个不 确定性问题。 “非打印”字符是否指隐藏文本、属性标记或者其它的控制字符？由于存在这 些问题，该需求是不可验证的。 改进： “用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有 HTML 标记之间进行切换” 。 （假设用户对触发机制并不关心） 现在，指代关系就清楚了，非打印字符指的是 HTML 标记。修改过的需求指明了是用 户触发了显示状态的转换，但是它并没有对设计造成限制，因为它并没有精确定义所使用 的机制。当设计人员选择好一种触发机制（例如热键、菜单命令或语音输入）时，就可以 编写详细的测试用例来验证这种转换操作是否正确。 例 3 “分析程序应该能生成 HTML 标记出错的报告，这样就可以使 HTML 的初学者 使用它来迅速排错。 ” 分析：“迅速”这个词具有模糊性。缺乏对出错报告内容的定义表明该需求也是不完 整的。还有一点不清楚的是：HTML 初学者使用的是分析程序还是出错报告。并且何时生 成这样的报告？ 改进： a)在 HTML 分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告， 这个报告中包含了在分析文件过程中所发现错误的 HTML 所在的行号以及文本内 容，还包含了对每个错误的描述。 b)如果在分析过程中未发现任何错误，就不必生成出错报告。 （描述了例外情况的处 理） 例 4 “如果可能的话，应当根据主货物编号列表在线确认所输入的货物编号。 ” 分析：“如果可能的话”这句话意味着什么？该需求是否在技术上可行？是否可以在 线访问主货物编号列表？如果不能确信是否可以递交一个请求，那么就使用“TBD” （待确 定）来表示未解决的问题。这个需求是不完整的，因为它并没有指明如果确认通过或失败， 将会发生什么情况。 改进：“系统必须根据在线的主货物编号列表确认所输入的货物编号。如果在主列表 中查不到该货物的编号，系统必须显示一个出错消息并且拒绝订货。 ” 例 5 “产品不应该提供将带来灾难性后果的查询和替换选择。 ” 分析：“灾难性后果”存在二义性。本条需求关注的焦点实际上可能是多级撤销(undo)能 软件需求说明书 Vm.n 第 17 页 共 46 页 力。 改进：“产品在编辑时应提供多级（可由用户配置，最大 99 级）撤销（undo）能力” 例6 “基站启动流程中对和超级终端串口的通信进行检测，如果通信正常，则进 行2）的处理。” 分析：该需求不完整。典型的只说一个分支的错误：只说了if，丢了else。 改进：“基站启动流程中对和超级终端串口的通信进行检测，如果通信不正常， 则转步骤 10） ；否则转到步骤 2） 。 ” 例 7 “参见 PPT 相关设计文档，XXXX 软件基本上是移植，改动主要涉及 U 口数量 增多、相关进程增加等方面。 ” 分析：引用应明确写出引用的文档名称、章节号、开始页号及行号、结束页号及行号， 方便读者准确、快速定位目标内容。同时应明确给出移植前后的差异，设计时才可根据差 异进行设计，否则就要在设计时找出哪些差异（需求）然后再设计。 例8 “在RCR STD-28协议中对输入有明确的规定。” 分析：引用协议应明确写出协议的章节号、开始页号及行号、结束页号及行号。 软件需求说明书 Vm.n 第 18 页 共 46 页 4.1功能需求功能需求 软件需求说明书 Vm.n 第 19 页 共 46 页 序号 功能需求描述 子项 前缀编号及格式说明示例 3触发条件T 格式同上。编号的前缀为大写的 T （代表触 发） 4正常过程N a)接着“正常过程：”后描述正常过程编 号，编号以大写的 N（代表正常）引导。 一般只有一个正常过程。 b)过程编号的引用规则： 需求编号 + “.” + 正常过程编号 正常过程：SR-F- 0010.N1 XX 引用正常过程的例 子： SR-F-0010.N1 5正常过程步骤N a)格式同“前置条件” 。编号的前缀为大 写的 N b)正常过程、可选过程、异常过程的步骤 可以放在一起编号，如 N01、A02、E03，也可以独立编号。 c)正常过程步骤的引用规则： 需求编号 + “.” + 正常过程编号 + “.” + 正常过程步骤编号 N0010 XXXX 引用正常过程步骤 的例子： SR-F-0010.N1. N0010 6可选过程A a)接着“可选过程：”后描述可选过程编 号，空两格后描述可选过程名称。编号 以大写的 A（代表可选）引导，编号的 位数可以等于最大位数 + 1，不足用 0 补齐 b)过程编号的引用规则： 需求编号 + “.” + 正常过程编号 可选过程：SR-F- 0010.A1 XX 引用可选过程的例 子： SR-F-0010.A1 7可选过程步骤A 格式同“正常过程步骤” 。编号的前缀为大 写的 A A0050 XXXX 引用可选过程步骤 的例子： SR-F-0010.A1. A0050 8异常过程E格式同“可选过程” 。编号的前缀为大写的 E 9异常过程步骤E 格式同“可选过程步骤” 。编号的前缀为大 写的 E 10特殊需求S 格式同“前置条件” 。编号的前缀为大写的 S（代表特殊） 11输入I 格式同“前置条件” 。编号的前缀为大写的 I（代表输入） 12输出O 格式同“前置条件” 。编号的前缀为大写的 O（代表输出） 13处理P 格式同“前置条件” 。编号的前缀为大写的 P（代表处理） 4.1.1 需求描述需求描述： 执行者执行者： 优先级优先级： 使用频度使用频度： 前置条件前置条件：软件需求说明书 Vm.n 第 20 页 共 46 页 件编号 + 两个空格 + 具体的前置条件。对于“无”的编写要求，同样适用于“后置条件” 、 “可选过程” 、 “异常过程” 、 “特殊需求” 。 后置条件后置条件： 正常过程正常过程： 可选过程可选过程：后的分支） 。 异常过程异常过程：后的分支） 。 特殊需求特殊需求： 包含包含： SR-F-0020 请求一种化学制品 需求描述需求描述：请求者通过输入化学制品的 ID 或输入化学制品的结构来指定对化学制品的 请求。系统则提供给请求者一个来自化学制品仓库的新的或已用过的化学制品容器，或者 让请求者向外界供货商订货。 执行者执行者：请求者 优先级优先级：5 使用频度使用频度：经常。对于每个药剂师大约每周 5 次，对于化学制品仓库的每个成员每周 100 次。 前置条件前置条件： 软件需求说明书 Vm.n 第 21 页 共 46 页 C0010 用户的身份被证实； C0020 具有在线的化学制品存货清单数据库。 后置条件后置条件： R0010 将完成的请求存入“化学制品跟踪系统” ； R0020 通过电子邮件把请求发往化学制品仓库或完成采购。 正常过程正常过程：SR-F-0020.N1 从供应商那里请求一种化学制品 N0010 执行者输入化学制品的 ID 或者包含化学制品结构的文件名； N0020 系统验证化学制品的 ID 是否合法； N0030 系统询问请求者需要一个新的供应商订单或一个来自化学制品仓库的容器； N0040 执行者确定供应商或化学制品仓库（可选过程 SR-F-0020.A1） ； N0050 正常过程结束。 可选过程可选过程：SR-F-0020.A1 从化学制品仓库中请求一种化学制品（SR-F- 0020.N1.N0040 之后的分支） A0010 系统显示出化学制品仓库中现存的所要求的化学容器的列表； A0020 执行者可选择地查看任何容器的历史； A0030 执行者选择一个特定的容器或发出供应商订单。 异常过程异常过程：SR-F-0020.E1 化学制品在业务上不可用（SR-F-0020.N1.N0020 之后的 异常） E0010 系统显示消息：不存在供应商； E0020 系统询问请求者是否要请求另一种化学制品或退出； E0030 执行者请求另一种化学制品； E0040 正常过程（本次）结束。 特殊需求特殊需求： S0010 系统必须可以按标准的编码形式输入化学制品的结构，这一标准来自对不同 化学制品图形包的支持。 S0020 在推荐的配置软、硬件环境上，只运行本软件时，软件必须在 1 秒内响应用 户的输入。 包含包含：SR-F-0512 输入货物编号 注释和问题注释和问题：Tim 将查明：在危险列表的第一级上请求一种化学制品是否需要管理层 的批准。预期时间 2002/11/04（同行评审前） 。 =Example End= 4.1.1 SR-F-0010 RRC 连接建立 RRC 连接建立用例图见图 4.1。 软件需求说明书 Vm.n 第 22 页 共 46 页 UE NodeB SR-F-0010-01 RRC 连 接建立在专用信道上 SR-F-0010-02 RRC 连 接建立在公用信道上 RNC 图 4.1 RRC 连接建立用例图 SR-F-0010-01 RRC 连接建立在专用信道上 需求描述需求描述：UE 在 CCCH 上发送 RRC 连接请求，RNC 根据 UE 请求为其分配相应资 源，并将 RRC 连接建立在专用信道上，并与 NodeB 协商为其分配无线口和 Iub 口专用传 输信道资源。 执行者执行者：UE，NodeB 优先级优先级：5 使用频度使用频度：经常 前置条件前置条件： C0010 RNC 与 NodeB 之间通信正常； C0020 UE 处于 NodeB 覆盖范围之内。 后置条件后置条件： R0010 RRC 连接建立成功。 正常过程正常过程：SR-F-0010-01.N1 N0010 UE 向 RNC 发送 RRC Connection Request 消息，请求建立 RRC 连接； N0020 RNC 决定将该 RRC 连接建立在专用信道（DCH）上，并为 UE 分配相关 无线资源。 N0030 RNC 向 NodeB 发送 Radio Link Setup Request 消息，请求 NodeB 为相关 专用无线信道的建立分配资源； N0040 NodeB 回应 Radio Link Setup Response 消息； N0050 RNC 用 ALCAP 协议建立 Iub 口的数据传输 AAL2 承载； N0060 RNC 向 NodeB 发送 Downlink Synchronisation 帧，准备建立下行同步； N0070 NodeB 向 RNC 发送 Uplink Synchronisation 帧，建立下行同步； N0080 RNC 在 CCCH 上向 UE 发送 RRC Connection Setup 消息，其中指示了给 软件需求说明书 Vm.n 第 23 页 共 46 页 UE 分配的无线资源； N0090 NodeB 向 RNC 发送 Radio Link Restore Indication 消息，指示上行同步已经 建立； N0100 UE 在专用信道上向 RNC 发送 RRC Connection Setup Complete 消息，整 个过程结束。 可选过程：可选过程：无 异常过程异常过程：SR-F-0010-01.E1 无法为 UE 分配专用信道资源（在正常过程 SR-F- 0010-01.N1.N0020 之后） E0010 RNC 决定将该 RRC 连接建立在专用信道（DCH）上后，发现无法为 UE 分 配专用信道资源； E0020 RNC 决定将 RRC 连接建立在公用信道上。具体过程请参见 SR-F-0010- 02（RRC 连接建立在公共信道上） 异常过程异常过程：SR-F-0010-01.E2 Iub 口无线链路建立失败（在正常过程 SR-F-0010- 01.N1.N0030 之后） E0010 NodeB 发送 Radio Link Setup Failure 消息给 RNC，指示无线链路建立失败； E0020 RNC 删除为 UE 分配的相关无线资源； E0030 RNC 决定将 RRC 连接建立在公用信道上。具体过程请参见 SR-F-0010- 02（RRC 连接建立在公共信道上） 异常过程异常过程：SR-F-0010-01.E3 Iub 口数据承载建立失败（在正常过程 SR-F-0010- 01.N1.N0050 之后） E0010 RNC 用 ALCAP 协议建立 Iub 口 AAL2 数据承载失败； E0020 RNC 向 NodeB 发送 Radio Link Deletion Request 消息，删除刚才建立的无 线链路； E0030 NodeB 发送 Radio Link Deletion Response 消息响应； E0040 RNC 删除为 UE 分配的相关无线资源； E0050 RNC 决定将 RRC 连接建立在公用信道上。具体过程请参见 SR-F-0010- 02（RRC 连接建立在公共信道上） 异常过程异常过程：SR-F-0010-01.E4 无线链路上行同步失败（在正常过程 SR-F-0010- 01.N1.N0080 之后） E0010 NodeB 向 RNC 发送 Radio Link Failure 消息，指示上行同步建立失败； E0020 RNC 向 NodeB 发送 Radio Link Deletion Request 消息，删除刚才建立的无 线链路； E0030 NodeB 发送 Radio Link Deletion Response 消息响应； E0040 RNC 删除为 UE 分配的相关无线资源； E0050 过程结束。 异常过程异常过程：SR-F-0010-01.E5 RRC Connection Setup 消息响应超时（在正常过程 软件需求说明书 Vm.n 第 24 页 共 46 页 SR-F-0010-01.N1.N0080 之后） E0010 RNC 在发送 RRC Connection Setup 消息 RRC_TIMEOUT 时间后没有接收 到 UE 的 RRC Connection Setup Complete 消息； E0020 RNC 向 NodeB 发送 Radio Link Deletion Request 消息，删除刚才建立的无 线链路； E0030 NodeB 发送 Radio Link Deletion Response 消息响应； E0040 RNC 删除为 UE 分配的相关无线资源； E0050 过程结束。 特殊需求特殊需求：无。 SR-F-0010-02 RRC 连接建立在公用信道上 需求描述需求描述：UE 在 CCCH 上发送 RRC 连接请求，RNC 根据 UE 请求为其分配相应资 源，并将 RRC 连接建立在公用信道上。 执行者执行者：UE 优先级优先级：5 使用频度使用频度：经常 前置条件前置条件： C0010 RNC 与 NodeB 之间通信正常； C0020 Uu 口以及 Iub 口的公共传输信道以及相关资源已经 建立和分配； C0030 UE 处于 NodeB 覆盖范围之内。 后置条件后置条件： R0010 RRC 连接建立成功。 正常过程正常过程：SR-F-0010-02.N1 N0010 UE 向 RNC 发送 RRC Connection Request 消息，请求建立 RRC 连接； N0020 RNC 决定将 RRC 连接建立在公用信道上，并分配相关无线资源； N0030 RNC 在 CCCH 上向 UE 发送 RRC Connection Setup 消息，其中指示了给 UE 分配的无线资源； N0040 UE 在公用信道上向 RNC 发送 RRC Connection Setup Complete 消息，整 个过程结束。 可选过程：可选过程：无 异常过程异常过程：SR-F-0010-02.E1 无法分配无线资源（在正常流程 SR-F-0010- 02.N1.N0020 之后） E0010 RNC 无法为 UE 分配相关无线资源； E0020 RNC 向 UE 发送 RRC Connection Reject 消息，拒绝 UE 接入； E0030 过程结束。 软件需求说明书 Vm.n 第 25 页 共 46 页 异常过程异常过程：SR-F-0010-02.E2 RRC Connection Setup 消息响应超时（在正常过程 SR-F-0010-02.N1.N0030 之后） E0010 RNC 在发送 RRC Connection Setup 消息 RRC_TIMEOUT 时间后没有接收 到 UE 的 RRC Connection Setup Complete 消息； E0020 RNC 删除为 UE 分配的相关无线资源； E0030 过程结束。 特殊需求特殊需求：无。 =Example End= 4.1.2 需求描述需求描述： 优先级优先级： 使用频度使用频度： 触发条件触发条件： 输入输入： 输出输出： 处理处理： 特殊需求特殊需求： SR-PF-0050 服务器登录功能 需求描述需求描述：提供一个公共界面，在该公共界面提供登录服务器的功能。 优先级优先级：5 使用频度使用频度：经常 软件需求说明书 Vm.n 第 26 页 共 46 页 触发条件触发条件： T0010 启动客户端或登录到另外一台服务器上。 输入输入： I0010 用户名（不超过 20byte 长度的字符串） ； I0020 密码（不超过 10byte 长度的字符串） 。 输出输出： O0010 登录结果（成功、失败、超时） 处理处理： P0010 发送登录消息到服务器端； P0020 如果可以和服务器建立通信，则由服务器根据用户名和密码进行安全验证； 否则超时后转到 P0030； P0030 显示超时或获得服务器端的验证结果后显示登录是否成功。 特殊需求特殊需求： S0010 在推荐的配置软、硬件环境上，只运行本软件时，软件从“发送登录消息” 开始到“得到成功或失败应答”不能超过 1 秒。 =Example End= SR-F-0010 LCCH 分配过程 需求描述需求描述：LCCH 分配过程是指手机和基站之间在呼叫发起时或者手机接收到 PCH 的寻呼请求后为了分配用于信令交互而使用的 TCH 频点和时隙而在 SCCH 上进行的消息 交互过程。LCCH 分配过程总是以手机在 SCCH 上发送 LCCH Establish Request 开始该 过程。 优先级优先级：5 使用频度使用频度：不关心 触发条件触发条件： T0010 主站 XXXX 软件收到 CSGBS 的 DSP 的 LCCH Establish Request 消息。 输入输入： I0010 见 RCR STD-28 协议第 4.3 节第 111 页第 1 行到第 181 页最后 1 行的描述； 和 DSP 的接口采用内部定义的方式。 输出输出： O0010 见 RCR STD-28 协议第 4.3 节第 111 页第 1 行到第 181 页最后 1 行的描述； 空中接口部分的数据格式采用内部定义的方式。 处理处理：主从站的 LCCH 分配过程如图 4.9 所示。 软件需求说明书 Vm.n 第 27 页 共 46 页 主站 主站与从站的 通信正常吗？ 超时了吗？ No No P0070 P0060 有空闲的TCH时 隙及TCH频点吗？ P0030Yes No Yes P0040 P0050 P0010 YesP0110 P0080 P0090 从站 图 4.9 LCCH 分配过程 P0010 主站 XXXX 软件收到 SCCH 的 LCCH Establish Request 消息。 P0030 如果有空闲的 TCH 时隙或 TCH 频点，则主站 XXXX 软件将从空闲的 TCH 时隙和频点中选择一个时隙和频点进行分配，并将分配内容通知给 CSGBS 的 DSP。CSGBS 的 DSP 将控制射频部分进行 TCH 接收和发送频点的修改，并将 LCCH Assign 消息发送给手机。 P0040 主站 XXXX 软件将执行 Service Channel Establish 过程。主站分配过程结束。 P0050 如果没有空闲的 TCH 时隙及 TCH 频点，且主站和从站的通信连接也不正常， 则主站 XXXX 软件将“LCCH Assign Reject”消息发送给手机。主站分配过程结束。 P0060 如果没有空闲的 TCH 时隙及 TCH 频点，但主站和从站的通信连接是正常的， 则主站 XXXX 软件将通过“捆绑接口基站通信流程”将 LCCH Establish Request 消息转 发给从站，并等待返回结果（定时器 XX 请见 XX第 XX 节定义） 。 P0110 如果超时，将向手机发送 LCCH Establish Reject 消息。主站分配过程结束。 P0070 如果没有超时，主站 XXXX 软件通过“捆绑接口基站通信流程”收到从站的 LCCH Assign 或者 LCCH Assign Reject 消息，直接转发给 DSP。主站分配过程结束。 P0080 从站的 XXXX 软件在收到捆绑口的 LCCH Establish Request 消息后，将从 空闲的 TCH 时隙和频点中选择一个时隙和频点进行分配，并将分配内容通知 CSGBS 的 DSP，同时向主站发送 LCCH Assign 消息。CSGBS 的 DSP 将控制射频部分进行 TCH 接 收和发送频点的修改。 P0090 从站的 XXXX 软件将执行“Service Channel Establish”过程。从站分配过 软件需求说明书 Vm.n 第 28 页 共 46 页 程结束。 特殊需求特殊需求：无 =Example End= 4.2性能需求性能需求 c)严格区分系统性能需求与软件性能需求。在以往的实践中，SRS 中的性能需求往 往直接拷贝自系统性能需求（即研制规范 ） 。实际上，两者在大多数情况下都 是不同的，一般无法直接借用。 可以在“性能需求”标题下直接以正文格式罗列性能需求，两条需求间以一行空行分 割，而不用编写第三级标题。如果要分组描述（父-子需求描述） ，则可将需求组作为第三 级标题（假设编号为 SR-P-0020） ，其下直接描述具体性能需求（具体性能需求的编号应 以 SR-P-0020-开头，如 SR-P-0020-01） 。此时，对于组（父）需求来说，除了要描述编 号及需求名称外，无需描述其它任何内容。注意：性能需求的描述方式应尽可能统一，即 一旦选择分组方式，就不要改用其它方式（即使只有一条需求） 。以下描述了需求分组描述 的情况。 软件需求说明书 Vm.n 第 29 页 共 46 页 4.2.1 需求描述需求描述： 优先级优先级： 需求描述需求描述： 优先级优先级： SR-P-0100-01 CS1 编码、3 时隙捆绑的 FTP 平均速率 需求描述需求描述：在实验室环境（接收电平大于-70dBm，没有同邻频干扰）下，使用 CS1 编码方式，独享捆绑的 3 时隙，仅下载一个 1M 大小的文件，FTP 平均速率应大于 2 kb/s，且在 20 次测试中，至少应有 15 次达到 2 kb/s。 优先级优先级：5 SR-P-0100-02 CS2 编码、3 时隙捆绑的 FTP 平均速率 需求描述需求描述：在实验室环境（接收电平大于-70dBm，没有同邻频干扰）下，使用 CS2 编码方式，独享捆绑的 3 时隙，仅下载一个 1M 大小的文件，FTP 平均速率应大于 3 kb/s，且在 20 次测试中，至少应有 15 次达到 3 kb/s。 优先级优先级：5 4.2.2 SR-P-0102 精度需求 SR-P-0102-01 传感器精度 需求描述需求描述：传感器的数据应具有 14 位的精度，在两年之内可扩展到 18 位。 优先级优先级：5 =Example End= 4.2.2 4.3质量属性需求质量属性需求 软件需求说明书 Vm.n 第 30 页 共 46 页 也无法测试。 实际上，业界已有一些标准来规定质量属性需求的定量描述。为了更好地（即定量、 可验证）描述质量属性需求，我们列出了 IEEE 的相关标准 IEEE 1061-1998 作为参考， 见表 4.2、表 4.3。引自软件验证与确认的最佳管理方法 （“7.2.2 框架”P69 - P72。 为方便读者理解，已对很少一部分内容进行了修改） 。另外，也参考了软件需求 （“第 11 章 软件的质量属性”P97 - P102。Karl E. Wiegers 著） 。 表 4.2 质量特性质量特性描述质量子特性质量子特性描述 谁最 感兴趣 硬件独立性软件不依赖于特定硬件环境的程度开发者 软件独立性软件不依赖于特定软件环境的程度开发者 易安装性 将软件安装到某个新环境所需努力的程 度 开发者可移植性 与软件可从某一环 境转移到另一环境 的能力有关的一组 属性 可重用性 软件可重新应用到一个新应用（与原应 用不同）的程度 开发者 无缺陷性软件不包含