簡単な答え：830-1998は標準ではありません。1998年のスタイルでSRSを書く方法に関する推奨ベストプラクティスです。
スーパーシードされた方法を見つけることができません（IEEEの高度な検索でも:(）
しかし、要件を指定する方法に関する方法全体が近年劇的に変化したためだと思います。
だから、これからは、少し修正された質問に答えようとします：
産業のベストプラクティスとは何ですか/ 2012年のスタイルでSRSを作成する場合の推奨されるベストプラクティスは何ですか？
古典的な方法で：
通常、ソフトウェア文書にはIEEE 1471の推奨事項を使用しますが、最近ISO / IEC 42010によってスーパーシードされました。これは非常に複雑な種類の文書です。新しいISOスタイル文書）
正式なドキュメンテーションに関する適度に優れた本はDocumenting Software Architectures、驚くほど優れた本は古いiconix本、古い古典はCockburnのWriting Effective Use Casesです。
今日の業界で実際に行われている方法について：
語られる真実、正式なプロジェクトのドキュメント、特に要件のドキュメントは、主にアジャイルの時代に殺されたとして、アジャイルマニフェストは正式な文書を阻止します。単一の大規模な正式な仕様はありませんが、代わりに、いわゆるユーザーストーリー、製品バックログなどがあります。これは、反復的な開発のためであり、2〜4週間の各サイクルで非公式に指定される機能はほんの一握りです。有名な本はUser Stories Appliedです。
いわゆる「実行可能」仕様がありますが、これは本質的にテスト用のドメイン固有言語（DSL）であるため、正式です。それらはUMLのOCLより良くも悪くもありませんが、おそらくより簡単に把握できますが、科学的ではありません。それらのほとんどはBDDフレームワークと呼ばれ、例にはFitNesse、Cucumber、Jasmineが含まれます-これらの大きな束を見つけるでしょう。BDDおよびTDD全般に関する有名な本もあります。
また、ソフトウェアエンジニアによる仕様は、情報アーキテクチャやインタラクションデザインを含むUXデザインに優先されるため、最近実際にコーディングできる人によっては行われず、競合が発生することがあります。これは、見た目がそれほど悪くない例です（標準ではありません！）が、UX /インタラクションコミュニティ内にはさらに多くのものがありますが、それらのためのまったく別のスタック交換サイトもあります。独自の基準、推奨されるベストプラクティスなどがあります。
しかし、古い方法に固執したい場合、例えば 大学の仕事ですか？
一般に、IEEE 830に準拠するようにしてください（スーパーシードされたものをWebページで見つけることはできませんが、IEEEはこれで良いことはありませんでした。レコードに有益な情報（例えば、私は、単一の俳優のスティック図がないと思う- >動詞-対象とシングルバブルが有用であると考えられる）、そこから全体的な目標のユーザの、全体的な範囲のユーザーのと全体的な方法の使用はいつでも再構築できます。
なぜ本をお勧めしますか？代わりに標準を見せてくれませんか？
繰り返しになりますが、このドキュメントは「スーパーシード」されたと思います。なぜなら、今日、要件の仕様に少々混乱が生じているからです。その方法については、多くの視点があります。
あなたに伝えることができる単一の機関はありません：「これが仕様の作成方法です」。ベストプラクティスがあり、完全ではなく、個人的に偏っている可能性がありますが、ドキュメントと指示の代表的なリストを提供しようとしました。
結局のところ、重要なのは、あなたが作成したドキュメントが、それを読んだすべての人が持っているすべての目標を達成できるかどうかです。これらの本ではかなりよく説明されており、これらはそれ自体がベストプラクティスです。ただし、1998年に多分あった単一の、分割されていないITコミュニティよりもはるかに小さなコミュニティではそうです。