通常，您会听到这样的观点，即根据GOST 34（TK）编写职责范围不仅费力，而且非常烦人，因为您必须编写大量各种各样的废话。 但是请考虑一下：整个研究机构都参与了该GOST的开发，这是一个国家级的项目，总结了数百个自动化项目，复杂项目的经验。 他们真的可以胡说八道吗？
实际上，通过有效的方法，GOST不仅可以极大地帮助制定技术规范，而且可以在整个自动化项目的实施过程中提供帮助（不仅在国家合同中，而且在商业开发中）。 有文化的人写了它。 但是，为了利用他们的劳动成果，不仅需要略微了解传统知识的概念，而且还需要整体了解GOST 34。
在本文中，我们将逐点分析GOST的所有要求，并尝试使根据GOST 34进行的TK开发不是负担，而是对项目的巨大帮助。
1.这篇文章是关于什么的？
通常，您会听到这样的观点，即根据GOST 34（TK）编写职责范围不仅费力，而且非常烦人，因为您必须编写大量各种各样的废话。 但是请考虑一下：整个研究机构都参与了该GOST的开发，这是国家一级的项目，数百个自动化项目的经验，复杂项目的概括。 他们真的可以胡说八道吗？
实际上，通过有效的方法，GOST不仅可以极大地帮助制定技术规范，而且可以在整个自动化项目的实施过程中提供帮助（不仅在国家合同中，而且在商业开发中）。 有文化的人写了它。 但是，为了利用他们的劳动成果，不仅需要略微了解传统知识的概念，而且还需要整体了解GOST 34。
顺便说一句，TK不是自动化项目期间开发的第一个文档。 这在第1.5段中有明确说明。 GOST 34.602-89：“ NPP的TK是根据初始数据开发的，包括“ NPP创造的研究和理由”阶段的最终文档中所包含的数据。 有关更多详细信息，请参阅我的文章“
信息系统开发过程中的设计前调查” 。
注意：本文章的目的不是取代成本，也不解释其中的某些规定。
2.符合GOST 34的技术规范的特征
2.1。 ToR是按照什么标准编译的？
根据GOST 34的TK标准的全称如下：GOST 34.602-89“信息技术（IT）”。 一套自动化系统的标准。 创建自动化系统的职责范围。”
标准本身仅打印15页（是的，相当多）。 语言是俄语，真的是俄语，而不是西里尔字母上的外来语言。 就是说，如果您不主动进入GOSTs文本，联邦法律或学位论文都无法理解的话，那么很有可能会阅读和理解，尽管通常不是第一次。
实际上，该标准使用了许多晦涩难懂的术语。 例如，语言支持是什么意思？ 为了阐明所使用的概念，应转向GOST 34.003-90“信息技术（IT）”。 一套自动化系统的标准。 自动化系统。 术语和定义。”
2.2。 为什么您需要GOST作为职权范围？
可能当您需要为您撰写一些新文档时，您正在Internet上寻找此类文档的模板或向同事索取。 因此，任何文档或流程标准都是模板。 此外，该模板大大简化了文档的开发：已经为您考虑了结构和内容，此外，这种模板还考虑了您不会记得的时刻。
2.3。 职权范围在项目中扮演什么角色？
根据标准RD 50-682-89的1.7段，“职权范围是执行AU并获得客户认可的主要文档。” 这确实是主要文件。 它应该描述系统开发和实施所需的一切。
TOR建立了系统的整体外观，工作量（开发框架）以及开发和验收程序。 一切都以传统知识开始，一切都以传统知识结束。 该文档非常适合您的客户了解任务的重要性和复杂性以及他为什么要付款。
此外，由于自动化项目是由双方的团队执行的，因此为承包商和客户都编制了技术规范。 在任何IT项目中，都有大量的组织活动，没有客户的积极参与就不可能实施。 抓住每一个机会向客户解释这一点，否则他们给人的印象是他们只需要付钱就可以坐下来：受雇的人会做一切。 然后项目失败，摊牌开始。 通常，如果没有真正的团队，则不值得开始一个项目。
不要正式制定传统知识。 如果您不知道写什么，则意味着开发TK还为时过早，您对系统不了解，自动化过程本身，自动化对象尚未被理解。 您应该草拟
系统的
概念 ，我们在本文的开头就谈到了这一点。
2.4。 GOST 34.602-89年龄多大，并且有更新的标准？
不算过时。 我几乎找不到任何非核心内容。 声称GOST 34已过时的人谁也不能举一个例子（可能只是没有资格阅读它？）事实是GOST描述了自动化项目的通用方法，它没有谈论编程， GOST 34并非如此。
好吧，如果我们要谈论与其他标准的比较，那么没有什么特别可比较的。 GOST 34对自动化项目的看法如此广泛，以至于其他标准不适合大底（我认为）。 是的，它们更简单（因此更受欢迎），但是深度并不相同。 这是在为自动化项目开发自己的标准时应该熟悉的标准列表：
- IEEE 830-1998。 编制软件需求规范的方法。
- GOST R ISO / IEC 12207-2010。 信息技术。 系统和软件工程。 软件生命周期过程。
- ISO / IEC / IEEE 29148-2011。 系统和软件工程-生命周期过程-需求工程。
- GOST R 54869-2011。 项目管理。 项目管理要求。
- 井和国家标准规格34系列。
3.根据GOST 34编写技术规范的一般原则
3.1。 哪位专家应根据GOST 34制定职责范围？
通常，开发人员根据GOST 34起草传统知识时会发誓。为什么？ 是的，因为这与程序员无关。 根据GOST 34的职权范围通常无法显示给程序员。 为此有技术项目文件。 职权范围-与客户达成一致的文档，该文档经常出现在项目经理的桌子上。 TK回答了两个问题：系统应该做什么以及应该如何创建。 技术项目回答了以下问题：应如何满足ToR的要求。 例如，在TK中，您规定应该通过登录名和密码进行授权，而在TP中，则提供界面，脚本，数据库结构的布局。 为什么要划分为不同的阶段以及为什么不应该立即为程序员完成任务，请参阅我的文章，
在开发信息系统时 以医院建设和
预先设计调查 为例，了解IP（信息系统）成功设计的
秘诀 。
职责范围应由业务分析师制定，因为他是客户与开发团队之间的“翻译”。 业务分析师的任务是了解客户的需求，并以团队易于理解的方式进行表达。 并以技术规范的形式表示。 此外，业务分析师不仅需要听取客户及其雇员的意见，还必须找出他们没有说的话（通常超过50％）。 因此，分析人员必须对自动化的流程有充分的了解，并由于他的知识，可以填补调查后仍然存在的空白。
3.2。 职权范围应在哪一边？
基本上，职权范围是由承包商编制的？ 怎么了
不仅因为在GOST 34-602-89的附录1中如此推荐。 实际上，客户通常没有适当的专家。 但是TK必须由客户开发并同意。 在这里有必要确保协议不正式。 我始终坚持要求我们与客户一起详细分析每个项目。 您的目标是吸引客户参与项目。 否则，他将无法形成对该系统的期望，这意味着，首先，他将对任何结果都不满意，其次，他将无法执行必要的组织措施。
3.3。 您能从GOST 34走多远？
任何模板都有一个明显的缺点-这是一个模板。 也就是说，向左和向右迈出的步伐是社会保护的最高标准（因为死刑曾被称为死刑）。
实际上，事实并非如此。 任何过程标准（即不是针对香肠的标准，而是针对某些活动的标准）都仅给出一般说明，概述。 创建它的目的是帮助您不要忘记重要的事情，将世代相传的经验传递给您，而不是使您落伍。
不信？ 然后阅读GOST 34.602-89的第2.2节（顺便说一下，连字符后面的数字是该标准或其版本的发布年份）：“根据自动化对象的类型，目的，特定功能以及系统运行的条件，可以以应用程序的形式草绘TK的各个部分，并引入其他内容，排除或合并传统知识的小节。” 同样在1.2段。 RD 34.698-90指出：“文档的内容对于所有类型的AS都是通用的，如有必要，文档的开发者可以根据所创建AS的功能对其进行补充。 允许在文档中包括其他部分和信息，以合并和排除部分。”
通常，如果您只能引用一般性短语，那么对于一切好事，对一切坏事，都不要写。 否则，阅读过此类文章的专家将不再认真对待该文件，并且将遗漏重要的要点。 不要使阅读文件成为一种折磨！
3.4。 为什么根据GOST 34的TK描述了这么多与系统功能没有直接关系的要求？
实际上，在30页的TOR中，只有7-10页可用于功能。 这有一个解释。 事实是，GOST 34的开发人员以与我们完全不同的方式看待自动化项目。 他们看起来更正确，更全面。
首先 ，在传统知识的前半部分，不仅仅提供有关系统的一般信息和一般要求。 我们需要了解为什么要创建系统，要使其自动化的过程，需要完成哪些工作才能使系统工作，系统具有什么样的系统。 这似乎是司空见惯的事情，但是如果没有它们，团队成员将以不同的方式理解工作目标和实现目标的手段。 对我们来说，确保所有参与者都适应同一波，而不是像天鹅，癌症和长矛一样，这非常重要。
其次 ，GOST 34的编译器主要将系统视为人员，然后将其视为硬件-软件组合。 这就是GOST 34.003-90定义自动化系统的方式：“一个由人员和一套用于其活动的自动化工具组成的系统，该工具实施信息技术以执行已建立的功能。” 因此，信息系统是受过训练的人员，复杂的软件和硬件。 确实，要从会计师那里拿走计算机虽然很困难，但尽管有纸质注册表，却能够胜任。 但是1C在没有会计师的情况下将无法独立工作。 因此，传统知识的许多部分涉及组织措施。 正如他们所说，IT系统占IT的20％，其余所有都是组织措施。 也就是说，TK是说明从A到Z的系统实施所需的所有内容的文档。
第三 ，请注意GOST 34.602-89的名称：“
创建自动化系统的职责范围”。 TK不是
用于系统的，而是用于系统的创建的。 有什么区别？ 区别在于ToR不仅建立了对系统本身的要求，而且还规范了系统的创建过程，也就是说，该文档包含了所有组织措施的要求，必须执行这些措施才能取得结果。 确实，在实施自动化项目时，您经常需要重组许多流程，培训人员并准备硬件。
第四 ，ToR是您可以在其中打勾的文档：我们是否考虑了此要求。 也许您会自动将10滴答滴答作响，因为这是标准解决方案。
但是11号复选标记将显示一个非常大的问题，如果您现在跳过此问题，则在确定所有截止日期和预算之后，它将在实施过程中弹出。第五，如上所述，可以排除不必要的小节，这是允许的。例如，如果您确定自己的设计没有任何专利，那么为什么要提出专利纯度要求呢？如果没有水，没有水，则不是这种情况。3.5。为什么不同的部分说相同的话？
实际上，在传统知识中，有一些小节在很大程度上重复了其他小节的内容。例如，需要组织支持以及人员数量和资格要求。在这两段中，我们都在谈论员工。但是在第一种情况下，我们提供有关组织结构的信息：应该是哪个部门，应该如何与其他部门建立互动。同意，这完全不同于简单的人员数量和资格要求。但是对于小型系统，只需要一个或两个管理员和几个主持人。在这种情况下，我们仅需在两个完整的部分中进行描述。然后省略一些部分，在其他部分中，给出完整的需求说明。3.6。我需要高质量地发行传统知识吗？
尽管在GOST 34.602-89的第3段中给出了传统知识设计的要求，但让我们在这方面说几句话。当然是主要内容。但是，首先，它们被衣服打招呼，其次，很难以跳过字体阅读不懂文字的文本。读者会因质量低劣的设计而分心，使他们难以深入研究内容。因此，技术文档中接受了严格的技术内容和有限的术语，没有生动的表述：读者应专注于本质，而不是艺术性。这里有一些关于执行大文件（如TK）的建议。首先，必须在大型文档中使用样式，并且除了在段落内加下划线或突出显示外，请勿仅更改一个片段的字体和段落设置。如果您更改了样式。其次，我们一定不要忘记诸如自动完成目录，术语和缩写列表（必不可少的猜测一个或另一个缩写的含义）之类的强制性元素，标题页。还建议提供文档版本列表，更改列表：很容易在以后跟踪特定版本的发送日期。第四名，每个单独的要求必须在单独的编号段落中列出。如果一个片段中有2-3个要求，那么只会读取第一个，而我们的大脑会跳过其余的。 TK是一个文档，您可以在其中每个段落的前面检查是否满足要求。第五，不要忽略链接的位置。有时，您读到提到某些功能或要求的段落，却听不懂，这是来自同一文档或来自另一文档。如果从这个，那么在哪个部分。因此，如果当前文本中提到其他部分，请尝试参考它们。自然，链接应该是自动的。请注意，根据严格的规则，工作说明书是在没有框架的情况下草拟的（这在第3段中有说明），但是其余文档则是有框架的。这是在GOST 24.301-80“ ACS技术文档系统”中建立的。实施文本文件的一般要求（经修订的第1、2号）。” 该标准规定了除传统知识和在预设计阶段创建的文件以外的所有文件的执行规则。尽管我个人不喜欢任何文档中的框架。4.第1节“一般信息” / p。2.3 GOST 34.602-89 /
本节中提供的大多数信息都不需要注释，因此我们仅关注某些小节。因此，“系统所依据的文档清单”是指法律，命令或协议。同样，如果我们为子系统开发TK，则此类文档可能是另一个TK。通常，ToR中有几个部分包含文档列表，并且必须非常清楚地了解技术任务的这些部分的目的之间的区别。在“处理系统并向客户展示创建系统（其零件）的工作结果，有关单个工具（硬件，软件，信息）以及软硬件（软件和方法论）系统组合的制造和调试的过程的程序”小节中提供了有关工作接受的一般信息。例如，我们转移了文件并进行了一系列系统测试。在这里，我们仅提及转移工作结果的过程，下面在其他部分中详细介绍了此主题。5.第2节，“创建（开发）系统的目的和目标”。2.4 GOST 34.602-89 /
在这里，我们需要了解创建系统的目的和目的之间的区别。这些概念经常被混淆。例如，他们写道，系统的目的是使您的个人帐户自动化，而目标是创建一个个人帐户。石油就是石油。在某些情况下，这些概念确实是一致的，然后只写约会。目的明确了一切：我们准确地提供了自动活动的类型。例如，如果我们创建一个用于生产核算的系统，那么就值得引用自动化的核算类型，自动化的操作以及应该自动化的对象。目标是一切都不同。目标是我们正在计划的项目。您可以将其称为业务目标。我重点介绍了自动化项目的以下可能目标：- ( , ..)
- (, -, , ).
- ( , , ).
- : , .
- , . , , «», .
GOST还说，有必要提供评估目标实现情况的标准，即具体指标。例如，我们有3个人每天收集总计20个订单。在系统实施之后，我们希望每个人收集20个订单，即多三倍。如果在那里知道这些指标，我们将在本段中介绍它们。6.第3节“自动化对象的特性” / p。2.5 GOST 34.602-89 /
一个非常重要且经常经常正式描述的部分。尽管我认为这是传统知识中最重要的部分，但是如果没有它，我们将根本不了解该系统的创建内容。我们首先定义什么是“自动化对象”。如果我们使仓库或工厂，会计部门自动化，那么一切都将变得清晰。例如，如果我们创建一个新的社交网络，那么该对象就不存在。但实际上，对象更可能表示自动化过程。甚至在仓库的情况下，我们也不是使仓库本身自动化（如何使箱子的存储自动化？），而是仓库过程。如果正式执行本节，它将与系统用途的描述非常相似，并且另一个水潭将出现在TOR中，但不清楚系统应该做什么。本节应包括：- 客户描述：客户的活动，分支机构的数量，员工。当然，您需要在与正在创建的系统直接相关的那部分中表征客户。
- 有关系统用户的信息：用户类型，系统为不同用户扮演的角色。
- 自动化对象的描述。例如，如果我们使仓库自动化，则必须描述仓库的数量，多少条走道，多少条走道，什么机架，是否有单独的装配区，多少人工作以及他们负有什么责任。然后，我们将了解到，我们正在专门实现仓库过程的外观和所使用的设备的自动化。
- 自动化过程的描述。当然，没有必要在传统知识中详细描述过程。但是需要常见方案。只有这样，我们才知道应该使用哪些功能。
- 提供自动化对象详细说明的文档列表。
在某些情况下，本节的描述占了传统知识开发的一半以上，因为它需要花费很长时间并精心收集不同的信息，对其进行分析和仔细地描述。7.第4节“系统要求”
根据GOST 34的传统知识中有一个巨大的部分：第4节“系统要求”。它分为三个小节：- 整个系统的要求。
- 系统执行的功能（任务）的要求。
- 对抵押品类型的要求。
我们将分别考虑这些小节。7.1。小节4.1。“整个系统的要求” / p。2.6.1 GOST 34.602-89 /
在第4.1节“整个系统的需求”中，描述了所谓的非功能性通用需求，这些需求描述了从不同角度创建的系统。顺便说一句，正如我们已经提到的，可以添加和省略小节。因此，此处给出的编号是近似的，用于物品内的定位。7.1.1。第4.1.1条。“对系统的结构和功能的要求”。2.6.1.1 GOST 34.602-89 /
此项相当广泛，应该给出系统体系结构的一般概念。我们将更详细地分析这些要求。1.子系统列表，它们的用途和主要特征，对层次级别数的要求和系统的集中程度。在本段中，我通常引用：- ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
- .
如果您正在计划微服务架构，则列出并描述服务的功能是有意义的。为了清楚起见，期望将系统的结构图附上其部件和相关系统的名称，如以下示例所示。
...或如此：
2.对系统组件之间的通信方法和信息交换方式的要求。3.对所创建系统与相关系统之间关系的特性的要求，对其兼容性的要求，包括有关如何交换信息（自动，发送文件，通过电话等）的说明。在现代条件下，大多数交互都是使用HTTP（S）协议执行的。看来，除此之外，没有什么可写的了。但是，这些项目可能太大，以致于无法提交给应用程序。他们应提供以下信息：- 传输信息的列表，至少是一般说明，以大致了解我们为什么要与特定系统集成；
- 协议描述（或描述链接），尤其是在设备连接的情况下；
- 本地网络结构；
- 所需的数据速率；
- 使用移动互联网或WiFi；
- 非自动化数据传输方法的说明。
4.对系统操作模式的要求。操作模式可以有几种分类：- : , , (, , , API, );
- : , , , ;
- : 24/7 ( );
- : ;
- : , , ( );
- : -, , (, , );
- : ( ), , (, , , );
- : , « »;
- 应用可见性：对话框或背景
- 对系统可能产生的影响：常规，培训，测试模式。
5.诊断系统的要求。对于基于微服务（间隔）体系结构的系统（包括设备：传感器，控制系统，终端等），应制定连续或定期诊断的要求。当然，如果仅开发在单个服务器上运行的软件，则这些要求是多余的：您将发现是否有东西停止工作。6.系统发展，现代化的前景。似乎“系统的结构和功能要求”小节中系统的开发前景如何？但是想像一下，现在您要为100个人创建一个Alpha版本，并且您希望在一年内在世界不同地区获得超过一百万同时工作的用户。然后，在创建阶段，您立即需要提供集群体系结构。或者现在您正在一个组织中工作，六个月之内将会有几个组织，这意味着您必须预见到扩展的可能性。换句话说，在本节中，您可以写下所有现代化的前景，但要特别注意那些肯定会影响体系结构的前景。7.1.2。第4.1.2条。“人员数量和资格要求” / p。2.6.1.2 GOST 34.602-89 /
正如我们前面提到的，任何自动化系统都包含“人员和用于其活动的一组自动化工具”。因此，在TOR中指示了人员要求及其资格。如果您使特定的生产线自动化，则您知道人员数量。但是在很多情况下，这取决于执行的工作量。因此，请指明职位，工作时间表，活动说明（用于分配访问权限）和大致资格。至少，您需要系统管理员和操作员，通常需要主持人。您可能需要为几种类型的操作员提供不同的访问级别。显然，人员需求通常是由客户设定的，为什么要带给他们呢？但是，首先，我们已经说过双方都制定了技术规范，其次，承包商将受到保护：不满足员工选拔条件，如果不实施该系统，客户又要什么呢？7.1.3。第4.1.3条。“绩效指标要求” / p。2.6.1.3 GOST 34.602-89 /
在本小节中，通常会写您喜欢的内容，因为GOST文本中缺少可能的指标列表，并且几乎不可能在开源中找到它们。请注意，GOST中给出的“适应度”，“现代化极限”和“概率-时间特性”首先用于ACS（自动控制系统），其次，它们很难测量。因此，这些特性并不总是合适的。然而，在案文本身中，“任用指标”被定义为“表征系统对目标的遵守程度的参数”。在现代计算机系统中，表征该系统的定量值主要与性能和数据存储量有关。目的地指标包括：- 同时在系统中工作的用户数；
- 到服务器的同时执行的请求数；
- 每单位交易时间（记录的）交易数；
- 不同数量的一次性请求和工作用户，不同数量的处理数据的响应时间（尤其是在搜索和汇总报告时）；
- 存储的数据量（尤其是图像和视频）；
- 达到最大负载时用于额外计算能力的连接时间；
- 附加容量的连接时间，大大增加了存储数据量。
所有这些特征都会影响服务器硬件，应用程序服务器和DBMS体系结构，关系或非关系DBMS，微服务等的选择。7.1.4。第4.1.4条。“可靠性要求” / p。2.6.1.4 GOST 34.602-89 /
GOST的文字详细描述了可靠性要求中需要指出的内容。但是，要了解确保该标准固有的可靠性的方法，您应该学习27系列的GOST。首先，您应该熟悉术语：这将足以理解可靠性的概念，如何测量以及如何提供可靠性。因此，请参考GOST 27.002-89。 “技术的可靠性。基本概念。术语和定义。”可以应用于自动化系统的基本概念是可用性系数：99％，99.9％，99.99％。每个“妮妮”的数量都是通过某些措施提供的。这些要求会影响哪些技术解决方案？这是备用容量的数量（各不相同），以及地面技术人员的可用性，不仅使用不间断电源，还使用柴油发电机，以及使用两个独立的电源进行连接（根据可靠性类别I或II连接至电网）。7.1.5。第4.1.5条。“安全要求” / p。2.6.1.5 GOST 34.602-89 /
本小节介绍了搬运设备的安全要求（安装，调试和操作）。现在，这些要求称为劳动保护，并包含在第12系列的GOST（SSBT-劳动安全标准体系）中。如果有人要认真从事安全工作，那么在TK中只要列出这些部分就足够了。7.1.6。第4.1.6条。“对人体工程学和技术美学的要求” / p。2.6.1.6 GOST 34.602-89 /
我们给出了GOST的要求：“对人体工程学和技术美学的要求包括AC指示器，这些指示器指定了与机器进行人机交互的必要质量以及工作人员的舒适度。”
通常在本段中写道，系统应具有方便美观的界面。 但是如何衡量方便性和美观性呢？ 因此，我们要么忽略此要求，要么说该接口将对应于以后开发的设计项目，要么我们提供标准，例如，开发移动应用程序的所谓“指南”：Android的
Material Design和iOS的
Human Interface Guidelines 。
在实现对我们特别重要的某些功能时，您还可以给出最大的转换次数（点击次数），平均数据搜索速度等。
7.1.7。 第4.1.7条。 “移动扬声器的便携性要求” / p。 2.6.1.7 GOST 34.602-89 /
说一些过时的要求。 现在，卡车上的服务器（例如以前的大型计算机）不再携带。 但是，假设您具有某种超级保护功能，在DMZ后面有内部电路，并且……需要通过笔记本电脑进行远程工作。 是的，可以随时配置VPN，但最好将其反映在《管理指南》中，并且由网络配置自行提供可能性。
7.1.8。 第4.1.8条。 “操作，维护，修理和存储的要求”。 2.6.1.8 GOST 34.602-89 /
这些要求涉及维护复杂的技术手段（服务器，防火墙，交换机，工作站等）。如果设备需要任何特殊维护，则必须在本节中对此进行描述。 例如，您有一个特殊的设备，每月需要校准一次。
7.1.9。 第4.1.9条。 “保护信息免遭未授权访问的要求” / p。 2.6.1.9 GOST 34.602-89 /
保护信息免遭未经授权的访问的话题非常广泛，同时还采取了各种措施来确保信息的安全。 当然，如果我们正在谈论访问网站的个人帐户和该网站的管理面板，那么对授权，密码复杂性，角色访问模型有足够的要求。 但是，如果为国家需求创建了金融系统或系统，则会出现特殊要求。
重要的是要注意，在本小节中，不仅给出了在系统开发过程中需要采取的措施，而且还给出了其操作。
因此，对于金融系统，您应该使用“支付卡行业数据安全标准”（PCI DSS）。 对于存储个人数据的系统，-俄罗斯联邦政府于2012年1月11日第1119号法令“关于批准在个人数据信息系统中处理个人数据的保护要求”。 您的主题领域可能还有其他标准。
通常，防护设备可以分为以下几种类型：
- 所创建的软件产品提供的手段。
- 系统管理员提供的措施。
- 实物保护措施。
- 一般组织措施。
- 在软件开发过程中采取的措施。
1.所创建的软件产品提供的安全措施：- 用户（特别是具有管理员角色的用户）的密码要求。
- 实施基于角色的访问模型。
- 使用电子签名密钥执行关键操作的要求。
- 删除负责与DMZ的外部系统进行交互的软件组件。
- 提供事件和用户操作的注册。
2.系统管理员提供的措施：- 使用防火墙（防火墙）。
- 记录和监视所使用的服务和协议。
- 非军事区（DMZ）配置。
- 监视使用笔记本电脑的规则的执行情况：使用防火墙连接到内部网络。
- 将设备和系统连接到网络之前，请禁用默认帐户。
- 配置无线访问设备：设置密码并更改默认访问设置。
- 安装可解决已识别的硬件和软件漏洞的更新。
- 为远程访问系统提供安全性（例如，使用VPN）。
- 安装，更新和监视防病毒软件。
- 进行定期的网络扫描，并在进行重要更改后进行扫描。
- 为每位员工分配一个唯一的帐户，定期检查是否有解雇的员工删除帐户，更改密码。 电子签名令牌的发行和记帐。
- 配置数据库访问限制。
- 所有服务器和工作站上的时间同步控制（以确保事件日志中记录的时间正确）。
- 配置事件日志。
- 定期清点无线访问点和其他设备安装的软件。
3.实物保护措施：- 限制进入关键房间。
- 在公共场所断开网络连接器。
- 在关键场所安装闭路电视摄像机。
4.一般组织措施：- 通过安全策略并定期对人员进行信息安全规则培训。
- 实施安全事件响应程序。
- 屏幕验证或机密数据报告。
- 向所有访客发放徽章，在关键区域陪同访客。
- 全面审查雇用的员工。
- 为组织提供安全性-与软件和硬件有关的服务提供者。
5.在软件开发过程中采取的措施：- 负责人控制，以更改程序代码，检查代码是否符合信息安全规则（缓冲区溢出控制，正确的错误处理，检查crossite脚本，访问机制错误等）
- 使用强密码学。
- 公共Web应用程序的安全规则的应用。
- 为每次更改制定取消程序。
- 变更文档。
7.1.10。 第4.1.10条。 “发生事故时对信息安全的要求” / p。 2.6.1.10 GOST 34.602-89 /
本节提供了可能的事故和故障清单，应在其中确保信息安全。 此类事件可能包括：
7.1.11。 第4.1.11条。 “保护免受外部影响的要求” / p。 2.6.1.11 GOST 34.602-89 /
对于冷藏仓库中的服务器，工作站和其他设备，或者相反，在高温，多尘场所或高湿度场所中的服务器，工作站和其他设备，本节将非常有用。 有时还值得考虑振动，辐射或其他影响。
7.1.12。 第4.1.12小节。 “专利纯度要求” / p。 2.6.1.12 GOST 34.602-89 /
如果您怀疑您将使用在其他国家（或在我们国家）获得专利的任何技术，并且专利持有人可能对系统所有者提起诉讼，则本段列出了您要检查的国家/地区列表专利纯度。
7.1.13。 第4.1.13条。 “标准化和统一的要求”。 2.6.1.13 GOST 34.602-89 /
该条款也很少包含在专门针对软件的职责范围中。 它指出了使用特定技术的要求以及文档和分类器的标准化形式。
如果您对所使用的框架，插件，协议，设备，数学算法，第三方软件等有特定要求，则此描述特别重要。只是请不要忘记指出应将这些工具用于哪个部分以及目的。
同样有时在某些类别的系统中，习惯上使用某些数据交换协议。 例如，OCG标准用于在地理信息系统之间交换数据，而OCPP用于控制电动汽车的充电站。
7.1.14。 第4.1.14条。 “其他要求” / p。 2.6.1.14 GOST 34.602-89 /
该段落应在GOST的文本中找到。 他不需要评论。
7.2。 第4.2小节。 “对系统执行的功能（任务）的要求”。 2.6.2 GOST 34.602-89 /
本部分是现代计算机系统的核心。 实际上，系统是为执行某些功能而创建的。 通常，TK是根据国外标准创建的，通常没有标准，仅包含此部分。
7.2.1。 功能描述结构
首先，我们考虑系统功能需求的结构：子系统-功能集-功能-任务。 任务是功能的一部分，可以将任务描述为单独的功能。 例如，对于登录功能，我们引入了密码作为任务之一。 我们可以将密码输入过程描述为一个单独的功能：正确性验证，密码恢复，提示显示等。 复杂是功能统一的基础。 例如，“会计基本信息”，“举行拍卖”等。 复合体具有两个或多个功能。
如果您的系统由几个子系统组成，那么从根本上讲，TK应该列出子系统的功能，并且已经在子系统的单个TK中详细描述了子系统的功能要求（现在通常称为CTZ-一项私人技术任务）。
7.2.2。 功能类型的实现方式
实际上，所有功能（或其任务；一个功能可以同时存在多个任务）可以分为以下类型：
- 输入信息。 有时称为“会计信息”。
- 信息输出。
- 自动处理信息。
7.2.3。 按职能类别划分的职能类型
功能可以是一般的和特殊的。 例如，常用功能包括使用对象列表，使用对象卡以及使用交互式地图。 这些功能可能适用于所有特殊功能或部分特殊功能。
7.2.4。 要求而非脚本
不要忘记ToR包含了系统及其创建过程的要求。 不是脚本。 TK回答了系统应该做什么的问题。 对技术设计如何回答的问题。 如果您开始详细描述技术实现，那么请深入细节，而不能给出完整的要求列表：我们的大脑无法同时以广泛覆盖和考虑细节的方式工作。
TOR和技术项目的功能结构可能有很大差异：在一种情况下，可以实现多个功能，反之亦然。
7.2.5。 功能要求
以下是有关如何编写功能说明的一些建议：
- 通常应对应用程序提出功能和任务的要求。 因此，该文档有机地分为非功能性部分和功能性部分。 此外，该应用程序始终可以单独打印和查看。
- 避免大段。 最好将需求分为段落和子段落：更容易理解并控制其执行（选中复选框）。 如果提供了要求或信息的列表，请通过编号或标记的列表给出。
- 对于用途不明确的功能，有必要指出用途和要解决的问题。 否则，即使是TK编译器也可能会忘记他为什么描述这种功能。
7.2.6。 功能说明示例
5.6。 在系统中注册车辆
提出以下要求：
1）系统应考虑以下一般信息：
- 国家注册商标（GRNZ）；
- 所有者名称；
- 所有者地址；
- 来自车辆数据采集服务的数据（请参阅附录B第3.3节）；
- 注意。
2）系统应允许考虑以下与车费支付有关的信息（指定信息本质上是信息性的，不需要直接在车辆登记卡中进行更改）：
- 当前的车辆等级（见附录A第3.3节）；
- 当前关税（见附录A第5.1节）；
- 现行合同（见附录A第5.5节）；
- 根据哈萨克斯坦共和国内政部的信息，对车辆进行分类；
- 有关个人帐户及其条件的信息（请参阅附录A第3.6节）；
- 有关降低票价的车辆登记处的信息（请参阅附录A第3.5节）。
3）系统应允许通过以下方式注册和更改有关车辆的信息：
- 由操作员手动进行；
- 在收到来自RFID标签注册系统的信息后（请参阅附录B第1.1节）；
- 使用摄像机GRNZ识别车辆时。
4）在系统中注册新车辆时，系统必须向服务部门请求有关车辆的数据，以接收有关车辆的数据（请参阅附录B第3.3段）。 应该可以更新单个车辆的指定信息。
7.3。 第4.3小节。 “安全类型要求” / p。 2.6.3 GOST 34.602-89 /
根据GOST，通常会引用对支持类型的要求部分作为传统知识过剩的例子。 当谈到是否应该给出所有部分和小节时，他们会回忆起该软件，在大多数情况下，无需编写任何软件。
实际上，这是一个非常重要的小节，尽管并非每个人都了解其目的。 它描述了无法进行开发或调试的条件。 这些条件称为“抵押”。
在阅读本小节时，有人想知道该标准的起草者是指“软件”，“语言软件”，“信息软件”等。 应在GOST 34.003-90中寻求答案，所有这些术语都应在此处解密。
7.3.1。 第4.3.1节“软件” / p。 2.6.3.1 GOST 34.602-89 /
想象一下您需要创建一个系统来实现自动计算最佳路线的情况。 “计算路线”按钮可能看起来很简单，但背后可能有非常复杂的数学算法和计算。 显然，进行这种算法的开发是不值得的；专业的数学家正在从事这一工作。 如果有这样的算法可用，那么还将写出它们开发或使用现成算法的要求。
7.3.2。 第4.3.2节“信息支持” / p。 2.6.3.2 GOST 34.602-89 /
在阅读GOST文本中有关此要求的描述时，似乎这是其他部分所讲内容的重复。 例如，为什么再次描述“在系统中组织数据的组成，结构和方法”和“在系统组件之间进行信息交换”的要求？ 但是我们再次忘记了，该系统下的GOST编译器不仅具有软件，而且具有整套组织措施。
在向您介绍时，您会遇到这样的情况，即客户本身没有提供将任何数据输入系统的操作员，同时该操作员指出系统无法正常工作。 熟悉的情况？ 但是，如果在工作说明中阐明了提供此输入的要求，那么此时可以直接戳客户。 或者，您需要访问特定的地址分类器才能工作，但客户不会将其提供给您。
因此，在本段中，有必要指定对传入信息的要求以及以非自动化方式从系统组件到另一组件传输的信息的要求。 其他部分将全面介绍自动信息处理，DBMS的使用，系统内的信息交换。
7.3.3。 第4.3.3节“语言支持” / p。 2.6.3.3 GOST 34.602-89 /
本段规定：
- 使用编程语言的要求（如果有特定偏好）；
- 界面语言（哪种语言，多语言界面）；
- 项目团队之间交流的语言，翻译要求；
- 数据输入和输出的其他功能（如果有）：加密，用户与系统交互的非标准方法。
7.3.4。 第4.3.4节“软件” / p。 2.6.3.4 GOST 34.602-89 /
如果已在ToR的开发阶段确定了已购买的软件，则本段列出了已购买的软件。
7.3.5。 第4.3.5节“技术支持” / p。 2.6.3.5 GOST 34.602-89 /
没有硬件，服务器，网络等，任何信息系统都无法工作。 通常建议确定设备的特定特性以包括在技术设计中，但是可以在工作说明中给出大概的组成，以便客户对未来的成本有所了解。
7.3.6。 第4.3.6节“计量支持” / p。 2.6.3.6 GOST 34.602-89 /
如果计划从系统中的传感器接收数据，则必须了解将使用哪种测量仪器，应提供的精度测量仪器，这些工具是否应经过认证和认证。7.3.7。第4.3.7节“组织支持” / p。2.6.3.7 GOST 34.602-89 /
想象一下，您正在从头开始创建系统。例如，这是一个用于新物流中心的仓库管理系统。换句话说，只有墙壁。或者您正在升级系统，并且要实施更改，您需要修改组织结构。在这种情况下，您应指定与您所提供的系统将在其上正常工作的过程的组织有关的条件。7.3.8。第4.3.8节“方法论支持” / p。2.6.3.8 GOST 34.602-89 /
有时，要管理系统，需要具有任何特殊能力的人员。在这种情况下，应该在TOR中给出方法，规范和标准的列表，以便与员工进行系统交互。7.3.9。其他类型的抵押品
在开发每个新TK时，应考虑成功调试所需的条件。例如，当所使用的法律框架未完全定义且其发展可能影响实施时，我经常写下法律支持的要求。尽管在起草职责范围之前最好解决此类问题。8.第5节“关于系统创建（开发）的工作的组成和内容”。2.7 GOST 34.602-89 /
这部分是组织性的，通常会放在合同中。但是，可以在ToR中指定此信息。本质上，这是开发和实施的短期计划。进行编译时，通常会提供一个表格，其中列出以下所有或某些列：- 阶段（子阶段）的名称。
- 工作内容（简短说明，任务列表）。
- 工作结果（批准的文件，已制定和提交的解决方案）。
- 设计，工作或报告文档。
- 负责人（执行这项工作的人：客户，承包商或其他人）。如果双方都必须给出共同的结果，则说明角色。
- 持续时间（日期，日期，时间开始）。
下表提供了本节内容的示例。9.第6节“系统的监视和验收程序” / p。2.8 GOST 34.602-89 /
本节详细介绍了客户接受系统的过程：应执行哪些测试，将在这些测试中包括哪些内容，根据将要测试的文档，将如何提出和消除注释。9.1。6.1小节。“系统及其组件的类型，组成，体积和测试方法” / p。2.8.1 GOST 34.602-89 /
通常，我在这里指出测试列表，并提到测试方法将在文档“测试程序和方法”中给出，该文档描述了主要测试用例，测试脚本。让我们详细介绍一下测试的类型。测试类型，组成，文件要求由GOST 34.603-92“信息技术”确定。自动化系统的测试类型。” 因此，在开发本节和技术项目时，请务必参考本标准，在此我们仅说明要点。让我们尝试了解什么类型的测试：1.测试分为以下几种类型：2.初步（和部分接受）测试又分为：为什么将测试分为不同阶段？首先，由于GOST 34.603-92不能区分内部接受和外部接受，因此部分测试可以在没有客户的情况下进行。其次，部分地描述了顺序测试过程，然后将所有内容集成在一起。让我们尝试用简单的词来描述测试过程：1.系统各部分的初步自治测试。如果组成中包含多个子系统或大型模块，则分别测试系统的各个部分。通常，此类测试是自动进行的，即无需与相邻系统集成。如果系统很简单，则可以安全地跳过此步骤。2.整个系统的初步自治测试。整个系统在自治模式下以复杂的方式进行测试，也就是说，无需与相邻系统集成。与相邻系统关联的功能未经测试。在极端情况下，将放置“存根”（集成仿真），或者数据库必须预先填充必须来自外部来源的数据。3.初步综合测试。该系统以集成方式（即与相邻系统交互）进行测试。以这种形式，系统被转移给客户进行试运行。4.试运行。MA可以以不同的方式进行。最好的事情是利用真实数据，真实用户和真实任务来进行开发。只有这种类型的测试才能确保系统确实可运行。在试运行期间，消除了这些缺点。5.验收测试。这是最后一种检查。告诉我，为什么消除所有缺点后的试运行将无法顺利进入工业领域？所以通常会发生。但是高级叔叔需要看到该系统确实有效，才能“感觉”到它。验收测试是专为他们而设的，以提高佣金。因此，验收测试与初步测试的不同之处主要在于佣金的状态。本段中还指出了将提供测试方法的文档：- « () ». . — 34.603-92 (. 2.2.2 4.1) — 50-34.698-90 « . . . . ».
- « », . 3.1 34.003-90. « » (. . 3.2 34.603-92), .
9.2。6.2小节。“分阶段接受工作的一般要求” / p。2.8.2 GOST 34.602-89 /
在本节中，我通常指出：- 测试将在谁的地区和设备上进行：客户或承包商。
- 有关如何进行测试的一般说明（例如，将检查文档，确定用户界面元素和脚本的存在）。
- 参加者名单。
- 列出测试结果的文档列表：
- 对于初步测试和验收测试，这是一份测试报告，其中提供了检查及其结果的列表。
- 对于试运行-试运行日志。
10.第7节“对准备使系统投入运行的自动化对象的工作组成和内容的要求”。2.9 GOST 34.602-89 /
本节中描述的过程通常称为实现。请注意，这些作品也在第5节“有关系统创建（开发）的作品的组成和内容”中给出。但是，在第5节中仅简要提及它们，并在此处给出详细说明。准备对象时，通常应执行以下工作：- 重组，必要时招募新员工。
- 员工培训。
- 对于Web应用程序：开发站点的公共部分和用户协议（同意处理个人数据）。
- 填充目录和其他背景信息。
- 从旧系统传输数据。
- 在工业服务器上部署系统。
- 配置与相邻系统的集成。
- 设置访问系统并创建帐户。
其中一些要点应进行详细描述，尤其是在数据传输和填写目录方面。11.第8节“文件要求” / p。2.10 GOST 34.602-89 /
不值得正式提及这些文件。文件-这是专案管理，专案工作流程。您不会一味掌握一切，项目的成功取决于文档的可用性和质量。当然，有一些文件“很重要”，应该对它们进行相应的处理，但是如果没有文件的平静有序地进行，则该项目无法实施。符合GOST 34的自动化项目文档受以下标准规范：- GOST 34.201-89创建自动化系统时，文档的类型，完整性和名称。
- RD 50-34.698-90指南。信息技术。一套自动化系统的标准和准则。自动化系统。文件内容要求。
- 对于职权范围-GOST 34.602-89，我们现在正在讨论。
第一个标准（GOST 34.201-89）提供了文档列表和结构。在第二个文件RD 50-34.698-90中，指示了以下文件的内容：- 初步设计和技术项目的文件。
- 在预设计阶段开发的文档。
- 组织和行政文件（法案，协议等）
11.1文档结构的特征
在编制必要文件清单时，他们通常会查看RD 50-34.698-90并选择所需的文件。同时，由于文档结构相当复杂，因此会犯很多错误，这在GOST 34.201-89中进行了描述。让我们尝试确定一些规则，这些规则将有助于编译文档列表。1.每个阶段都有自己的一套文档。每个阶段都有自己的一套文档。了解这一点非常重要。不必在设计阶段就制定操作文档，反之亦然。事实证明，这是纯粹的正式论文，您将花费大量时间。如果直到系统开发结束时，“用户指南”通常都没有人组成（尽管我已经见过这样的数字），那么在开发完成之后，会不断地制定“自动功能描述”，其中通常会为程序员提供脚本。另外，在阅读RD 50-34.698-90时，可能会感觉到某些文档的内容重叠：这也是由于这些文档打算用于不同的阶段。由于某些文件可以在一个阶段或另一个阶段进行开发，因此为避免重复，GOST 34.201-89分别提供了可以在技术设计和工作文件阶段发布的文件清单，以及单独提供了用于以下目的的文件清单：每个阶段分别进行。因此，在为其中一个阶段编译文档列表时，必须在标准的多个部分中浏览文档列表。为了避免混淆，我编译了一个Excel电子表格，在其中可以使用过滤器立即显示特定阶段的文档的完整列表。2.文档分为主题（项目的一部分）。GOST 34包含描述系统范围解决方案以及组织，技术，数学，软件，信息支持（我们在上面讨论了支持的类型）的文档。在RD 50-34.698-90中，这些文件是按部分项目（主题）精确分类的。您应该始终注意这一点，以确定文档的目的。3.文件可以合并。GOST 34.201-89直接指示在哪种情况下一个文档包含在另一个文档中。这样做是为了避免只剩下一页或两页的退化文档。如果需要描述某些内容，但是体积很小，则最好将文本包含在另一个文档中。在大多数情况下，有一个文档，例如“技术设计说明”，您可以在其中添加部分。4.运营和设计估算分别突出显示。GOST 34.201-89的编译器在表格的不同列中，列出了属于运营和设计估算的文件清单。设计估算包括管理施工和电气工程的文件：估算，采购计划，图纸和电气图。操作文档包括指导系统使用和维护的文档：手册和说明，材料和数据列表，包含有关操作期间违规信息的文档。11.2设计文件清单的功能
如您前面所述，在第5节“创建（开发）系统的组成和内容”中描述工作阶段时，还提供了文档列表。提供文档双重清单的原因很简单：仅指出文档名称是不够的，仍然有必要说明其目的并提供简短的摘要（当然，对于“用户指南”，指出内容是没有意义的）。否则，它将无法确定特定文档在项目管理中的重要性。GOST是来宾，在每个项目中文档的内容和角色可能有所不同。此外，列表中可能包含不受GOST 34规范的文档，需要对其进行明确说明。在文档规则中，我通常提供一个包含以下各列的表：- 舞台。
- 文件名称。
- 注意：表示文档的开发标准，目的，摘要和主要功能。
11.3文档清单示例
对于要实施复杂系统的大型项目，可能需要大量的文档。我们在下表中给出了此类列表的示例。12.第9节“发展之源”。2.11 GOST 34.602-89 /
它似乎是正式的部分，但非常有用。 想象一下一种情况，当您记得在开发TK时您读过一篇文章，并且由于某种原因需要找到它，例如，澄清某些内容或为您的决定辩护。 但是您绝对不记得它的名称或它所在的位置。 因此，当我使用任何有用的材料时，请务必将它们列入清单。 在文本中，我在脚注中注明了出处。
如果来源很多，则应将其分为几个小节，例如：
- 描述已开发系统的类似物（原型）的材料。
- 描述系统总体思想的材料。 通常，这些文档是在预设计阶段编译的，通常在“自动化对象的特性”部分中进行引用。
- 项目开发材料：34系列的二手GOST清单，二手的项目管理标准。
- 与主要流程的执行相关的材料：法律，标准，内部法规和命令的列表，这些清单建立了自动化流程的执行规则。
- 包含通用和信息安全要求的材料和标准。
结论
当然，按照GOST 34编写职责范围并不容易。 不是因为GOST不好，而是因为GOST会让您在整个项目中思考，画出所有小东西。 但是编写良好的TOR只是项目成功的一半。
如果您认为有必要澄清或补充某些内容，请在评论中写上。 确保对文章进行更改。阅读作者的其他文章：