问什么标准取代了830-1998？

EN

简短的回答: 830-1998不是一个标准，它是关于如何以1998年的风格编写SRS的一个推荐的最佳实践。

我找不到它是如何被超生的(即使使用IEEE的高级搜索:( )

但我想这是因为我们如何指定需求的整个方法在最近几年发生了巨大的变化。

所以，从现在开始，我试着回答一个修改过的问题：

什么是工业最佳做法/在编写2012年风格的SRSs方面所建议的最佳做法是什么？

经典方法的

：

通常我在软件文档中使用IEEE1471的建议，尽管这也是最近被ISO/IEC 42010所取代的。这是一种非常复杂的文档，主要用于切换，尽管它包含了大部分需求(这是新ISO风格文档中的第7章)

关于正式文档的一本比较好的书是软件体系结构文档化，一本令人惊讶的好书是旧伊科尼克斯书，一本古老的经典是科伯恩的有效用例。

关于它在今天的行业中是如何实现的：

老实说，正式的项目文档，特别是需求文档，大多是在敏捷时代被淘汰的，因为敏捷宣言不鼓励正式的文档。没有单一的、大型的正式规范，而是有所谓的用户故事、产品积压等等。这是因为迭代开发，在每个2-4周的周期中，只非正式地指定了少数几个特性。一本著名的书是用户故事应用。

有所谓的“可执行”规范，它们是正式的，因为它们本质上是用于测试的特定于域的语言(DSLs)。它们并不比UML的OCL好或差，但它们可能更容易理解，但也不那么科学。其中大多数被称为BDD框架，示例包括FitNesse、黄瓜、茉莉 --您会发现其中的一大串。此外，亦有著名的书籍有关BDD和TDD的一般。

此外，软件工程师的规范也被UX设计所取代，包括信息体系结构和交互设计，因此它并不是由现在真正会编码的人来完成的，这有时会导致冲突。这是一个关于一个人的样子的不错的例子 (这不是一个标准！)，但是您可以在UX /交互社区中找到更多的东西，但是甚至还有一个完整的单独的堆栈交换站点。它们有自己的标准、推荐的最佳做法等。

，但是如果你想坚持旧的方法，比如。大学工作？

一般来说，试着遵守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包含与整个生命周期系统和软件产品和服务的需求工程相关的流程和产品的规定。它定义了良好需求的构造，提供了需求的属性和特性，并讨论了需求过程在整个生命周期中的迭代和递归应用。