计算机软件需求规格说明规范

计算机软件需求规格说明规范

国家标准 GB/T9385一2008 代替GB/T9385一1988 计算机软件需求规格说明规范 Nrmmofcomputersofwarereqirememtsspeifeautior 2008-04-11发布 2008-09-01实施 国家质量监督检验检疫总局 发布 国家标准化管蹬委员会国家标准
GB/T9385一2008 目 次 前言 引言 范围 规范性引用文件 术语和定义 SRS的编制原则 SRs的组成和内容要求 附录A资料性附录SRS提纲模板 A.1按照运行模式组织的SRS第3章模板版本1 A.2按照运行模式组织的sRs第3章模板(版本2) 15 A.3按照用户类别组织的sRs第3章模板 16 A.4 第3章模板 16 按照对象组织的SRS 按照系统特征组织的sRs第3章模板 按照激励组织的sRs第3章模板 18 按照功能层次组织的sRs第3章模板 18 体现多种组织形式的sRS第3章模板 20 参考文献 21
GB/T9385一2008 前 言 本标准是GB/T9385《计算机软件需求说明编制指南》的第一次修订 本标准与GB/T9385 1988的主要差别如下: 根据GB/T1.1的规定,原GB/T9385一1988版中第1章引言部分中的内容放在新版的引言 部分; b)新版标准的范围部分重新进行调整改写; 第2章规范性引用文件删去了GB/T8567; e' d)根据GB/T8566和GB/Tll457的规定,术语“开发者”改为“供方” 原GB/T9385一1988版的第4章和第5章调整为新版的第章,且名称为sRs”的编制原则 调整后的第4章更加清晰、完善 而删去了旧版第5章中有关模型的内容; 旧版标准的第6章的主要内容调整为新版标准的第5章,而提纲部分调整为新版标准的附录 A且附录A的内容扩充了一部分 本标准的附录A是资料性附录 本标准自实施之日起代替被废止GB/T93851988 本标准由信息产业部提出 本标准由全国信息技术标准化技术委员会归口 本标准起草单位:信息产业部电子工业标准化研究所、航天科技集团公司软件评测中心、上海 计算机软件开发中心、上海宝信软件股份有限公司,东方通科技广两软件园、上海浦东软件园有限责任 公司、上海鲁齐信息科技有限公司 本标准主要起草人;冯惠、王宝艾,窦传义、石柱、杨根兴、李春青、陈在根、张肠肠、张露莹 本标准于1988年首次发布 业
GB/T9385一2008 引 言 本标准描述了软件需求规格说明的编制方法 它基于以下设想,即软件需求规格说明确定过程的 结果是一份明确和完备的规格说明文档 本标准将有助于 软件的顾客准确地描述其希望得到什么 -软件的供方正确地理解顾客想要什么; 对于实现以下目标的有关单位和人员 为其所在的组织编制一份标准的软件需求规格说明(SRS)提纲; 定义其具体软件需求规格说明的格式和内容; 编制其他的本地支持资料,如,SRS质量检查清单、或SRS编写者手册 对于顾客、供方和其他有关人员，一份好的SRs可能带来一些具体的益处,例如 -对于提供什么软件产品,为顾客和供方之间的协议建立基础 在sRS中软件功能的完备描述 将协助潜在用户,以便确定指定的软件是否满足其需要,或者为满足其需要应如何修改软件; -减少开发工作 SRS 文档的编制迫使顾客组织有关备方或人员在设计之前严格考虑所有的 需求,并减少以后的重新设计、重新编码和重新测试 对SRS中的各项需求进行仔细评审,可 以在开发周期的早期揭示某些遗漏、误解和不 -致,此时这些问题更容易纠正 为估计成本和进度提供基础 SRS中给出的待开发产品的描述是估计项目成本的现实基础， 可用于取得投标认可或得出价格估算 为验证和确认提供基线 通过一份好的sRs文档,组织可提出其更加有效的验证和确认计 -部分,SRS提供了可用于测量依从性的基线 划 作为开发合同的一 便于软件产品转移 sRS文档使软件产品转移到新的用户或机器更容易 顾客因此发现软 件产品更容易转移到组织的其他部门,供方发现软件产品更容易转移到新的顾客; 作为进一步增强的基础 因为sRs文档讨论的是产品,而不是开发它的项目,因此,sRs是已 开发产品后续增强的基础 尽管SRs文档或许需要修改,但它确实为后续的产品评价提供了 基础
GB/T9385一2008 计算机软件需求规格说明规范 范围 本标准给出了软件需求规格说明(SRs)的编制要求,描述了一份好的sRs的内容和质量,并在附 s 录A中给出一些SRs提纲示例 本标准适用于编制SRS. 本标准并不限定任何编制sSRs特定的方法,命名约定和工具 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款 凡是注日期的引用文件,其随后所有 的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究 是否可使用这些文件的最新版本 凡是不注日期的引用文件,其最新版本适用于本标准 GB/T8566信息技术软件生存周期过程(GB/T8566一2007,ISO/IEC12207;1995,MOD) GB/T11457 信息技术软件工程术语 术语和定义 GB/T1l457中确立的以及下列术语和定义适用于本标准 合同contract 由顾客和供方共同签署的具有法律约束力的文件,其中包括产品的技术、组织、成本和进度的需求 合同同样可包括某些非正式的、但有用的信息,如,参与各方的承诺或期望 3.2 顾客eustomer 为产品支付费用,并通常(但不必要)确定需求的个人或群体 在某些情况下,顾客和供方可以是同 -组织的成员 3.3 供方supplier 为顾客开发产品的个人或群体 在某些情况下,顾客和供方可以是同一组织的成员 3 用户user 直接运行产品或与产品进行交互作用的个人或群体 用户和顾客通常不是同一个人或群体 SRs的编制原则 4.1综述 本章给出了编制SRs时宜考虑的事项及编制原则 a)SRS的基本性质 b SRs的环境 好的SRs的特性; c d)SRs的联合编制 SRS演变; e
GB/T9385一2008 原型法; f g)SRs中嵌人设计 SRS中嵌人项目需求 h 4.2sSRs的基本性质 SRS是对在具体环境中执行确定功能的特定软件产品,程序或一组程序的规格说明 sRSs可由来 自供方、顾客或双方的一个或者多个人员编写,4.5推荐由来自供方和顾客双方的人员联合编写 SRs编写人员应关注以下基本点 功能 -软件将执行什么功能" a) b)外部接口 -软件如何与人、系统的硬件及其他硬件和其他软件进行交互？ c)性能 -各种软件功能的速度、响应时间、恢复时间等是多少? d 属性 软件的可用性、可靠性、可移植性、正确性,可维护性、安全性如何" 影响产品实现的设计约束 是否有使用标准、编程语言、数据库完整性方针、资源限制运行 环境等方面的要求? 编写人员宜避免把设计或项目需求写人SRS中 SRS的内容详见第5章 SRS的环境 很重要的一 -点是应考虑sRs在整个项目计划中的作用 项目计划的定义见cB/T67 软件既 可以基本上包括了项目的所有功能也可以是更大系统的一部分 在后一种情况,典型的SRs将指出 系统及其软件部分的接口,并将外部性能和功能需求写人软件部分 显然,SRs应当在系统需求上扩 展并与其保持一致 GB/T8566描述了软件生存周期的各个步骤,以及每步适用的输人 与软件生存周期等有关的其 他标准,可对软件需求进行补充 因为SRS在软件开发过程中发挥特定的作用,编写人员宜谨慎对待,不超出其作用的范围 这意 味着SRS a)宜正确地定义所有软件需求 由于将要处理的任务的性质或项目的具体特性,则软件需求是 存在的 b) 不宜描述任何设计或实现的细节 这些内容应当在项目的设计阶段进行描述 e)不宜对软件设置附加的限制条件 这些内容可在其他文件中规定,如,软件质量保证计划 因此,编写适当的sRS限定了正确设计的范围,但不规定任何具体的设计 好的SRs的特征 4.1综述 4. SRS宜是 正确; a b) 无歧义 e) 完备; d 一致 e) 重要性和/或稳定性分级 f 可验证; 可修改 g h 可追踪 4.4.2正确 当且仅当SRs中的每一项需求都是软件应满足的需求,SRs才是正确的 不存在确保SRs正确性的工具或规程 宜把SRS与任何适用的上层规格说明如，系统需求规
GB/T9385一2008 格说明其他项目文件和其他适用的标准进行对比,以确保其相互一致 作为一种选择,顾客或用户可 以确定SRs是否正确地反映了实际需要 可追踪性使相应的规程更加便利并减少缺陷(见4.4.8). 4.4.3无歧义 当且仅当SRS中的每一项需求都只有一种解释,SRS才是无歧义的 这要求最终产品的每个特征 至少使用唯一的术语来描述 当在特定背景中使用的某个术语存在多种含义时,宜将该术语包含在术语表中,以便更加具体地说 明其含义 正如在GB/T8566中所描述的那样，SRS是软件生存周期中需求过程的一个重要部分,并被应用 于设计、实现、项目监控、验证和确认,以及培训活动中 对于编制人员和使用人员，sRS宜是无歧义 的 但是,这些人员通常并不具备相同的背景,因而对软件需求的描述不会倾向相同的形式 为开发人 员而改进的SRS表述,或许会降低用户对SRS的理解,反之亦然 .4.3.1到4.4.3.3给出了如何避免歧义性的建议 4.4.3.1 自然语言的缺陷 需求通常使用自然语言(如,议语)来编写 但自然语言具有固有的不明确性 使用自然语言编制 的SRS宜由独立的一方进行评审,以识别语言的含糊用法并予以纠正 44.3.2需求规格说明语言 避免自然语言周有的鼓义的一种方式是,使用特定的需求规格说明语言编写sRs 该语言处理器 可自动检测出许多同法.句法和语义错误 使用这类特定语言的缺点是,学习语言需要较长的时间 同时,多数非技术方面的使用者发现它们 不易理解 此外,这类语言倾向于表述某些特定类型的需求和处理某些特定类型的系统 因此这类语 言可能以难以捉摸的方式影响这些需求 4.4.3.3表述工具 -般而言,支持编制需求的方法、语言和工具分为三种通用类别;对象、过程和行为 面向对象的方 法按照现实世界的对象、它们的属性和这些对象完成的服务来组织需求;基于过程的方法将需求组织成 功能的层次结构,而这些功能通过数据流进行通信;基于行为的方法利用一些抽象的符号(如,谓词演 算、数学函数或状态机来描述系统的外部行为 这些工具和方法对编制SRs时的有用程度依赖于项目的规模和复杂性 这里并不试图描述和认 可任何特定的工具 当使用任何这类方法时,最好仍保持自然语言方式的描述,这样,不熟悉这些方法、符号的顾客仍然 能够理解SRS 4.4.4完备 4.4.4.1当且仅当SRs包含以下要素,SRS才是完备的 a 所有重要的需求,不论是否与功能、性能、设计约束、属性或者外部接口有关 尤其是由系统规 格说明所施加的任何外部需求都应当得到确认和处理 b 软件响应的定义,以说明软件对所有可实现的输人数据类型的响应 应当注意,对于有效和 无效输人数值两种情况,规定软件响应是重要的 SRS中所有图表的全面标记和索引,以及所有术语和度量单位的定义 c 4.4.4.2任何含有“待定”词语的SRs是不完备的 但是有时使用“待定”是不可避免的,若万一使用 “待定”时应做如下说明: a 对导致使用“待定”的情形进行描述(为什么答案未知),以便问题能得到解决; 描述为排除“待定”应采取的措施、由谁负责排除以及何时必须排除 4.4.5 致 4.4.5.1 -致是指内部一致性 如果SRS与某些更高层的文档如,系统规格说明)不一致,那么它是
GB/T9385一2008 不正确的见4.4.1 4.4.5.2当且仅当在SRs中描述的任何单个需求的子集之间相互不矛盾,SRS才是内部一致的 SRSs中可能存在下述三种类型的矛盾 现实世界对象的规定特征可能相互矛盾 如: a 报告输出的格式在一个需求中是表格形式,而在另一个需求中是文本形式; 2 个需求指出所有的灯是绿色,而另一个需求规定所有的灯是蓝色 b 在两个规定的行为之间可能存在逻辑上的或时间上的冲突 如: 个需求规定程序将对两个输人相加,另一个需求则规定程序将对这两个输人相乘; 个需求指出“A"必须总是在“B”之后,而同时在另一个需求中要求“A和B”同时发生 可能两个或更多的需求描述现实世界的相同对象,但使用不同的术语 如,在一个需求中程序 对用户输人的请求称为“提示符”,在另一个需求中称为“提示” 使用标准术语和定义可以改 善一致性 4.4.6重要性和/或稳定性分级 如果sRs中每条需求赋有标明其重要性或稳定性的标识,那么该sRs便按照重要性和/或稳定性 进行了分级 通常,与软件产品有关的所有需求并不具有相同的重要性 某些需求可能是基本的特别是与人身 生命有关的关键应用,而其他的可能是所期望的需求 sRs中的每个需求宜予以标识,以使需求在这方面的差异清晰和明确 按下述方式标识需求有 助于 a)使顾客更仔细地考虑每个需求,这样,常常会澄清顾客可能引人的任何隐藏的假设; b) 使开发人员做出正确的设计决定,并针对软件产品的不同部分做出相应适当工作的投人 4.4.6.1稳定性程度 可以用需求的期望变更次数来标识需求的稳定程度 4.4.6.2重要性程度 -种需求分级的方式是区分如下基本的、有条件的和可选的需求类别 另 -除非表示同意并满足了这类需求,否则软件将不被接受 a) 基本的 b 有条件的 表示这类需求会增强软件产品,但是,如果缺少这类需求,也不会导致软件产品 被拒收; c)可选的 表示该类功能需求可有可无,这赋予供方提出超出SRs的建议的机会和余地 4. ..4.7可验证 当且仅当SRS中的每个需求是可验证的,SRs才是可验证的 当且仅当存在某个有限的成本、有 效的过程,人或机器依照该过程能够检查软件产品满足某个需求,该需求才是可验证的 一般说来,任 何有歧义的需求都是不可验证的 不可验证的需求包含诸如“工作良好”“好的人机界面”和“通常应该发生”之类的陈述 因为不可 能定义“良好”,“好的”和“通常”,因此,这些需求不可能验证 陈述“程序应绝对不进人无限循环”是不 可验证的,因为理论上该特性是不可测试的 可验证陈述示例 程序输出应在事件开始20s内达到60%,在30s内达到100% 这样的陈述是可验证的,因为它使用了具体的术语和可测量的数值 如果不能设计出一种方法,以确定软件是否满足某个具体的需求,那么该需求宜被删除或被修改 4.4.8可修改 当且仅当sRs的结构和形式能够对任何需求进行容易,全面和一致的修改,同时保持该结构和形 式,SRS才是可修改的 一般地，可修改性要求SRS:
GB/T9385一2008 a)具有连贯、方便使用的结构,包含目次、索引及清晰的相互引用; b)没有冗余(即,相同的需求在SRs不应当出现在多处) 分别地表述每个需求,而不与其他需求相混淆 c 尽管冗余本身不是缺陷,但它容易导致错误 尽管冗余偶尔可以有助于SRs的可读性,但当对存 在冗余的文件更新时,可能会引起问题 例如,可能对出现多处的某个需求仅在一处做了修改,那么使 得SRS内容不一致 当需要冗余时,SRS宜包括一个清晰地交叉索引表,以增加其可修改性 4.4.9可追踪 如果SRS每个需求的来源是清楚的,并在将来编制或增强文档的过程中便于每个需求的索引,那 么该SRS是可追踪的 推荐以下两种类型的可追踪性 a)逆向可追踪性(即,到以前的开发阶段) 这依赖于每个需求清晰地指向其在早期文件的来源; b)正向可追踪性(即,到由SRS产生的所有文件) 这依赖于SRS中每个需求具有唯一的名称 或索引号 当软件产品进人运行和维护阶段时,SRs的正向可追踪性尤其重要 随着代码和设计文档的修 改,最要紧的是能够确定这些修改可能影响的全部的需求集合 4.5SRS的联合编制 软件开发过程宜从顾客与供方关于完成的软件必须做什么达成的协议开始 依照sRs的形式,该 协议宜联合起草 这一点很重要,因为通常不管是顾客还是供方,单方面都不具备编写一份良好SRS 的资格 a)顾客通常对软件设计和开发过程了解的不够,不足以编写实用的SRS; 供方通常对顾客的问题和从事的领域了解不够,不足以为系统规定满意的需求 b 因此,顾客和供方宜一起工作,以编写良好的、全面的和可理解的sRS. 当系统及其软件二者同时被定义时,存在一种特殊情况,软件的功能、接口,性能、及其他的属性和 限制条件不是预先定义的,而是联合定义并且需要协商和变更这使得满足4.4所述的特征更困难,但 尤其是,不符合其母系统需求规格说明的教件SRs是不正确的 更重要 本标准不具体讨论sRs的形式,语言的使用或良好的编写技巧,但是,编写良好的sRs十分重要 -般的技术写作书籍可用作编写指南 4.6SRS的演变 随着软件产品开发的进展，sRs可能需要演变 在项目开始时,规定某些细节是不可能的(例如、 对于一个交互程序,在需求阶段定义所有屏幕格式是不可能的) 随着sRs中的缺陷、不足和不准确之 处的发现,可能会相继发生对sRS的其他变更 在此过程中,两个重要的考虑事项如下 a)尽管可以预见对sRS的演变修订是不可避免的,但在某个时间对需求的规定应当尽可能完全 宜注明需求不完备的事实 和细致 宜启动正式的变更过程,以识别、控制、跟踪和报告指定的变更 已批准的需求变更宜按以下 b 方式纳人sRS中 l提供准确的和全面的变更审核追踪记录 2)允许对sRs的当前版本和先前版本进行评审 4.7原型法 在项目的需求阶段常常使用原型法 一些工具可简单、快捷地创建体现系统某些特征的原型 注，可参照AsTME1340;1996(计算机系统快迷原型法标准指南》. 原型的实用性有以下原因: 与阅读SRS和提出意见相比,顾客更有可能考察原型并提出建议; a b)原型可演示系统行为不可预见的方面,因此,原型不但提供答案,同时还提出一些新的问题
GB/T9385一2008 这有助于完善SRS 基于原型提出的SRS在开发过程中倾向更少的变更,从而减少开发时间 原型是用于提取软件需求的一种方式 诸如屏幕或报告格式之类的某些特征可以直接从原型中提 取 其他需求可以通过进行原型试验推导出来 4.8SRs中嵌入设计 4.8.1 一般来说,在SRS中尽量避免嵌人设计说明,在SRS中嵌人设计说明会过多地约束设计,并且 人为地把具有潜在危险的需求引人SRS. 个需求规定了系统某个外部可见的功能或属性 设计描述了系统某个具体的子部件和/或它与 其他子部件的接口 SRS编写人员应当清楚地区分识别所需要的设计约束和构想具体的设计之间的 差异 应当注意,SRS的每个需求限制了设计的可选择性 但这并不意味着每个需求就是设计 SRS应当规定对何数据执行何功能以便在何地为何人产生何种结果 SRS宜集中于所提供的服 务 SRS通常不规定设计事项,如 a)划分软件为各个模块; 分配功能到各个模块; b 描述模块之间的信息流或控制流; c d 选择数据结构 把设计相sRs完全割裂开来也是不现实的 在某些特殊情况下,某些需求可能严重地限制了 4.8.2 设计 对安全或保密安全方面的周密考虑可能增加一些直接反映设计约束的需求，例如 a用几个分开的模块来实现某些功能 b) 在程序的某些区域之间仅允许有限的通信; e)对临界的变量检查数据的完整性 有效的设计约束条件示例如;物理需求、性能需求、软件开发标准以及软件质量保证标准 因此,宜从完全外部的角度规定需求 当使用模型阐述需求时,应记住模型仅仅用来表明系统的外 部行为,并不规定设计 4.9sRs中嵌入项目需求 SRS宜关注软件产品,而不是软件产品的生产过程 项目需求表示了顾客和供方之间有关软件生产合同事宜的理解,因此不宜包括在SRs中 通常这些项目需求包括如下 a)成本 b 交付进度; e)报告规程 d 软件开发方法 e)质量保证 f 验证和确认准则 g)验收规程 项目需求在其他文档中规定,通常在软件开发计划、软件质量保证计划或者工作说明中规定 SRs的组成和内容要求 5.1综述 本章讨论组成SRS的每个基本组成部分和内容要求 图1以提纲形式列出这些部分,可作为编写 SRS的示例 尽管sRs不必要按照此提纲或使用这里给出的各章条的名称,但是，一份良好的SRS宜包括以下 论述的所有信息
GB/T9385一2008 目 次 引言 .1目的 .2范围 1.3定义、简写和缩略语 1.4引用文件 1.综述 2 总体描述 2.1产品描述 2.2产品功能 2.3用户特点 2.！约束 2.5假设和依赖关系 2.6需求分配 具体需求(对可能的具体需求的说明见5.4.1到5.4.8 也可参见附录A中关 3 于SRS几种不同模式 附录 索引 图1sRs提纲 5.2引言(SRs的第1章) SRS的引言部分应当提供整个SRS的概述,包括以下各条 目的; a b) 范围; e定义、简称和缩略语 d 引用文件 e)综述 5.2.1目的(SRs的1.1) 本条宜: a)描述SRS的目的; b 说明SRs的预期读者 5.2.2范围(sRs的1.2 本条宜: a)通过名称识别要生产/开发的软件产品例如,宿主数据库管理系统(DBMS),报告生成器等) D) 必要时,说明软件产品将做或不做什么 e)描述规定的软件的应用,包括相关的收益、目标和目的 d 如果上层规格说明(如,系统需求规格说明)存在,与上层规格说明类似的陈述保持一致 2. 3 5 定义、,简写和缩略语(sRs的1.3 本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义,这些信息可以通过引用 SRS中的一个或多个附录,或者引用其他文件的方式来提供 5.2.4引用文件SRs的1.4) 本条宜
GB/T9385一2008 a)提供SRS引用的所有文件的完整清单 D) 标识出每个文件的名称、报告编号(适用时、日期、出版组织; 标明可以获得引用文件的来源 c 这些信息可以通过引用附录或引用其他文档的方式提供 5.2.5综述SRS的1.5 本条宜: a)描述SRS的其余章条包含的内容; b)说明SRs是如何组织的 5.3总体描述(SRs的第2章) 本章宜描述影响产品及其需求的一般因素,而不叙述具体的需求 相反它提供需求的背景并使它 们更易理解,而在SRS的第3章将详细定义这些需求 本章通常由以下6条组成 产品描述 a b) 产品功能; 用户特点 c d 约束 假设和依赖关系; e f 需求分配 产品描述(sRs的2.1 5.3.1 本条宜把产品置于其他有关产品的全景之下 如果产品是独立的和完全自我包含的,这里宜如实 给予陈述 正如常出现的那样,如果sRs定义的产品是较大系统的组成部分,则本章宜将软件的功能 性与较大系统的需求相联系,而且宜识别软件和系统之间的接口 使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的 本条也宜描述在各种不同的约束下软件如何运行 如,这些约束可包括 系统接口; a 用户界面 b e) 硬件接口 软件接口 d 通信接口 f 内存 运行 g h 现场适应性需求等 5.3.1.1系统接口 本条宜列出每个系统接口,识别完成系统需求的软件功能以及与系统匹配的接口描述 5.3.1.2用户界面 本条宜规定以下方面: 在软件产品与用户之间每个界面的逻辑特征 这包括完成软件需求所需要的那些配置特征 a 例如,要求的屏幕显示格式、页面或窗口版式布局、任何报告或菜单的内容、或者可编程功能 键的设置); b)优化系统用户界面的所有方面 这可以简单地包括一个针对系统对用户的显示方式系统将 做什么和不做什么的清单 例如,可能是一项选择长或短的错误消息方面的需求 如同所有 其他需求一样,这些需求宜是可验证的,例如,“经过1h培训后,4级打字员能够在Zmin内 执行功能X”,而不是“打字员能够执行功能X”这也可以在标题为使用方便性章条的软件系
GB/T9385一2008 统属性中规定). 5.3.1.3硬件接口 本条宜规定系统硬件各部件与软件产品之间每个接口的逻辑特征,包括配置特征(端口数量、指令 集等),同样也覆盖这些事项,如,支持什么设备、如何支持以及采用什么协议 例如,相对逐行支持,终 端支持可能规定为全屏支持 5.3.1.4软件接口 本条宜规定对其他软件产品(例如,数据管理系统、操作系统、或数学软件包)的使用,以及与其他应 用系统(例如,账户接收系统和一般的会计记帐系统的链接)的接口 对于每个要求的软件产品,宜 提供 名称; a 助记符; D) e)规格说明编号; 版本号 d 来源 e) 对于每个接口,宜提供 相对此软件产品,接口软件的目的的论述; a b)按照消息内容和格式对接口的定义,不必要详细描述任何已文件化的接口,但要求引用定义 此接口的文件 5.3.1.5通信接口 本条宜定义不同的通信接口,如,局域网协议等 5.3.1.6内存约束 本条宜规定对主存和辅存的任何适用特征和限制 5.3.1.7操作 本条宜规定用户要求正常的和特定的操作,如 a)用户组织的不同操作模式(如,用户引发的操作); 交互操作的周期和无人值守操作的周期 b) e)数据处理支持功能 d 备份和恢复操作 注:有时此条规定作为用户界面的一部分 5.3.1.8现场适应性需求 本条宜: 对于给定的现场、任务或运行模式如,网格数、安全限制等),为任何数据或启动顺序定义 a 需求; b针对软件适应特定的安装现场或任务,规定应当修改的特征 5.3.2产品功能(SRs的2.2) 本条宜给出软件将执行主要功能的概要 例如,某个会计程序的SRS可在此部分关注顾客账户维 护,顾客财务报表及发票准备,而不涉及这些功能要求的大量细节 有时,本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明(如果存在)中摘 为了清晰,应当注意 录 a》功能宜以这样的方式组织.以使顾客或第一次阅读该文件的任何读者对功能列表容易理解， 可以使用文本或图示的方法,显示不同的功能及其之间的关系 这样的图示不必显示产品的 b 设计,但简要显示变量之间的逻辑关系
GB/T9385一2008 5.3.3用户特点SRs的2.3) 本条宜给出软件产品预期用户的一般特征,包括教育程度、经验、专业技术情况 它不宜指出具体 的需求,但宜给出SRS第3章中为何规定某些具体需求的原因 5.3.4约束(SRs的2.4) 本条宜给出将会限制开发人员选择的任何其他事项的一般描述 这些包括 a) 法规政策; b 硬件局限(如,信号时间要求); c 与其他应用的接口; d)并行操作; 审核功能; f 控制功能; g高级语言需求; 信号握手协议(如,.xoON-xOFF,ACK-NVACK); h iD 可靠性需求; 应用的关键性; k安全和保密安全考虑 5.3.5假设和依赖关系(SRS的2.5 本条宜列出影响sRs规定需求的每个因素 这些因素不是软件设计的限制条件但是它们的任 何变更可能影明sRs中的需求 例如,某个假设可能是软件产品指定的硬件具有某个特定操作系统 如果事实上该操作系统不能使用,那么SRS将做相应的修改 5.3.6需求分配(SRs的2.6 本条宜识别可能推迟到系统将来版本的需求 具体需求(Ss的第3章) 5 本章宜包括足够详细的所有软件需求,使设计人员能够设计系统以满足这些需求,并且使测试人员 能够测试该系统满足这些需求 贯穿本章,对于用户,运行人员或其他外部系统,每个规定的需求应当 是外部可理解的 这些需求至少应当包括,每个系统输人(激励),每个系统输出(响应)以及系统通过响 应某个输人或支持某个输出所执行的所有功能 由于这通常是sRs篇幅最大和最主要部分,以下原则 适用: a)规定的具体需求宜符合4.4描述的所有特征; b 具体需求宜引用较早的相关文件 e)所有的需求宜是唯一可标识的; d 宜注意需求的组织,使其具有最大的可读性 在考察组织需求的具体方式之前,了解5.4.1到5.4.7组成需求的各个不同项是有益的 5 4.1外部接口 本条宜是软件系统所有输人和输出的详细描述 它宜是对5.2的接口描述的补充,不宜重复前面 已有的信息 宜包括以下内容和格式: 项的名称; a b)目的描述; 输人源和输出目的地; c d)有效范围准确度和/或容限 测量单位; e f 定时; 10
GB/T9385一2008 g与其他输人/输出的关系; h 屏显格式/组织; i 窗口格式/组织; 数据格式; j 命令格式 k 结束消息 5.4.2功能 功能需求宜定义软件在接收和处理输人以及处理和产生输出中必须发生的基本动作 一般情况下 使用“系统应”的方式来陈述 这些包括 a) 对输人有效性的核查; b)操作的准确顺序; 异常情况响应,包括: 溢出; 1 2) 通信设施; 3)错误处理和恢复 d 参数影响 输人与输出的关系,包括 e 输人/输出顺序; 从输人到输出转换的公式 2) 尽管将功能需求划分为子功能或子过程可能是适当的,但这并不意味着软件设计同样以这样的方 式划分 5.4.3性能需求 本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求 静态数量化需求可能 包括 a 支持的终端数量; 支持同时运行的用户数量 b 要处理的信息量和类型 C 有时,静态数量需求包含在命名为"能力"的独立部分 动态数量化需求可能包括,如,在正常和高峰工作负载条件在某时段内处理的事务处理数.任务数 和数据量 所有这些需求宜以可测量的方式规定 如: 应在小于1s内处理95%的交易量 而不是 操作方不需等待事务处理结束 注:适用于某个具体功能的数量化限制,通常作为该功能处理描述部分予以规定 5.4.4数据库逻辑需求 宜规定将置于数据库的任何信息的逻辑需求 这可包括: 不同功能使用的信息类型; a b 使用频度; 访问能力 c d)数据实体及其之间的关系; 完整性约束 e 1l
GB/T9385一2008 f 数据保存需求 5.4.5设计约束 宜规定可能由其他标准、硬件局限等引发的设计约束 5.4.5.1标准依从性 本条宜规定来自现存标准或法规的需求 它们可能包括: a)报告格式; b数据命名 会计规程 c d 审核追踪 例如,可以规定追踪处理活动的软件需求 为了最低满足法规或财务标准,对于某些应用这样的追 踪是需要的 例如,审核追踪需求可能规定,对于支付薪金数据库的所有变更,必须在一个追踪文档中 记录支付前后的数额 软件系统属性 5.4.6 有一些软件属性可以作为需求 规定所要求的软件属性是重要的这样才能客观地验证属性的实 现情况 5.4.6.1到5.4.6.5给出了部分示例 5.4.6.1 可靠性 本条宜规定要求的因素，以便建立在交付时软件系统所要求的可靠性 5.4.6.2可用性 为了确保整个系统已定义的可用性程度,宜规定所要求的因素,如,检查点、恢复以及重启动 5.4.6.3安全保密性 由于事故、,恶意访问、使用、修改、破坏或泄露,本条宜规定需要保护软件的因索 这方面可能的具 体需求包括 D使用某些密码技术; 保留某些特定数据组的历史或记录 b) e)分配某些功能到不同的模块; 在程序的某些域间限制通信 d e)对于关键变量检查数据的完整性 5. 4.6.4可维护性 本条宜规定与软件本身维护简易性有关的软件属性 可以对模块化、接口和复杂性等有一定的要 求 但不宜仅因为是良好设计实践就将其作为需求 5.4.6.5可移植性 本条宜规定与软件移植到其他主机和/或操作系统简易性相关的软件属性 这可能包括 a)依赖主机代码模块的百分比; b) 依赖主机代码的百分比; e已证明可移植语言的使用 d)特定编译器或语言子集的使用 特定操作系统的使用 e 5.4.7具体需求的组织 除了微小的系统之外,任何系统倾向有大量的详细的需求 由此,宜仔细考虑这些需求的组织方 式,以最优化可理解性 对于所有的系统不存在单一的最优化组织方式 不同类型的系统SRs的第3 章有不同的需求组织方式 5.4.7.1到5.4.7.7描述了一些组织方式 5.4.7.1 系统模式 依赖于运行模式,某些系统的行为显著不同 例如,根据其运行模式:培训、正常运行或者应急,某 12
GB/T9385一2008 个控制系统可能具有不同的功能集合 当按照运行模式组织该部分时,宜采用第A.1章或第A.2章的 提纲 需求组织方式的选择取决于系统接口和性能是否依赖于运行模式 5.4.7.2用户类型 有些系统对不同的用户提供不同的功能集合 例如,对于一般乘客、维护人员和消防人员,电梯控 制系统显示不同的能力 当按照用户类别组织该部分时,宜采用第A.3章的提纲 5.4.7.3对象 对象是现实世界中的实体,系统具有与其对应的部分 例如,在病人监控系统中,对象包括病人传 感器、护士、房间、医师、医药等 与每个对象相联系的是一组属性(对象具有的)和功能(对象执行的. 这些功能也称之为服务、方法或过程 当按照对象组织该部分时,宜采用第A.4章的提纲 应注意,对 象组可能共有某些属性和服务,要按照类别把这些组织在一起 5.4.7.4特征 系统特征是从外部希望得到的服务,可能要求一系列的输人以产生希望的结果 例如,在电话系统 中,系统特征包括本地话务,话务转接.以及会议话务 一般的,系统每个特征按照- 系列激励-响应对 的方式描述 当按照系统特征组织该部分时,宜采用第A.5章的提纲 5.4.7.5激励 某些系统可以根据激励描述其功能的方式最佳地组织其需求 例如,飞机自动着陆系统的功能,可 依照动力降低、风向切变,机身摇摆突变,垂直速度限值等,组织到相应的部分 当按照激励方式组织该 部分时,宜采用第A.6章的提纲 5.4.7.6响应 有些系统可以通过描述其支持产生某个响应的所有功能,最佳地组织其需求 例如,某个人员管理 系统的功能,可按照与产生薪金支付有关的所有功能、与产生当前职员清单有关的所有功能,等等,予以 组织到相应的部分 宜采用第A.6章的提纲(所有的激励之处由响应替代. 5. .4.7.7功能层次 当上述组织方式证明没有益处时,可按照共同的输人、共同的输出或者共同的内部数据访问,将系 统总体功能性组织成为一个功能层次 数据流图和数据词典可以用来表示功能和数据之间的相互关 系 当按照功能层次组织该部分时,宜采用第A.7章的提纲 5.4.8附加说明 在编制新的SRS时,在5.4.7.7给出的多种组织技术可能都是适用的 在这种情况下,宜依据该 系统的特定要求所剪裁出的若干层次来组织特定的需求 例如,第A.8章组织形式结合了用户类别和 系统特征 任何附加的需求,可以在sSRS的结尾处放在一个独立的部分 有许多现行可用于帮助需求文档化的符号、方法和自动化支持工具 就大部分而言,它们的有效性 是组织的职能 例如,当按照运行模式组织时,限定的状态机或状态图表可能证明是有益的;当按照对 象组织时,面向对象的分析可能是有益的;当按照系统特征组织时,激励-响应序列可能证明是有益的 当按照功能结构组织时,数据流图和数据词典可能证明是有益的 在第A.1章到第A.8章给出的任何提纲中,称为“功能需求I”的那些条目可以用自然语言、伪码、 系统定义语言、或用标题为引言、输人、处理、输出4个子部分予以描述 5.5支持信息 支持信息以使SRs更容易使用,包括 目次; a b 索引; e)附录 5.5.1 目次和索引 目次和索引十分重要,宜按照一般的文档编写惯例 13
GB/T9385一2008 5.5.2附录 附录并不总是实际的SRS的一部分或总是需要的 附录可以包括: a)输人/输出格式示例,成本分析研究,或者用户调查的结果; b)有助于读者理解SRs的支持或背景信息; 软件所解决的问题描述 d)对代码和媒体的特殊包装说明,以满足安全、出口、初始装人、或其他需求 当包括附录时，SRS宜明确地规定附录是否作为需求的部分 14
GB/T9385一2008 附 录A 资料性附录 SRs提纲模板 按照运行模式组织的sRs第3章模板版本1) 具体需求 3.1外部接口需求 用户界面 3.1.1 3.1.2硬件接口 软件接口 3.l.3 通信接口 3.1. 3.2功能需求 模式1 3 2.1 功能需求1.1 3.2.1.l 3.2.1.n功能需求1.n 模式2 3.2.2 3.2.m模式mn 功能需求m.1 3.2.m. 3.2.m.n功能需求m." 3.3性能需求 3.4设计约束 3.5软件系统属性 3.6其他需求 按照运行模式组织的SRS第3章模板版本2 具体需求 3 功能需求 3 模式1 外部接口 用户界面 硬件接口 l1.3 软件接口 通信接口 3.1.1.2功能需求 3.1.1.2.1功能需求1 l5
GB/T9385一2008 3.1.1.2.n功能需求n 3.1.1.3性能 3.1.2模式2 3.1.m模式n 3.2设计约束 3. 软件系统属性 其他需求 3 按照用户类别组织的SRs第3章模板 具体需求 3.1外部接口需求 .1.1用户界面 33 3.1.2硬件接口 .1.3软件接口 33 3.1.4通信接口 3. .2 功能需求 3.2.1 用户类别1 功能需求1.1 功能需求1.n 用户类别2 用户类别m" 3.2.mn.1 功能需求m.l 3,2..n 功能需求 71，71 性能需求 3 设计约束 软件系统属性 其他需求 3 按照对象组织的SRs第3章模板 具体需求 3.1外部接口需求 用户界面 3.l.l 3.1.2硬件接口 3.1.3软件接口 3.1.4通信接口 3.2类/对象 16
GB/T9385一2008 3.2.1类/对象1 属性直接的或继承的 3.2.1.l 32.1.1.1属性1 3.2.1.1.n属性n 3.2.1.2功能服务、方法、直接的或继承的) 3.2.1.2.1功能需求1.1 3.2.1.2.m功能需求1.m 3.2.1.3消息接收的或发送的通信 3.2.2类/对象" 3. .2.p类/对象p" 3 3. 性能需求 3 设计约束 3.5软件系统属性 3.6其他需求 A.5按照系统特征组织的sRs第3章模板 具体需求 3.1外部接口需求 3.1.1用户界面 3.1.2硬件接口 软件接口 3.l1.3 3.1.4通信接口 系统特征 系统特征1 3 2 特征说明/目的 激励/响应序列 2 2 1.3 相关的功能需求 功能需求1 功能需求n 系统特征2" 3.2.m系统特征m" 3. 性能需求 3 设计约束 3 3. 软件系统属性 5 其他需求 3
GB/T9385一2008 A.6按照激励组织的SRs第3章模板 具体需求 3.1外部接口需求 3.1.1用户界面 3.1. 硬件接口 2 3.1.3软件接口 3.1.4通信接口 3.2功能需求 3. .2.1激励1 3.2.1.1功能需求1.1 3.2.1.n功能需求1." 2 3.2. 激励2 3.2.m 激励 3.2.m.l 功能需求" n.l 3.2, n 功能需求 n，7n 3.3性能需求 3.4 设计约束 软件系统属性 3 其他需求 按照功能层次组织的sRs第3章模板 具体需求 外部接口需求 3.1 3.1.1 用户界面 硬件接口 3.1.2 3 软件接口 1.3 通信接口 3 功能需求 3 信息流 数据流图1 数据实体 有关的过程 拓扑图 数据流图2 2 1.2.1数据实体 1.2. 2' 有关的过程 3 2 1.2.3拓扑图 3 2 18
GB/T9385一2008 3. .2.1.n数据流图n 3.2.1.n.1 数据实体 有美的过犁 2 3.2.1.n 3.2.1.n.3拓扑图 2.2过程描述 3 过程1 输人数据实体 3. 2.2.1.1 过程算法或公式 1.2 2 受影响的数据实体 2 2 过程2 输人数据实体 3. 2 2.2.2过程算法或公式 3 2 3 2. .2.2.3受影响的数据实体 3.2.2.m过程m" 输人数据实体 2.2.m.1 过程算法或公式 2. 2 2.m. 3.2.2.m.3受影响的数据实体 3 数据构建规范 构建1 2. .3.1.1记录类型 3 2.3.1.2组成字段 2 3.2.3.2构建 记录类型 2.3.2.1 3.2.3.2.2组成字段 构建" 3.2.3，力！记录类型 3.2.3.. 2 组成字段 2 数据词典 3.2.4.1 数据元素1 2 名称 4.l.l 4.1.2表示法 2 3.2. 单位/格式 精确度/准确度 4.1.4 1.5范围 数据元素 2 2 4.2.1 名称 3.2.4.2.2表示法 4.2.3单位/格式 3. 精确度/准确度 3.2.4.2.4 5 3.2.4.2. 范围 19
GB/T9385一2008 3.2.4.g数据元素g" 名称 3.2.4.g.l 3.2.4.g.2表示法 3.2.4.g.3单位/格式 3.2.4.q. 精确度/准确度 3.2.4.g.5范围 性能需求 3. .3 3.4设计约束 3.5软件系统属性 3 6 其他需求 A.8体现多种组织形式的SRs第3章模板 具体需求 3.1外部接口需求 s .1.1用户界面 3.1.2硬件接口 1.3软件接口 3 3.1.4通信接口 3. 2 功能需求 用户类别1 3.2.1.1特征1.l 特征说明/目的 3. 激励/响应序列 1.3 有关的功能需求 特征1.2 特征说明/目的 激励/响应序列 有关的功能需求 3.2.lmn特征l.mn 特征说明/目的 3 2.1.m. 激励/响应序列 3 2 2.l.mn. 1.m.3有关的功能需求 3 2 用户类别2 3.2.n用户类别n 性能需求 3. .3 3.4设计约束 3. 5 软件系统属性 其他需求 6 3. 20
GB/T9385一2008 参 考 文 献 [1]ASTME1340:1996计算机系统快速原型法标准指南