5つの機能ソフトウェア要件(R1-R5)があるとします。当社のソフトウェア設計により、6つのモジュール(M1〜M6)またはクラスが実装されます。私は、デザインが多かれ少なかれ最適であり、各モジュールが明確に定義された目的を持ち、モジュール間の依存関係が最小限に抑えられていると想定しています。
下の図の左側に示すように、要件とモジュールの関係はほぼ1対1になります。別のケース(別のプロジェクト)では、右側のように多対多の場合があります。
左側のバージョンは、おそらくテストとプロジェクト管理の観点から扱う方がはるかに簡単です。
私の質問:
要件とモジュールの間のこれらの異なるタイプの関係に一般的に使用される名前はありますか?
高度に相互接続されたケースでは、要件に欠陥があり、なんらかの方法で再構築する必要があると言えますか、それともより複雑なシステムを示しているだけですか?
要件とモジュールの関係
要件とモジュールの関係は一般に明白ではないため、常に多対多になります。
したがって、高度に相互接続されたスキーマがあることは、要件に欠陥があることを必ずしも意味しません。また、複雑なシステムを扱っている可能性もあります。または、多くの一般的な要件を特定しました。
画像を簡略化する方法は?
複雑さをマスターするための最初のステップは、表現したいものを決定することです。
別のアプローチは、要件のカテゴリを想定することです。例えば:
この図を使用してシステムを改善する方法
したがって、一般的に、相互接続が高いことは要件の欠陥を意味するものではありません。
ただし、たとえば ハーバートのサイモンの「人工の科学」 などのシステムに関するいくつかの基本的な理論は、最適な構造化システムでは、サブシステム間よりもサブシステム内でより多くの相互関係が期待されることを示唆しています。
したがって、「に実装されている」リンクのみを描画し、一般的な要件をすべて削除した場合(または、より良いのは、ユースケースのトランザクション要件のみを採用した場合)、左側の図のような状況になるはずです。
このような単純化/フィルター処理された図では、相互接続が高い場合、ユースケース要件に欠陥がある(まだ一般的すぎるか、あいまいすぎる)可能性があります。または、モジュールへのグループ化が理想的に考えられていなかったこと。
したがって、それらの用語でそれを考えないでください。全体像を作り出すのは複数の視点であり、そうでなければ非常に重要です。
これが、あなたの質問で私たちが直面しているポイントです。詳細設計は、ビジネス要件に準拠する必要がある技術要件に準拠する必要があるArch設計に100%準拠する必要があります。技術的な実装は単純または複雑であるため、これは多対多の関係になる可能性がありますが、技術的に正しいことを行う必要がありますが、ビジネスはビジネスに適した方法で明確にする必要があります。したがって、ビジネスには、30のモジュールによって達成される400のものがあり、40のモジュールが9のビジネスを達成することもあります。これらの視点を維持する必要があるため、複雑な場合もあれば、単純な場合もあります。
そうは言っても、他のパースペクティブやロールが同様に重要であるのと同じように、単純または複雑な関係の数に関係なく、技術モジュールは記述された部分に準拠することが重要です。 「不一致」または「マルチアラインメント」は、可能性のある穴を指摘し、他の方法では簡単に受け入れられる可能性があることを再考することで、アプリケーションの完全な成功を確実にするために存在します。