システム要件定義・ソフトウェア要件定義｜システムアーキテクト試験

図ごとの着目点と、要件をどの層に置くか

要件定義では、何を作るかを関係者が合意できる形に書き表します。そのための図法と、要件の種類や層の区別がこの単元の中心です。図は、何に着目して描くものかで見分けるのが基本です。

DFD はデータの流れの図で、源泉と吸収（外部実体）、データフロー、プロセス、データストアの四つで描きます。関連や実体は構造を描く E-R 図の要素です。DFD を子に分割するときは、親に出入りするデータフローと子全体の出入りが一致し、入力か出力の欠けた子プロセスがないことを確かめます。既存の業務から作るなら、現物理、現論理、新論理、新物理の順にモデル化します。

UML では、外から見た機能とシステムの境界はユースケース図、業務の流れや分岐・並行処理はアクティビティ図、メッセージの時間順序はシーケンス図、オブジェクト間のつながりと分担はコミュニケーション図、一つのオブジェクトの状態の移り変わりはステートマシン図で描きます。SysML は UML を基に、要求図や制約条件を書くパラメトリック図などを加えた表記法です。

クラス図では、多重度を相手側の端に書き、自分一つから見て相手が幾つ対応するかを表します。コンポジションの菱形は全体の側に付きます。可視性の記号は、＋が公開、－が非公開、＃がサブクラスまでの限定公開です。分析モデルでは、外との窓口を境界、流れの段取りを制御、データの持ち主をエンティティのオブジェクトとして分けます。

機能要件はシステムが扱うデータと処理の中身、非機能要件は性能や可用性、運用の条件など、それをどの水準で実現するかを定めます。システム要件は人手の作業や機器も含む全体の取決め、ソフトウェア要件はソフトウェアで実現する機能やインタフェースです。システム要件で定めた内容は、システム適格性確認テストで確かめる対になっています。

表で漏れを確かめる道具もあります。CRUD マトリックスは機能とエンティティの組ごとに生成・参照・更新・削除を書き込み、決定表は条件の組合せと処理を対応させます。アシュアランスケースは、品質の主張を証拠と論理でつないで説明する文書で、故障や逸脱の原因を探す分析手法とは役割が違います。