システム要件定義・ソフトウェア要件定義｜エンベデッドシステムスペシャリスト試験

表したいものは構造か、流れか、状態か、同期か

要求を表すモデルや図は、何を表したいかで選び分けます。データの構造ならE-R図、データの流れならDFD、状態の移り変わりなら状態遷移図、並行して進む事象どうしの同期ならペトリネットです。組込みシステムでは、事象と状態とタイミングを表せるかどうかが選ぶ軸になります。

ペトリネットは、プレース、トランジション、トークンで振る舞いを表し、入力側の全てのプレースにトークンがそろったときにトランジションが発火します。この待ち合わせで同期を表現できます。状態遷移図は、同じ事象でも今の状態によって動作が変わる対象、たとえば通信プロトコルの記述に向きます。DFDに制御の流れや事象を書き加えて制御とタイミングを表すのがリアルタイム構造化分析で、変換図を使います。事象ごとにシステムが応答する一連の動作を洗い出すのが事象応答分析です。

UMLの図は、構造を表す図と振舞いを表す図に分かれます。クラス図、オブジェクト図、パッケージ図、コンポーネント図、配置図は構造の側です。シーケンス図は縦に時間の流れをとり、オブジェクト間のメッセージを順に描きます。状態マシン図はイベントによる状態の移り変わりを表し、どちらも振舞いの側です。相互作用を描く図でも、オブジェクトどうしのつながりに注目するのはコミュニケーション図です。

DFDを階層化するときは、親のプロセスを子プロセスに分けても、外との出入りのデータフローは親と一致していなければなりません。さらに、どの子プロセスにも入力と出力の両方があり、データが湧き出たり消えたりする箇所がないことを確かめます。

共通フレームでは、要件を定める工程と、それを確かめるテストの工程が同じレベルで対応します。システム要件定義で定めた要件は、システム適格性確認テストで満たされたかを確かめます。要件定義の終わりの評価では、その要件を満たす方式設計が実現可能かを見極めます。方式との一貫性や追跡可能性は、方式を設計した後で確かめる事柄です。

非機能要求の可用性は、継続性、耐障害性、災害対策、回復性に分けて考えられます。継続性は、運用時間や目標復旧時間、稼働率のように、どれだけ止めずに使えるかを数値で示す要求です。