ソフトウェア要件の仕様と図
私はある大学のコンピューターサイエンスの学生ですが、SRSやアクティビティ図やユースケース図などのさまざまな図を使用することに少し混乱しています。 SRSの目的は、特定の目標を達成するために開発者が必要とする時間と労力を最小限に抑え、開発コストとシステムの相互作用を削減することです。
システムがどのように機能し、ユースケース図やその他の図を作成するかなど、このSRS情報を誰かが使用することは適切ですか？
SRS、ユースケース図、アクティビティ図などが実際にどのように相互作用するのか、少し混乱しています。
特定の図にある特定の機能は、一貫性を確保するために特定の図に反映する必要があることを理解しています。
しかし、一貫性を確保するために何を同じにすべきかを正確に解読することはできません。
私にとって、SRSの基本的な目的はソフトウェアチームにソフトウェアが何をすべきかを伝えることです。これは、進行中に単に構成することの代替手段です（別名「アジャイル」）。
オブジェクト指向の場合は、オブジェクト指向の分析と設計のアプローチを取る必要があります。ほとんどの場合、最初のステップは、SRS内のアクターを特定し、オブジェクトを特定することです（このレベルには1つしかない場合があります）。
次に、ユースケースを開発できます。非常に大きな図が必要でない限り、これはおそらくいくつかのユースケース図です。
その後、オブジェクトをパッケージに分解し、次にクラスに分解します。
一貫性は、トレーサビリティによってずっと下で行われます。 Everyソフトウェア要件は、設計の下にある何かで対処する必要があります（多くの場合ユースケースですが、常にではありません）。多くの場合、「要件マトリックス」はそれを文書化するための最良の方法です。
極端な場合（セーフティクリティカルなど）には、要件のトレーサビリティをこれまでに行って、誰かがコード内の行をポイントして「何のためにあるのか」と尋ねた場合、最後までトレースすることができます。どの条件を満たす必要があるかを正確に答えてください。
物事を複雑にしないでください。 SRSは、ソフトウェアが実行することになっていることを説明する単なるドキュメントですが、ソフトウェアがそれを実行する方法ではありません。プレーンテキストにすることもできますが、多くの場合、ダイアグラムを含めることは理にかなっています。多くの場合、ユースケースやアクティビティなどの標準化されたUML図を使用することをお勧めします。ただし、これは必須ではありません。
ソフトウェア要件仕様（SRS）は、利害関係者間のコミュニケーションを支援するツールです。コミュニケーションの促進以外にも、時間と労力を最小限に抑えたり、コストを削減したりすることを意図していません。 SRSドキュメントはスコープを説明し、テストケースを構築するための開始点を提供し、レビューおよび議論する具体的なものを提供します。
IEEE標準29148-2011-ISO/IEC/IEEE国際標準-システムおよびソフトウェアエンジニアリング-ライフサイクルプロセス-要件エンジニアリング は、 SRSの構造と内容。議論の多くはテキスト要件に関するものですが、標準は、ビジュアルモデルを含む要件をキャプチャする他の方法を認識しています。 UML（および類似の言語や手法）は、ビジュアルモデルとして含まれます。この規格では、データフロー、制御フロー、状態モデル、オブジェクトモデルなどについても言及されています。
ソフトウェア要件の ビジュアルモデルの方法とアプローチを定義することは、本全体を入手できるものです 。
個人的には、一部のモデルは他のモデルよりも要件エンジニアリングに適しています。 UMLで、アクティビティ図、状態図、展開図、およびユースケース図は、要件エンジニアリングに向いている傾向があります（ほとんどの場合、ユースケース図は避けることをお勧めします）。これは他のモデル（クラス図、シーケンス図）の使用を妨げるものではありませんが、忠実度が低くなる可能性があります。また、 UMLモード 、特に UML as Sketch 、および アジャイルモデリング テクニック。