web-dev-qa-db-ja.com

830-1998に取って代わった規格は何ですか？

私はソフトウェアプロジェクトをより正式に文書化する方法を調査しており、 IEEE 830-1998：ソフトウェア要件仕様の推奨される実践 について学びました。ただし、そのリンクからわかるように、置き換えられています。

私は830-1998、そしておそらく830-1993でさえ、おそらく問題なく使用できることを知っています。ただし、他に何もない場合は、どの標準がそれに取って代わったのかを知りたいと思います。この場合は問題ではないかもしれませんが、他の標準がより技術的なものに取って代わられる場合、どの標準が別の標準に取って代わったかをどこかにリンクすることは良い考えだと思います（同じ行の別の標準ではない場合（830、この場合））。

それは言及する価値があります：

  1. IEEE規格協会のWebサイトで「ソフトウェア要件の仕様」または「ソフトウェア要件」を検索したときの最新の標準は830-1993です。
  2. 2004年（現在）バージョンの [〜＃〜] swebok [〜＃〜] は830-1993を参照（ 2.5項 ）、
  3. ドキュメントの Wikipediaの記事 は、標準が置き換えられたことについては言及していません。

TLDR：どの規格が他の規格に取って代わり、どの規格が830-1998に取って代わったのですか？

documentationrequirementsstandards
17
user1564158

短い回答：830-1998は標準ではありません標準ではありません。 1998年のスタイルでSRSを記述します。

それがどのようにスーパーシードされたかを見つけることができません（IEEEの高度な検索を使用しても:(）

しかし、私が要件を特定する方法に関する全体的な方法が近年劇的に変化したためだと思います。

それで、これからは、少し変更された質問に答えようと思います：

業界のベストプラクティスとは/ 2012年のスタイルでSRSを作成する上で推奨されるベストプラクティスは何ですか？

古典的な方法について：

通常、ソフトウェアのドキュメントにはIEEE 1471の推奨事項を使用しますが、最近ISO/IEC 42010によってスーパーシードされました。これは非常に複雑な種類のドキュメントであり、主にハンドオーバーに使用されますが、ほとんどの要件が含まれています（新しいISOスタイルドキュメント）

正式なドキュメントに関するやや良い本は Documenting Software Architectures であり、驚くほど良い本は old iconix book であり、古い古典は Cockburnの書き込み効果的な使用例です。 。

今日の業界で実際にどのように行われているかについて：

Agile Manifesto が正式なドキュメントを阻止するため、正式なプロジェクトドキュメント、特に要件のドキュメントは、主にアジャイルの時代に打ち切られました。単一の大きな正式な仕様はありませんが、代わりに、いわゆるuser stories、product backlogsなどがあります。これは反復的な開発が原因であり、2〜4週間の各サイクルで非公式に指定される機能はほんの一部です。有名な本は ユーザーストーリー適用 です。

いわゆる「実行可能」仕様があり、それらは本質的にテスト用のドメイン固有言語（DSL）であるため、正式なです。それらはUMLの [〜＃〜] ocl [〜＃〜] より良くも悪くもありませんが、おそらくより簡単に理解できますが、科学的でもありません。それらのほとんどはBDDフレームワークと呼ばれ、例には FitNesse 、 Cucumber 、 Jasmine が含まれます-これらの多くが見つかります。 BDDとTDDに関する一般的な著書もあります。

また、ソフトウェアエンジニアによる仕様は X設計によって上位に追加されました。これには、情報アーキテクチャと対話設計が含まれているため、今日実際にコーディングできる人々によって行われていません。これは時々衝突を引き起こす可能性があります。これは not-so-bad example がどのように見えるか（これは標準ではありません！）ですが、UX /インタラクションコミュニティの内部にはもっと多くのものが見つかりますが、全体もあります- separate stackexchange それらのサイト。独自の基準、推奨されるベストプラクティスなどがあります。

しかし、古いメソッドを使い続けたい場合はどうでしょうか。大学の仕事ですか？

一般に、IEEE 830に準拠するようにしてください（スーパーシードが何であるかをWebページで見つけることができませんが、IEEEはこれで十分ではありませんでしたが、残念ながら、それはもはや問題ではなくなったためだと思います）。 有用な情報を記録する（例えば、私は単一の俳優のスティックフィギュア->動詞主語を含む単一のバブルが有用であると考えられるとは思わない）そこから全体的なユーザーの目標、ユーザーの全体範囲、および使用の全体メソッドは、いつでも再構築されます。

なぜ本を推薦するのですか？代わりに規格を見せてくれませんか？

繰り返しになりますが、このドキュメントは「スーパーシード」だったと思います。今日、要件の仕様に少し混乱があります。それをどのように行うべきかについて、多くの見方があるからです。

「これが仕様の作成方法です」と言うことができる単一の権限はありません。 ベストプラクティスがあり、私はドキュメントと指示の代表的なリストを提供しようとしましたが、決して完全ではありませんが、おそらく個人的に偏っています。

結局のところ、あなたが作成するドキュメントがそれを読んだすべての人が持っているすべての目標を達成することができるかどうかが重要です：人々が見たいもの、要件を理解するために人々が知っておくべきことはこれらの本でかなりよく説明されており、これらはそれ自体がベストプラクティスです。

23
Aadaam

私はこれを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には、ライフサイクル全体のシステムおよびソフトウェア製品とサービスの要件のエンジニアリングに関連するプロセスと製品の規定が含まれています。

これは、適切な要件の構成を定義し、要件の属性と特性を提供し、ライフサイクル全体にわたる要件プロセスの反復的および再帰的な適用について説明します。

9
Fabricio