SRS文档和版本控制

Question

当在相对较小的项目上工作时，但是软件需求规范文档是必需的，那么在版本控制系统中包含所述文档是一种标准，还是管理方式不同。注意我说的是标准

Answer 1

是也不是。版本控制就是这样的:控制资产的修订，不管它们是源代码文本文件、图像，甚至是文档。软件工程师通常会将源代码和图形资源(一旦他们收到)置于版本控制之下，而图形资产和标准文档通常是由非工程师编写的。根据我的经验，这些人很少在版本控制下工作(尽管可以说他们应该这样做)。

需求规范通常不受版本控制的另一个原因是，它们通常不是文本文件(Word文档、电子表格或Google文档是常见的)，因此许多版本控制系统无法很容易地比较版本。是的，现代文字处理器可以智能地比较不同的修订，但有时版本控制系统无法调用该特性。

尽管如此，人们还是很自然地倾向于理解保存旧版本的重要性，我也看到了非工程师使用的各种临时方法，比如在文件名中添加修改号或日期。

你问有关标准，我知道没有普遍适用的官方标准，要求哪些资产需要在版本控制下，哪些不需要。这是一种管理和组织上的选择，而且各地都不一样。一些企业有明确的政策围绕这一点，使用内部或外部定义的指导方针，或特殊的软件工具，其他没有。

Answer 2

虽然我同意兰德尔·库克的回答的大部分内容，但我想添加一些额外的内容。

您的需求应该在配置管理之下，并在某种程度上受到控制。也就是说，您应该能够将给定的一组需求(可能在SRS文档或用户故事集合、数据库或其他格式中捕获)与给定的软件版本相关联。对于任何给定的软件版本，您可能想知道需求、设计、实现(源代码)、测试用例(测试代码、脚本、手动过程)，甚至测试结果。这方面的配置管理被称为“配置标识”。

配置管理的一个方面是版本控制。但是，根据工件的类型，实现版本控制的方式可能有所不同。源代码可以保存在非常适合管理软件(通常是文本文件)的工具中，比如Subversion或git。但是，可能需要不同的工具来正确地对其他工件进行版本化。需求管理工具(如DOORS )通常具有更改管理工作流，并支持需求的版本控制。对于文档，内容管理系统也允许您跟踪版本。

就标准而言，有关于配置管理的标准、有很多、一些主动的标准和一些撤回或取代的标准-- ANSI、ISO、IEEE、美国国防部、多个不同行业的特定行业实践，等等。它们对您的适用程度取决于各种因素--合同或监管义务、项目规模和类型、行业等等。它们可以为裁剪提供指导和起点。不过，最终还是要由开发组织来定义一个适合他们需求的流程。