機能要件とソフトウェアモジュール間のマッピング

Question

5つの機能ソフトウェア要件（R1-R5）があるとします。当社のソフトウェア設計により、6つのモジュール（M1〜M6）またはクラスが実装されます。私は、デザインが多かれ少なかれ最適であり、各モジュールが明確に定義された目的を持ち、モジュール間の依存関係が最小限に抑えられていると想定しています。

下の図の左側に示すように、要件とモジュールの関係はほぼ1対1になります。別のケース（別のプロジェクト）では、右側のように多対多の場合があります。

左側のバージョンは、おそらくテストとプロジェクト管理の観点から扱う方がはるかに簡単です。

私の質問：

要件とモジュールの間のこれらの異なるタイプの関係に一般的に使用される名前はありますか？
高度に相互接続されたケースでは、要件に欠陥があり、なんらかの方法で再構築する必要があると言えますか、それともより複雑なシステムを示しているだけですか？

Christophe · Accepted Answer

要件とモジュールの関係

要件とモジュールの関係は一般に明白ではないため、常に多対多になります。

1つのモジュールが1つの要件を実装することは非常にまれです。通常、モジュールはいくつかの関連する要件を実装します。
多くの場合、すべてではないにしても多くのモジュールに実装されることになっているいくつかの一般的な要件（たとえば、機能しないセキュリティ要件、またはヘルプボタンの可用性などのユーザーインターフェイス要件）があります。

したがって、高度に相互接続されたスキーマがあることは、要件に欠陥があることを必ずしも意味しません。また、複雑なシステムを扱っている可能性もあります。または、多くの一般的な要件を特定しました。

画像を簡略化する方法は？

複雑さをマスターするための最初のステップは、表現したいものを決定することです。

要件がシステムにどのように実装されているかを表現しようとしていますか？この場合、リンクを「に実装されている」関係に制限することで、図に表示するリンクを減らすことができます。したがって、他のモジュールに機能を提供するユーティリティモジュールに一般的な要件が実装されている場合、リンクは1つしかありません。
ユーザーの観点からモジュールが要件にどのように準拠するかを示したいですか？この場合、「ユーザーに提供される」タイプのリンクを回避することはできません。

別のアプローチは、要件のカテゴリを想定することです。例えば：

機能しない一般的な要件（すべてのモジュールで想定）
ユースケース要件（特定のビジネス機能に関連するトランザクション要件：これらは1つのモジュールで期待されます）
ユーティリティ要件（インクルードまたはエクステント、いくつかの異なるユースケースで使用：これらはユーティリティモジュールまたは複数のモジュールのいずれかで期待されます）
ユーザー・インターフェース要件（ユーザー・インターフェース・モジュールと相互作用するモジュールで期待される）

この図を使用してシステムを改善する方法

したがって、一般的に、相互接続が高いことは要件の欠陥を意味するものではありません。

ただし、たとえばハーバートのサイモンの「人工の科学」などのシステムに関するいくつかの基本的な理論は、最適な構造化システムでは、サブシステム間よりもサブシステム内でより多くの相互関係が期待されることを示唆しています。

したがって、「に実装されている」リンクのみを描画し、一般的な要件をすべて削除した場合（または、より良いのは、ユースケースのトランザクション要件のみを採用した場合）、左側の図のような状況になるはずです。

このような単純化/フィルター処理された図では、相互接続が高い場合、ユースケース要件に欠陥がある（まだ一般的すぎるか、あいまいすぎる）可能性があります。または、モジュールへのグループ化が理想的に考えられていなかったこと。

mutt · Answer

したがって、それらの用語でそれを考えないでください。全体像を作り出すのは複数の視点であり、そうでなければ非常に重要です。

BRD（ビジネス要件文書）が顧客から引き出されます。
これらは、ビジネスの理解から顧客のニーズを定量化するために書き出されます
技術要件は、ビジネスニーズをプログラム可能な技術用語に変換するために作成されます。これらはRTM（要件トレーサビリティマトリックス）に追加されます。
ユースケースは、製品の完成を目標とするシナリオとワークフローを例示するために書かれています。
アーキテクチャにRTM /ユースケースが提供され、Arch Designで機能します
詳細設計を行うために、RTM /ユースケースとArch Designが開発に提供されます

これが、あなたの質問で私たちが直面しているポイントです。詳細設計は、ビジネス要件に準拠する必要がある技術要件に準拠する必要があるArch設計に100％準拠する必要があります。技術的な実装は単純または複雑であるため、これは多対多の関係になる可能性がありますが、技術的に正しいことを行う必要がありますが、ビジネスはビジネスに適した方法で明確にする必要があります。したがって、ビジネスには、30のモジュールによって達成される400のものがあり、40のモジュールが9のビジネスを達成することもあります。これらの視点を維持する必要があるため、複雑な場合もあれば、単純な場合もあります。

テストは、テストへの異なるアプローチを必要とする技術的およびビジネス的アプローチを検証することです。適切なテストエンジニアリングは、オリジナルとファイナルを再構築して、オリジナルの意図と比較した最終製品の全体像分析を提供します。より複雑になるほど、テスターはより熟練する必要があります。また、考え方がまったく異なるため、仕事がまったく異なる理由でもあります。

そうは言っても、他のパースペクティブやロールが同様に重要であるのと同じように、単純または複雑な関係の数に関係なく、技術モジュールは記述された部分に準拠することが重要です。「不一致」または「マルチアラインメント」は、可能性のある穴を指摘し、他の方法では簡単に受け入れられる可能性があることを再考することで、アプリケーションの完全な成功を確実にするために存在します。