GBT9385-200X计算机软件需说明编制规范-国标送审稿

'ICS35.080L77中华人民共和国国家标准GB/T9385—××计算机软件需求说明编制规范Specificationfordrawupcomputersoftwarerequirementsspecification(送审稿)××××-××-××发布××××-××-××实施国家质量监督检验检疫总局发布 GB/T9385—××目次前言.................................................................................II引言................................................................................III1范围................................................................................12规范性引用文件......................................................................13术语和定义..........................................................................14SRS的编制原则.....................................................................15SRS的组成和内容要求...............................................................7附录A（资料性附录）SRS提纲模版....................................................15A.1按照运行模式组织的SRS第3章模板（版本1）...................................15A.2按照运行模式组织的SRS第3章模板（版本2）...................................15A.3按照用户类别组织的SRS第3章模板...............................................16A.4按照对象组织的SRS第3章模版...................................................17A.5按照系统特征组织的SRS第3章模板...............................................17A.6按照激励组织的SRS第3章模版...................................................18A.7按照功能层次组织的SRS第3章模板...............................................19A.8体现多种组织形式的SRS第3章模版...............................................21I GB/T9385—××前言本标准的附录A是资料性附录。本标准由中华人民共和国信息产业部提出。本标准由全国信息技术标准化技术委员会归口。本标准起草单位：信息产业部电子工业标准化研究所、航天科技集团第十二研究所、上海计算机软件开发中心、东方通科技、浦东软件园。本标准主要起草人：II GB/T9385—××引言本标准描述了软件需求规格说明的编制方法。它基于以下设想，即软件需求规格说明确定过程的结果是一份明确和完备的规格说明文档。本标准将有助于：——软件的客户准确地描述其希望得到什么；——软件的供方正确地理解客户想要什么；——对于实现以下目标的有关单位和人员：.为其所在的组织编制一份标准的软件需求规格说明（SRS）提纲；.定义其具体软件需求规格说明的格式和内容；.编制其它的本地支持资料，如，SRS质量检查清单、或SRS编写者手册。对于客户、供方和其他有关人员，一份好的SRS可能带来一些具体的益处，例如：——对于提供什么软件产品，为客户和供方之间的协议建立基础。在SRS中软件功能的完备描述将协助潜在用户，以便确定指定的软件是否满足其需要，或者为满足其需要应如何修改软件；——减少开发工作。SRS文档的编制迫使客户组织有关各方或人员在设计之前严格考虑所有的需求，并减少以后的重新设计、重新编码和重新测试。对SRS中的各项需求进行仔细评审，可以在开发周期的早期揭示某些遗漏、误解和不一致，此时这些问题更容易纠正；——为估计成本和进度提供基础。SRS中给出的待开发产品的描述是估计项目成本的现实基础，可用于取得投标认可或得出价格估算；——为验证和确认提供基线。通过一份好的SRS文档，组织可提出其更加有效的验证和确认计划。作为开发合同的一部分，SRS提供了可用于测量依从性的基线；——便于软件产品转移。SRS文档使软件产品转移到新的用户或机器更容易。客户因此发现软件产品更容易转移到组织的其他部门，供方发现软件产品更容易转移到新的客户；——作为进一步增强的基础。因为SRS文档讨论的是产品，而不是开发它的项目，因此,SRS是已开发产品后续增强的基础。尽管SRS文档或许需要修改，但它确实为后续的产品评价提供了基础。III GB/T9385—××计算机软件需求说明编制规范1范围本标准给出了软件需求规格说明（SRS）的编制要求，描述了一份好的SRS的内容和质量，并在附录A中给出一些SRS提纲示例。本标准可直接用于编制SRS。本标准并不限定任何编制SRS特定的方法、命名约定和工具。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T8566信息技术软件生存周期过程GB/T11457软件工程术语ASTME1340-1996计算机系统快速原型法标准指南3术语和定义GB/T11457中确立的以及下列术语和定义适用于本标准。3.1合同contract由客户和供方共同签署的具有法律约束力的文件，其中包括产品的技术、组织、成本和进度的需求。合同同样可包括某些非正式的、但有用的信息，如，参与各方的承诺或期望。3.2客户customer为产品支付费用，并通常（但不必要）确定需求的个人或群体。在某些情况下，客户和供方可以是同一组织的成员。3.3供方supplier为客户开发产品的个人或群体。在某些情况下，客户和供方可以是同一组织的成员。3.4用户user直接运行产品或与产品进行交互作用的个人或群体。用户和客户通常不是同一个人或群体。4SRS的编制原则4.1综述本章给出了编制SRS时宜考虑的事项及编制原则：1 GB/T9385—××a)SRS的基本性质；b)SRS的环境；c)好的SRS的特性；d)SRS的联合编制；e)SRS演变；f)原型法；g)SRS中嵌入设计；h)SRS中嵌入项目需求。4.2SRS的基本性质SRS是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。SRS可由来自供方、客户或双方的一个或者多个人员编写，4.5推荐由来自供方和客户双方的人员联合编写。SRS编写人员应关注以下基本点：a)功能——软件将执行什么功能？b)外部接口——软件如何与人、系统的硬件及其他硬件和其他软件进行交互？c)性能——各种软件功能的速度、可用性、响应时间、恢复时间等是多少？d)属性——软件的可移植性、正确性、可维护性、安全性如何？e)影响产品实现的设计约束——是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求？编写人员宜避免把设计或项目需求写入SRS中。SRS的内容详见第5章。4.3SRS的环境很重要的一点是应考虑SRS在整个项目计划中的作用。项目计划的定义见GB/T11457。软件既可以基本上包括了项目的所有功能，也可以是更大系统的一部分。在后一种情况，典型的SRS将指出系统及其软件部分的接口，并将外部性能和功能需求写入软件部分。显然，SRS应当在系统需求上扩展并与其保持一致。GB/T8566描述了软件生存周期的各个步骤，以及每步适用的输入。与软件生存周期等有关的其他标准，可对软件需求进行补充。因为SRS在软件开发过程中发挥特定的作用，编写人员宜谨慎对待，不超出其作用的范围。这意味着SRS：a)应当正确地定义所有软件需求。因为要处理任务的性质或项目的具体特性，可能存在一项软件需求。b)不应当描述任何设计或实现的细节。这些内容应当在项目的设计阶段进行描述。c)不应当对软件设置附加的限制条件。这些内容可在其他文件中规定，如，软件质量保证计划。因此，编写适当的SRS限定了正确设计的范围，但不规定任何具体的设计。4.4好的SRS的特征SRS宜是：a)正确；b)无歧义；c)完备；d)一致；e)重要性和/或稳定性分级；f)可验证；g)可修改；2 GB/T9385—××h)可追踪。4.4.1正确当且仅当SRS中的每一项需求都是软件应满足的需求，SRS才是正确的。不存在确保SRS正确性的工具或规程。应当把SRS与任何适用的上层规格说明（如，系统需求规格说明）、其他项目文件和其他适用的标准进行对比，以确保其相互一致。作为一种选择，客户或用户可以确定SRS是否正确地反映了实际需要。可追踪性使相应的规程更加便利并减少缺陷（见4.4.8）。4.4.2无歧义当且仅当SRS中的每一项需求都只有一种解释，SRS才是无歧义的。这要求最终产品的每个特征至少使用唯一的术语来描述。当在特定背景中使用的某个术语存在多种含义时，应当将该术语包含在术语表中，以便更加具体地说明其含义。正如在GB/T8566中所描述的那样，SRS是软件生存周期中需求过程的一个重要部分，并被应用于设计、实现、项目监控、验证和确认，以及培训活动中。对于编制人员和使用人员，SRS应当是无歧义的。但是，这些人员通常并不具备相同的背景，因而对软件需求的描述不会倾向相同的形式。为开发人员而改进的SRS表述，或许会降低用户对SRS的理解，反之亦然。4.4.2.1到4.4.2.3给出了如何避免歧义性的建议。4.4.2.1自然语言的缺陷需求通常使用自然语言（如，汉语）来编写。但自然语言具有固有的不明确性。使用自然语言编制的SRS应当由独立的一方进行评审，以识别语言的含糊用法并予以纠正。4.4.2.2需求规格语言避免自然语言固有的歧义的一种方式是，使用特定的需求规格语言编写SRS。该语言处理器可自动检测出许多词法、句法和语义错误。使用这类特定语言的缺点是，学习语言需要较长的时间。同时，多数非技术方面的使用者发现它们不易理解。此外，这类语言倾向于表述某些特定类型的需求和处理某些特定类型的系统。因此，这类语言可能以难以捉摸的方式影响这些需求。4.4.2.3表述工具一般而言，支持编制需求的方法、语言和工具分为三种通用类别：对象、过程和行为。面向对象的方法按照现实世界的对象、它们的属性和这些对象完成的服务来组织需求；基于过程的方法将需求组织成功能的层次结构，而这些功能通过数据流进行通信；基于行为的方法利用一些抽象的符号（如，谓词演算）、数学函数或状态机来描述系统的外部行为。这些工具和方法对编制SRS时的有用程度依赖于项目的规模和复杂性。这里并不试图描述和认可任何特定的工具。当使用任何这类方法时，最好仍保持自然语言方式的描述，这样，不熟悉这些方法、符号的客户仍然能够理解SRS。4.4.3完备当且仅当SRS包含以下要素，SRS才是完备的：a)所有重要的需求，不论是否与功能、性能、设计约束、属性或者外部接口有关。尤其是由系统规格说明所施加的任何外部需求都应当得到确认和处理。b)在所有可实现的情形类别中，对所有可实现输入数据类别的软件响应的定义。应当注意，对于有效和无效输入数值两种情况，规定软件响应是重要的。c)SRS中所有图表的全面标记和索引，以及所有术语和度量单位的定义。4.4.3.1关于“待定”一词的使用3 GB/T9385—××任何含有“待定”词语的SRS是不完备的。但是有时使用“待定”是不可避免的，若万一使用“待定”时应做如下说明：a)对导致使用“待定”的情形进行描述（为什么答案未知），以便问题能得到解决；b)描述为排除“待定”应采取的措施、由谁负责排除以及何时必须排除。4.4.4一致一致是指内部一致性。如果SRS与某些更高层的文档（如，系统规格说明）不一致，那么它是不正确的（见4.4.1）。4.4.4.1内部一致性当且仅当在SRS中描述的任何单个需求的子集之间相互不矛盾，SRS才是内部一致的。SRS中可能存在下述三种类型的矛盾：a)现实世界对象的规定特征可能相互矛盾。如：1)报告输出的格式在一个需求中是表格形式，而在另一个需求中是文本形式；2)一个需求指出所有的灯是绿色，而另一个需求规定所有的灯是蓝色。b)在两个规定的行为之间可能存在逻辑上的或时间上的冲突。如：1)一个需求规定程序将对两个输入相加，另一个需求则规定程序将对这两个输入相乘；2)一个需求指出“A”必须总是在“B”之后，而同时在另一个需求中要求“A和B”同时发生。c)可能两个或更多的需求描述现实世界的相同对象，但使用不同的术语。如，在一个需求中程序对用户输入的请求称为“提示符”，在另一个需求中称为“提示”。使用标准术语和定义可以改善一致性。4.4.5重要性和/或稳定性分级如果SRS中每条需求赋有标明其重要性或稳定性的标识，那么该SRS便按照重要性和/或稳定性进行了分级。通常，与软件产品有关的所有需求并不具有相同的重要性。某些需求可能是基本的，特别是与人身生命有关的关键应用，而其他的可能是所期望的需求。SRS中的每个需求应当予以标识，以使需求在这方面的差异清晰和明确。按下述方式标识需求有助于：a)使客户更仔细地考虑每个需求，这样，常常会澄清客户可能引入的任何隐藏的假设；b)使开发人员做出正确的设计决定，并针对软件产品的不同部分做出相应适当工作的投入。4.4.5.1稳定性程度标识需求的一种方法是使用其稳定性的大小。基于将要发生的、影响软件系统所支持组织、功能和人员的事件的知识和经验，任何需求的稳定性可以以其期望的变更次数来表示。4.4.5.2必要性程度另一种需求分级的方式是区分如下基本的、有条件的和可选的需求类别：a)基本的——除非表示同意并满足了这类需求，否则软件将不被接受；b)有条件的——表示这类需求会增强软件产品，但是，如果缺少这类需求，也不会导致软件产品被拒收；c)可选的——表示该类功能需求可有可无，这赋予供方提出超出SRS的建议的机会和余地。4.4.6可验证当且仅当SRS中的每个需求是可验证的，SRS才是可验证的。当且仅当存在某个有限的成本、有效的过程，人或机器依照该过程能够检查软件产品满足某个需求，该需求才是可验证的。一般说来，任何有歧义的需求都是不可验证的。4 GB/T9385—××不可验证的需求包含诸如“工作良好”、“好的人机界面”和“通常应该发生”之类的陈述。因为不可能定义“良好”、“好的”和“通常”，因此，这些需求不可能验证。陈述“程序应绝对不进入无限循环”是不可验证的，因为理论上该特性是不可测试的。可验证陈述示例：程序输出应在事件开始20s内达到60%，在30s内达到100%。这样的陈述是可验证的，因为它使用了具体的术语和可测量的数值。如果不能设计出一种方法，以确定软件是否满足某个具体的需求，那么，该需求应当被删除或修改。4.4.7可修改当且仅当SRS的结构和形式能够对任何需求进行容易、全面和一致的修改，同时保持该结构和形式，SRS才是可修改的。一般地,可修改性要求SRS：a)具有连贯、方便使用的结构，包含目次、索引及清晰的相互引用；b)没有冗余（即，相同的需求在SRS不应当出现在多处）；c)分别地表述每个需求，而不与其他需求相混淆。尽管冗余本身不是缺陷，但它容易导致错误。尽管冗余偶尔可以有助于SRS的可读性，但当对存在冗余的文件更新时，可能会引起问题。例如，可能对出现多处的某个需求仅在一处做了修改，那么使得SRS内容不一致。当需要冗余时，SRS宜包括一个清晰地交叉索引表，以增加其可修改性。4.4.8可追踪如果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的演变修订是不可避免的，但在某个时间对需求的规定应当尽可能完全和细致。宜注明需求不完备的事实；5 GB/T9385—××b)宜启动正式的变更过程，以识别、控制、跟踪和报告指定的变更。已批准的需求变更宜按以下方式纳入SRS中：1)提供准确的和全面的变更审核追踪记录；2)允许对SRS的当前版本和先前版本进行评审。4.7原型法在项目的需求阶段常常使用原型法。一些工具可简单、快捷地创建体现系统某些特征的原型。参照ASTME1340-96。原型的实用性有以下原因：a)与阅读SRS和提出意见相比，客户更有可能考察原型并提出建议；b)原型可演示系统行为不可预见的方面，因此，原型不但提供答案，同时还提出一些新的问题，这有助于完善SRS；c)基于原型提出的SRS在开发过程中倾向更少的变更，从而减少开发时间。原型是用于提取软件需求的一种方式。诸如屏幕或报告格式之类的某些特征可以直接从原型中提取。其他需求可以通过进行原型试验推导出来。4.8SRS中嵌入设计一般来说，在SRS中尽量避免嵌入设计说明，在SRS中嵌入设计说明会过多地约束设计，并且人为地把具有潜在危险的需求引入SRS。一个需求规定了系统某个外部可见的功能或属性。设计描述了系统某个具体的子部件和/或它与其它子部件的接口。SRS编写人员应当清楚地区分识别所需要的设计约束和构想具体的设计之间的差异。应当注意，SRS的每个需求限制了设计的可选择性。但这并不意味着每个需求就是设计。SRS应当规定对何数据执行何功能以便在何地为何人产生何种结果。SRS宜集中于所提供的服务。SRS通常不规定设计事项，如：a)划分软件为各个模块；b)分配功能到各个模块；c)描述模块之间的信息流或控制流；d)选择数据结构。4.8.1必要的设计需求把设计和SRS完全割裂开来也是不现实的。在某些特殊情况下，某些需求可能严重地限制了设计。对安全或保密安全方面的周密考虑可能增加一些直接反映设计约束的需求，例如：a)在某些分开的模块中保持某些功能；b)在程序的某些区域之间仅允许有限的通信；c)对临界的变量检查数据的完整性。有效的设计约束条件示例如：物理需求、性能需求、软件开发标准、以及软件质量保证标准。因此，宜从完全外部的角度规定需求。当使用模型阐述需求时，应记住模型仅仅用来表明系统的外部行为，并不规定设计。4.9SRS中嵌入项目需求SRS宜关注软件产品，而不是软件产品的生产过程。项目需求表示了客户和供方之间有关软件生产合同事宜的理解，因此不宜包括在SRS中。通常这些项目需求包括如下：a)成本；b)交付进度；c)报告规程；d)软件开发方法；e)质量保证；6 GB/T9385—××f)验证和确认准则；g)验收规程。项目需求在其他文档中规定，通常在软件开发计划、软件质量保证计划或者工作说明中规定。5SRS的组成和内容要求5.1综述本章讨论组成SRS的每个基本组成部分和内容要求。图1以提纲形式列出这些部分，可作为编写SRS的示例。尽管SRS不必要按照此提纲或使用这里给出的各章条的名称，但是，一份良好的SRS宜包括这里讨论的所有信息。目次1.引言1.1目的1.2范围1.3定义、简写、缩略语1.4引用文件1.5综述2.总体描述2.1产品描述2.2产品功能2.3用户特点2.4约束条件2.5假设和依赖关系2.6需求分配3.具体需求（对可能的具体需求的说明见5.3.1到5.3.8。也可参见附录A中关于SRS几种不同模式。）附录索引图1：SRS提纲5.2引言（SRS部分1）SRS的引言部分应当提供整个SRS的概述，包括以下各条：a)目的；b)范围；c)定义、简写和缩略语；d)引用文件；e)综述。5.2.1目的（SRS的1.1）本条宜：a)描述SRS的目的；b)说明SRS的预期读者。5.2.2范围（SRS的1.2）本条宜：a)通过名称识别要生产/开发的软件产品（即，宿主数据库管理系统（DBMS）、报告生成器等）；7 GB/T9385—××b)必要时，说明软件产品将做或不做什么；c)描述规定的软件的应用，包括相关的收益、目标和目的；d)如果上层规格说明（如，系统需求规格说明）存在，与上层规格说明类似的陈述保持一致。5.2.3定义、简写和缩略语（SRS的1.3）本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义，这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供。5.2.4引用文件（SRS的1.4）本条宜：a)提供SRS引用的所有文件的完整清单；b)标识出每个文件的名称、报告编号（适用时）、日期、出版组织；c)标明可以获得引用文件的来源。这些信息可以通过引用附录或引用其他文档的方式提供。5.2.5综述（SRS的1.5）本条宜：a)描述SRS的其余章条包含的内容；b)说明SRS是如何组织的。5.3总体描述（SRS的第2章）本章宜描述影响产品及其需求的一般因素，而不叙述具体的需求。相反，它提供需求的背景并使它们更易理解，而在SRS的第3章将详细定义这些需求。本章通常由以下6条组成：a)产品描述；b)产品功能；c)用户特点；d)约束；e)假设和依赖关系；f)需求分配。5.3.1产品描述（SRS的2.1）本条宜把产品置于其他有关产品的全景之下。如果产品是独立的和完全自我包含的，这里宜如实给予陈述。正如常常出现的那样，如果SRS定义的产品是较大系统的组成部分，则本章宜将软件的功能性与较大系统的需求相联系，而且宜识别软件和系统之间的接口。使用框图展示较大系统的主要部分、相互联系、以及外部接口是有帮助的。本条也宜描述在各种不同的约束下软件如何运行。如，这些约束可包括：a)系统接口；b)用户界面；c)硬件接口；d)软件接口；e)通信接口；f)内存；g)运行；h)现场适应性需求。5.3.1.1系统接口本条宜列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。5.3.1.2用户界面本条宜规定以下方面：8 GB/T9385—××a)在软件产品与用户之间每个界面的逻辑特征。这包括完成软件需求所需要的那些配置特征（例如，要求的屏幕显示格式、页面或窗口版式布局、任何报告或菜单的内容、或者可编程功能键的设置）；b)优化系统用户界面的所有方面。这可以简单地包括一个针对系统对用户的显示方式系统将做什么和不做什么的清单。例如，可能是一项选择长或短的错误消息方面的需求。如同所有其他需求一样，这些需求应当是可验证的，例如，“经过1h培训后，4级打字员能够在Zmin内执行功能X”，而不是“打字员能够执行功能X”（这也可以在标题为使用方便性章条的软件系统属性中规定）。5.3.1.3硬件接口本条宜规定系统硬件各部件与软件产品之间每个接口的逻辑特征，包括配置特征（端口数量、指令集等），同样也覆盖这些事项，如，支持什么设备、如何支持以及采用什么协议。例如，相对逐行支持，终端支持可能规定为全屏支持。5.3.1.4软件接口本条宜规定对其他软件产品（例如，数据管理系统、操作系统、或数学软件包）的使用，以及与其他应用系统（例如，帐户接收系统和一般的会计记帐系统的链接）的接口。对于每个要求的软件产品，宜提供：-名称；-助记符；-规格说明编号；-版本号；-来源。对于每个接口，宜提供：-相对此软件产品，接口软件的目的的论述；-按照消息内容和格式对接口的定义，不必要详细描述任何已文件化的接口，但要求引用定义此接口的文件。5.3.1.5通信接口本条宜定义不同的通信接口，如，局域网协议等。5.3.1.6内存约束本条宜规定对主存和辅存的任何适用特征和限制。5.3.1.7操作本条宜规定用户要求正常的和特定的操作，如：a)用户组织的不同操作模式（如，用户引发的操作）；b)交互操作的周期和无人值守操作的周期；c)数据处理支持功能；d)备份和恢复操作。注：有时此条规定作为用户界面的一部分。5.3.1.8现场适应性需求本条宜：a)对于给定的现场、任务或运行模式（如，网格数、安全限制等），为任何数据或启动顺序定义需求；b)针对软件适应特定的安装现场或任务，规定应当修改的特征。5.3.2产品功能（SRS的2.2）本条宜给出软件将执行主要功能的概要。例如，某个会计程序的SRS可在此部分关注客户帐户维护、客户财务报表及发票准备，而不涉及这些功能要求的大量细节。9 GB/T9385—××有时，本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明（如果存在）中摘录。为了清晰，应注意：a)功能应当以这样的方式组织，以使客户或第一次阅读该文件的任何读者对功能列表容易理解；b)可以使用文本或图示的方法，显示不同的功能及其之间的关系。这样的图示不必显示产品的设计，但简要显示变量之间的逻辑关系。5.3.3用户特点（SRS的2.3）本条宜给出软件产品预期用户的一般特征，包括教育程度、经验、专业技术情况。它不宜指出具体的需求，但宜给出SRS第3章中为何规定某些具体需求的原因。5.3.4约束（SRS的2.4）本条宜给出将会限制开发人员选择的任何其他事项的一般描述。这些包括：a)法规政策；b)硬件局限（如，信号时间要求）；c)与其他应用的接口；d)并行操作；e)审核功能；f)控制功能；g)高级语言需求；h)信号握手协议（如，XON-XOFF、ACK-NACK）；i)可靠性需求；j)应用的关键性；k)安全和保密安全考虑。5.3.5假设和依赖关系（SRS的2.5）本条宜列出影响SRS规定需求的每个因素。这些因素不是软件设计的限制条件，但是，它们的任何变更可能影响SRS中的需求。例如，某个假设可能是软件产品指定的硬件具有某个特定操作系统，如果事实上该操作系统不能使用，那么SRS将做相应的修改。5.3.6需求分配（SRS的2.6）本条宜识别可能推迟到系统将来版本的需求。5.4具体需求（SRS的第3章）本章宜包括足够详细的所有软件需求，使设计人员能够设计系统以满足这些需求，并且使测试人员能够测试该系统满足这些需求。贯穿本章，对于用户、运行人员、或其他外部系统，每个规定的需求应当是外部可理解的。这些需求至少应当包括，每个系统输入（激励）、每个系统输出（响应）、以及系统通过响应某个输入或支持某个输出所执行的所有功能。由于这通常是SRS篇幅最大和最主要部分，以下原则适用：a)规定的具体需求应当符合4.4描述的所有特征；b)具体需求应当引用较早的相关文件；c)所有的需求应当是唯一可标识的；d)宜注意需求的组织，使其具有最大的可读性。在考察组织需求的具体方式之前，了解5.4.1到5.4.7组成需求的各个不同项是有益的。5.4.1外部接口本条宜是软件系统所有输入和输出的详细描述。它宜是对5.2的接口描述的补充，不宜重复前面已有的信息。宜包括以下内容和格式：a)项的名称；b)目的描述；10 GB/T9385—××c)输入源和输出目的地；d)有效范围、准确度和/或容限；e)测量单位；f)定时；g)与其他输入/输出的关系；h)屏显格式/组织；i)窗口格式/组织；j)数据格式；k)命令格式；l)结束消息。5.4.2功能功能需求宜定义软件在接收和处理输入以及处理和产生输出中必须发生的基本动作。一般情况下使用“系统应……”的方式来陈述。这些包括：a)对输入有效性的核查；b)操作的准确顺序；c)异常情况响应，包括：1）溢出；2）通信设施；3）错误处理和恢复。d)参数影响；e)输入与输出的关系，包括：1）输入/输出顺序；2）从输入到输出转换的公式。尽管将功能需求划分为子功能或子过程可能是适当的，但这并不意味着软件设计同样以这样的方式划分。5.4.3性能需求本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求。静态数量化需求可能包括：a)支持的终端数量；b)支持同时运行的用户数量；c)要处理的信息量和类型。有时，静态数量需求包含在命名为‘能力’的独立部分。动态数量化需求可能包括，如，在正常和高峰工作负载条件，在某时段内处理的事务处理数、任务数和数据量。所有这些需求宜以可测量的方式规定。如：应在小于1s内处理95%的交易量。而不是：操作者不需等待事务处理结束。注：适用于某个具体功能的数量化限制，通常作为该功能处理描述部分予以规定。5.4.4数据库逻辑需求宜规定将置于数据库的任何信息的逻辑需求。这可包括：a)不同功能使用的信息类型；b)使用频度；c)访问能力；11 GB/T9385—××d)数据实体及其之间的关系；e)完整性约束；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保密安全性由于事故、恶意访问、使用、修改、破坏或泄露，本条宜规定需要保护软件的因素。这方面可能的具体需求包括：a)使用某些密码技术；b)保留某些特定数据组的历史或记录；c)分配某些功能到不同的模块；d)对于关键变量检查数据的完整性。5.4.6.4可维护性本条宜规定与软件本身维护简易性有关的软件属性。对于某些模块化、接口、复杂性等，可能有某些需求。不宜仅考虑到是良好设计实践就作为需求对待。5.4.6.5可移植性本条宜规定与软件移植到其他主机和/或操作系统简易性相关的软件属性。这可能包括：a)依赖主机代码模块的百分比；b)依赖主机代码的百分比；c)已证明可移植语言的使用；d)特定编译器或语言子集的使用；e)特定操作系统的使用。5.4.7具体需求的组织除了微小的系统之外，任何系统倾向有大量的详细的需求。由此，宜仔细考虑这些需求的组织方式，以最优化可理解性。对于所有的系统不存在单一的最优化组织方式。不同类型的系统SRS的第3章有不同的需求组织方式。5.4.7.1到5.4.7.7描述了一些组织方式。5.4.7.1系统模式12 GB/T9385—××依赖于运行模式，某些系统的行为显著不同。例如，根据其运行模式：培训、正常运行或者应急，某个控制系统可能具有不同的功能集合。当按照运行模式组织该部分时，宜采用附录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组织形式结合了用户类别和系统特征。任何附加的需求，可以在SRS的结尾处放在一个独立的部分。有许多现行可用于帮助需求文档化的符号、方法和自动化支持工具。就大部分而言，它们的有效性是组织的职能。例如，当按照运行模式组织时，限定的状态机或状态图表可能证明是有益的；当按照对象组织时，面向对象的分析可能是有益的；当按照系统特征组织时，激励–响应序列可能证明是有益的；当按照功能结构组织时，数据流图和数据词典可能证明是有益的。在A.1到A.8给出的任何提纲中，称为“功能需求I”的那些条目可以用自然语言、伪码、系统定义语言、或用标题为引言、输入、处理、输出4个子部分予以描述。5.5支持信息支持信息以使SRS更容易使用，包括：a)目次；b)索引；c)附录。5.5.1目次和索引目次和索引十分重要，宜按照一般的文档编写惯例。13 GB/T9385—××5.5.2附录附录并不总是实际的SRS的一部分或总是需要的。附录可以包括：a)输入/输出格式示例，成本分析研究，或者用户调查的结果；b)有助于读者理解SRS的支持或背景信息；c)软件所解决的问题描述；d)对代码和媒体介质的特殊包装说明，以满足安全、出口、初始装入、或其他需求。当包括附录时，SRS宜明确地规定附录是否作为需求的部分。14 GB/T9385—××附录A（资料性附录）SRS提纲模版A.1按照运行模式组织的SRS第3章模板（版本1）3.具体需求3.1外部接口需求3.1.1用户界面3.1.2硬件接口3.1.3软件接口3.1.4通信接口3.2功能需求3.2.1模式13.2.1.1功能需求1.1...3.2.1.n功能需求1.n3.2.2模式2...3.2.m模式m3.2.m.1功能需求m.1...3.2.m.n功能需求m.n3.3性能需求3.4设计约束3.5软件系统属性3.6其他需求A.2按照运行模式组织的SRS第3章模板（版本2）3.具体需求3.1.功能需求3.1.1模式13.1.1.1外部接口3.1.1.1.1用户界面3.1.1.1.2硬件接口3.1.1.1.3软件接口3.1.1.1.4通信接口3.1.1.2功能需求15 GB/T9385—××3.1.1.2.1功能需求1...3.1.1.2.n功能需求n3.1.1.3性能3.1.2模式2...3.1.m模式m3.2设计约束3.3软件系统属性3.4其他需求A.3按照用户类别组织的SRS第3章模板3.具体需求3.1外部接口需求3.1.1用户界面3.1.2硬件接口3.1.3软件接口3.1.4通信接口3.2功能需求3.2.1用户类别13.2.1.1功能需求1.1...3.2.1.n功能需求1.n3.2.2用户类别2...3.2.m用户类别m3.2.m.1功能需求m.1...3.2.m.n功能需求m.n3.3性能需求3.4设计约束3.5软件系统属性3.6其他需求16 GB/T9385—××A.4按照对象组织的SRS第3章模版3.具体需求3.1外部接口需求3.1.1用户界面3.1.2硬件接口3.1.3软件接口3.1.4通信接口3.2类/对象3.2.1类/对象13.2.1.1属性(直接的或继承的)3.2.1.1.1属性1...3.2.1.1.n属性n3.2.1.2功能(服务、方法、直接的或继承的)3.2.1.2.1功能需求1.1...3.2.1.2.m功能需求1.m3.2.1.3消息(接收的或发送的通信)3.2.2类/对象2...3.2.p类/对象p3.3性能需求3.4设计约束3.5软件系统属性3.6其他需求A.5按照系统特征组织的SRS第3章模板3.具体需求3.1外部接口需求3.1.1用户界面3.1.2硬件接口3.1.3软件接口3.1.4通信接口3.2系统特征17 GB/T9385—××3.2.1系统特征13.2.1.1特征说明/目的3.2.1.2激励/响应序列3.2.1.3相关的功能需求3.2.1.3.1功能需求1...3.2.1.3.n功能需求n3.2.2系统特征2...3.2.m系统特征m...3.3性能需求3.4设计约束3.5软件系统属性3.6其他需求A.6按照激励组织的SRS第3章模版3.具体需求3.1外部接口需求3.1.1用户界面3.1.2硬件接口3.1.3软件接口3.1.4通信接口3.2功能需求3.2.1激励13.2.1.1功能需求1.1...3.2.1.n功能需求1.n3.2.2激励2...3.2.m激励m18 GB/T9385—××3.2.m.1功能需求m.1...3.2.m.n功能需求m.n3.3性能需求3.4设计约束3.5软件系统属性3.6其他需求A.7按照功能层次组织的SRS第3章模板3.具体需求3.1外部接口需求3.1.1用户界面3.1.2硬件接口3.1.3软件接口3.1.4通信接口3.2功能需求3.2.1信息流3.2.1.1数据流图13.2.1.1.1数据实体3.2.1.1.2有关的过程3.2.1.1.3拓扑图3.2.1.2数据流图23.2.1.2.1数据实体3.2.1.2.2有关的过程3.2.1.2.3拓扑图...3.2.1.n数据流图n3.2.1.n.1数据实体3.2.1.n.2有关的过程3.2.1.n.3拓扑图3.2.2过程描述3.2.2.1过程13.2.2.1.1输入数据实体3.2.2.1.2过程算法或公式3.2.2.1.3受影响的数据实体3.2.2.2过程23.2.2.2.1输入数据实体3.2.2.2.2过程算法或公式3.2.2.2.3受影响的数据实体.19 GB/T9385—××..3.2.2.m过程m3.2.2.m.1输入数据实体3.2.2.m.2过程算法或公式3.2.2.m.3受影响的数据实体3.2.3数据构建规范3.2.3.1构建13.2.3.1.1记录类型3.2.3.1.2组成字段3.2.3.2构建23.2.3.2.1记录类型3.2.3.2.2组成字段...3.2.3.p构建p3.2.3.p.1记录类型3.2.3.p.2组成字段3.2.4数据词典3.2.4.1数据元素13.2.4.1.1名称3.2.4.1.2表示法3.2.4.1.3单位/格式3.2.4.1.4精确度/准确度3.2.4.1.5范围3.2.4.2数据元素23.2.4.2.1名称3.2.4.2.2表示法3.2.4.2.3单位/格式3.2.4.2.4精确度/准确度3.2.4.2.5范围...3.2.4.q数据元素q3.2.4.q.1名称3.2.4.q.2表示法3.2.4.q.3单位/格式3.2.4.q.4精确度/准确度3.2.4.q.5范围3.3性能需求3.4设计约束3.5软件系统属性20 GB/T9385—××3.6其他需求A.8体现多种组织形式的SRS第3章模版3.具体需求3.1外部接口需求3.1.1用户界面3.1.2硬件接口3.1.3软件接口3.1.4通信接口3.2功能需求3.2.1用户类别13.2.1.1特征1.13.2.1.1.1特征说明/目的3.2.1.1.2激励/响应序列3.2.1.1.3有关的功能需求3.2.1.2特征1.23.2.1.2.1特征说明/目的3.2.1.2.2激励/响应序列3.2.1.2.3有关的功能需求...3.2.1.m特征1.m3.2.1.m.1特征说明/目的3.2.1.m.2激励/响应序列3.2.1.m.3有关的功能需求3.2.2用户类别2...3.2.n用户类别n...3.3性能需求3.4设计约束3.5软件系统属性3.6其他需求21'