我一直在研究如何更正式地记录软件项目，并且了解了IEEE 830-1998：《软件需求规范的推荐做法》。但是，从该链接可以看到，它已被取代。
我知道830-1998，甚至830-1993都可以使用。但是，如果没有别的，我想知道是什么标准取代了它。在这种情况下，可能没有关系，但是如果为了其他技术问题而取代了其他标准，我认为最好在某个地方链接取代的另一个标准（如果不是同一行中的另一个标准的话（830，在本指南中）案件））。
值得一提的是：
TLDR：您如何找到取代另一标准的标准，以及取代830-1998的标准？
Answers:
简短答案：830-1998 不是标准，它是关于以1998风格编写SRS的推荐最佳实践。
我找不到它的超级种子（即使使用IEEE的高级搜索:(）
但是我想这是因为近年来确定需求的整个方法已经发生了巨大变化。
因此，从现在开始，我尝试回答一些修改后的问题：
什么是行业最佳实践/关于以2012风格编写SRS的建议最佳实践是什么？
在经典方法上：
我通常使用IEEE 1471建议作为软件文档，尽管最近也被ISO / IEC 42010取代。这是一种非常复杂的文档，尽管主要包含要求，但它主要用于切换（在第7章中，第7章）。新的ISO样式文档）
关于正式文档的一本不错的书是《文档编制软件体系结构》，一本令人惊讶的好书是旧的iconix书，而一本经典的书是Cockburn的《写作有效用例》。
关于当今行业中实际的操作方式：
说实话，正式项目文档，尤其是需求文档在敏捷时代就被淘汰了，因为敏捷宣言不鼓励正式文档。没有一个单一的大型正式规范，而是所谓的用户案例，产品积压等。这是由于迭代开发，对于2-4周的每个周期，非正式地指定了少数功能。一本著名的书是《User Stories Applied》。
有所谓的“可执行”规范，它们是正式的，因为它们本质上是用于测试的领域特定语言（DSL）。它们并不比UML的OCL更好或更糟，但是它们更容易掌握，但也不够科学。它们中的大多数被称为BDD框架，示例包括FitNesse，Cucumber和Jasmine-您会发现其中的一大堆。一般而言，还有有关BDD和TDD的著名书籍。
而且，软件工程师的规范已被UX设计（包括信息体系结构和交互设计）所取代，因此，如今并非由能够实际编写代码的人来完成，这有时会导致冲突。这不是一个看起来很糟糕的示例（这不是标准！），但是您会在UX /交互社区中找到更多的东西，但是甚至还有一个单独的堆栈交换站点。他们有自己的标准，推荐的最佳做法等。
但是，如果您想使用旧方法，例如？上大学吗？
通常，尝试遵守IEEE 830（虽然在IEEE 830上没有找到它的超级种子，但是IEEE从来没有这样做，我想这是因为不再重要了，请确保尝试）以记录有用的信息（例如，我不认为一个演员简笔画- >以动词学科的单个气泡被认为是有用的），从总体目标用户，整体范围内的用户和整个方法的用法可以随时重建。
你为什么推荐书？您为什么不给我看标准呢？
再说一次，我猜这个文档是“超级种子”，因为今天，我们在需求规范方面有些混乱：关于如何完成需求规范有很多观点。
没有哪个机构可以告诉您：“这就是制定规范的方式”。有最佳做法，我尽力为您提供代表性的文档和说明列表，尽管这些文档和说明绝不完整，而且可能带有个人偏见。
归根结底，重要的是您创建的文档是否能够实现所有阅读该文档的人们所拥有的所有目标。：人们想要看到什么，人们需要知道什么才能理解需求这些书对它们进行了很好的描述，它们本身就是最佳实践，尽管与1998年我们所拥有的单一，未分割的IT社区相比，它们的规模要小得多。
我在IEEE网站上找到了这个： http //standards.ieee.org/findstds/standard/29148-2011.html
29148：2011标准似乎取代了IEEE 830：1998。
该标准代替了IEEE 830-1998，IEEE 1233-1998，IEEE 1362-1998。
ISO / IEC / IEEE 29148：2011包含与整个生命周期中的系统和软件产品及服务的需求工程相关的过程和产品的规定。
它定义了一个好的需求的结构，提供了需求的属性和特征，并讨论了整个生命周期中需求过程的迭代和递归应用。