最近，我的一个朋友抱怨英语professional语在某些专业社区中占主导地位。 我回答他这很糟糕，但是被迫。 就像这样，自然的借贷过程就发生了，必要的东西经过调整而不必要的东西被清除了。 而且英语本身的拉丁语要比俄罗斯英语多得多。 毕竟，曾经从事科学的人们只用拉丁语交流。
在俄语中，仍然存在一个很小的区域，需要将其带入现代现实。 这适用于在人员和团队管理方面的西方实践。 他们对苏联科学的研究很差，而在90年代，他们的加速引进是由最近认为他们在意识形态上不正确的人开始的。 经济和特定领域也是如此，例如与软件生产相关的领域。
我们一直都知道如何编写出色的程序代码。 但是，软件业务比简单的受雇编程要广泛得多-它是知识交易。 如果是这样，则需要生产及其组织。 在这里，需求收集管理系统起着关键作用，在该系统中，生产过程必须基于西方的经验来建立。
在本文的进一步部分，将使用来自Karl I. Wigers的著作“ Software Requirements Development”的翻译示例来分析典型的借用错误。 最后，使用软件设计需求生命周期的V模型总结了所讨论的材料。
毫无疑问，卡尔·维格斯（Karl I. Wigers）的一本有趣的书“软件需求的开发”（以下简称RTkPO）正在成为俄罗斯信息界的某种标准。 但是在作者概念之外使用本书中的条款（借来的，原始的，翻译的）会引起我想理解的问题。
这说明了随着项目从上到下的过程中需求的发展，它通过三个文档进行了说明：“
关于项目的图像和边界的 文档 ”，“
用例文档 ”，“
软件需求规范 ”。 在第3版中，前两个文档分别表示为“
概念和边界 文档 ”和“
用户需求文档 ”
要创建正确的文档，您必须首先了解其本质。 看来关键是要揭开神秘的“
项目的图像和边界 ”：解决它，您可以不受限制地使用现成的实践，并从中受益匪浅。 不幸的是，这仅适用于从第三方购买的简单技术。
团队管理的各个方面与外国文化的特征直接相关，那里的一切都不容易。 文化差异是整个
潜意识种族刻板印象体系中冰山的可见部分。 但是我们根本不控制潜意识的境界，或者我们只是部分地控制了潜意识。
但是，并非所有事情都如此绝望。 我们需要找到他们的术语与我们的实践的联系。 我们将分析“
关于项目图像和边界的文档 ”。 项目的边界是
项目范围 。 这应该翻译为“
工作量 ”。 不在字典中吗？ las 您可以看一下英语手册：
项目范围-项目计划的一部分，包括确定然后记录项目特定目标，结果，任务，成本和期限的过程 。 有一个特定的程序，为什么不将其称为“
项目边界 ”？ 在这种情况下，我们过去的经验整合会产生问题：毕竟，我们一直在计划，尤其是确定以前的工作范围。
当词典翻译失败时，您需要寻找一个简单的概念模型，该模型说明有争议的术语在相关主题领域中的使用。 将这种简单的披露模型进一步转移到本地土壤，使我们能够找到语言匹配。 三重约束模型是项目管理的介绍。
该模型揭示了术语“
执行时间 ”，“
成本 ”，“
工作量 ”（时间，成本，范围）之间的关系，这些术语以等边三角形的形式放置，这意味着更改此三角形的一侧会导致全部更改。
Project Vision有时不是翻译为“
项目图像 ”，而是翻译为“
项目概念 ”，但这并没有增加清晰度。 手册中的
“项目愿景声明 ”被定义为“
对成功完成项目后可获得的预期业务成果的
理想看法 ”。 我们通常使用“
项目目标 ”一词，并伴随着国内的悲观情绪来制定这些任务。 如果我们称其为“
项目形象 ”，那么这不太可能有助于在其自身的土地上表现出西方的乐观态度。 总的来说，第一个文件可以称为“
项目目标和工作范围 ”。 没有什么神秘的。
人们认为，这些术语不应翻译，而应在项目中使用英语。 这仅在某种程度上起作用，从而极大地限制了事务专家的圈子。 在与种族文化差异有关的技术问题上，基本的语言技能还不够。
这是RTkPO的一个典型示例：“
要求应按顺序说明，例如，“系统将是...”或“用户将是...”，然后是活动动词，然后是观察到的结果……您可以使用“应该”作为“将”的同义词，但是避免使用“应该”，“也许”，“可能”和类似的词语，因为不清楚这些词语是否需要采取行动 。”
您可能会认为这是现成的行动指南。 实际上，这种翻译无助于弄清它的含义，但会使一切更加混乱。 而且，英语原文不是最终的真理，而是对英语形式的某种看法的表达。 该视图包含在RFC2119 **标准中，该标准阐明了在需求管理领域使用英语关键字的规则（
例如，必须，应当，应该，可以 ）。 例如，在该标准中，
必须表示“
定义是规范的绝对要求 ”。 但是，作者遇到了直接禁止使用
must的文档模板（有关此位置的说明，可从Internet ***获得）。
需求的下一个详细级别是“
用例文档 ”。 在RTkPO上，表明它定义了用例，方案和
事件响应表。 将“
用例 ”翻译为“
用例 ”不必要地简化了对事物的看法（因此，在实践中，用例的英国主义已变得更加牢固）。 现代软件应具有防止黑客入侵和免受傻瓜保护的功能，但应将其视为一种使用方式-暴力使用俄语。 对于翻译，提出了“交互方案”。
实际上，
事件响应模型
是我们已知的。 在高中，它被称为“
影响- 波动 ->反应” 。 在相同的影响下，系统的响应可能会由于随机波动而发生变化。 在用户软件中，这些通常是各种错误情况。 此外，在概念层面上，应将环境影响与用户影响区分开。 尽管尚未建立术语，并且遇到了非常不同的选项（例如，在最新版本中，名称“
User Requirements Document ”会自动使用），但此级别的要求或多或少都适合使用“
系统要求 ”或已经是“
软件产品要求 ”的名称。不包括嵌入式系统）。
开发此级别要求的本质是创建在理想的外部世界中运行的详细的软件推测模型。 因此，重要的是设置限制并进行假设。 “
只要是黑色，汽车的
颜色就可以是任何颜色， ”-因此，亨利·福特将汽车颜色的业务需求重新设计为一种假设。 然而，又一次，为了满足汽车清洁的业务要求，事实证明有必要制造非平面流线型玻璃。 福特工程师表示，这在技术上是不可能的。 福特在旁边找到了年轻的发明家。
较低的级别由“
软件需求规范 ”表示，其中包括“
限制 ”，“
外部接口 ”，“
质量属性 ”和实际上是“
功能需求 ”。 这是该图中的最后一个文档，很遗憾，后续测试的问题没有得到解决。 因此，为了制定该定义，RTkPO被迫使用业务需求的概念：“
功能需求确定了开发人员必须构建的软件功能，以便用户可以在业务需求框架内完成其任务 ”
在测试方面，定义更易于构建：“
功能需求是正在测试的需求 。” 这应该理解为通过经典意义上的测试（通过-判定为通过或失败）来测试每个功能需求的能力。 严格来说，相反的说法是不正确的：某些测试可能会自己存在。 但是这种测试的存在表明在需求工作中存在遗漏。 毕竟，测试会检查代码的任何部分，这些部分不是独立出现的，而是由于执行某些功能需求而出现的。
现代成熟的软件开发过程正在尝试将测量组件带入软件产品制造的早期阶段。 无需赘述-大多数情况下，这些都是覆盖率指标。 未来产品质量的指标之一是功能需求测试的覆盖率，该百分比是使用覆盖率表（矩阵）（可追溯性矩阵）计算得出的。 可以在矩阵中包括非功能性需求，但是在将来的工作中，它将被标记为不可测试，最重要的是，测试人员会将其评估为无用。 看起来，完整的“
软件需求规范 ”和一系列非功能需求对程序员非常有用。 如果至少在不定期的情况下，他们在编译后到那里看的话，也许会这样。
绝大多数非功能性需求可以以功能性方式编写。 换句话说，对系统或软件产品的几乎所有非功能性需求都可以处理为一个或多个功能性需求。
RTkPO中的质量属性部分属于功能要求，这是绝对正确的。 但是，RTkPO的局限性和外部接口定义如下：“
其他非功能性需求描述了系统与外界之间的外部交互，设计和实现的局限性。 “约束（constraints）与开发产品的外观和结构的可能性的选择有关 。” 与外界的通信子系统始终具有功能正常且经过测试的接口。
限制可以是功能要求吗？ 绝对可以，如果您将它们以倒置形式写成机会。 例如，该产品应该比竞争对手的产品更快（否则不需要它-一个非常严格的限制）。 首先，我们谈论的是决策的新颖性，已记录在案，包括需求形式。 但是很明显，系统应该在早期阶段就具有用于测量此速度的检测参数的模块。
因此，“
功能规范 ”是较低级规范的既定名称，其形式为格式化文档或在专用软件的控制下为数据库。
接下来的要求会怎样？ 除了开发人员（程序员）之外，测试工程师和QA（质量保证）工程师还将满足要求。 “测试”可以翻译为“验证”，但是借用的“测试”显然发生了。 再次翻译质量检查需要披露模型-在这里，它是原则的基础。 首先，“
适合目的 ”（产品应适合于预期目的），其次，“
正确的第一次 ”（“第一次” –应该消除错误），其次，项目独立。 这就是“
接受 ”，其原理是众所周知的军事接受和传奇的国家接受的基础。
需求规格将构成进一步设计文件的基础。 至少，这些要求将用于
用户文档的开发中。 通常接受的测试是从
测试计划开始，以
测试报告结束，即与规格直接相关的文档。 人们可以以不同的方式看待RTkPO中的数字-作为软件开发过程的通用模型（或软件生命周期模型）。 在此模型中，完成的文档是流程各阶段之间的入口/出口点。
文件将按时间顺序显示如下：业务需求（作为项目范围的一部分），系统需求（PO），功能需求，测试计划，测试报告，用户文档。 两个文档之间的界线是处理阶段。 通常以重复周期或螺旋形式绘制模型，但是，更容易看到一个简单的时间轴。 然后，该过程的第一阶段和最后阶段不是通过线段而是通过射线指示。 在现代演示中，时间轴在编码阶段的中间以字母“
V ”的形式弯曲，从而得到所谓的
V模型 。
虚线表示绕过时间轴的连接，表示可以提前开始一些工作。 例如，在制定了业务需求的情况下，您已经可以对产品的用户文档说些什么，并且针对系统形成的需求将提供未来软件的模型，其质量已经可以评估。
但是这些行的主要功能是显示V模型的可伸缩性（简化）。
支持所有阶段和文档始终是一种昂贵的乐趣，并且是输给更多移动竞争对手的非常普遍的原因 。 例如，一个人的工作是这样的：业务需求->开发（编码）->用户文档。 这是切口的上折线。 通常，外包公司会跳过较低的阶段而无需在功能规范上花钱，并且会受到一种或另一种系统要求（例如，
交互方案 ）的限制。 对于相同类型的产品，通常存在企业标准，并且从编码阶段开始，对开发人员进行内部测试的某些报告，以开始质量检查/接受阶段。
基本的V模型有助于明确责任范围。 例如，员工根据其工作阶段扮演验收工程师（QA）或测试工程师的角色。 指派他到特定项目或部门并不重要。 分析师，设计师，开发人员也是如此-一个人履行所有这些角色的能力不会反驳V模型。 对于验收工程师（QA）和分析师，基础是“系统要求”，他们将开发的软件当作黑匣子使用。 对于参与这些阶段的人员，设计，开发和测试是一个白盒，尽管程度不同。
总之，值得注意的是，V模型仍然可以表示（在这种情况下，说明了需求的设计演变）。 这不是直接的操作指南；实际的软件开发过程更加复杂。 但是其显示潜力很难被低估。
* Karl I. Wigers，“软件需求开发”。
**在RFC中用于指示需求级别的关键字（https://tools.ietf.org/html/rfc2119）
***必须-不要使用必须，因为没有人定义必须与必须如何不同。 另外，应已在法庭上阻止，不得已。 当然，听起来一定更强吧？ 我的意思是，如果您的老板告诉您您“必须”做某事，那么您将要做。 但是，在编写需求时，请保持简单，应使用（http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should-should）