システム要件と業務モデリング

要点と定義

システム要件定義では、利用状況や運用シナリオを基にシステムの境界と対象範囲を定め、機能や性能、利用者の業務手順、データ、運用などの要求を明確にします。要求は根拠や確認方法と結び付け、関係者と評価・レビューします。5W2Hの観点で、誰が、いつ、どこで、何を、なぜ、どのように行うかなどを整理すると、曖昧な要求を具体化できます。

ソフトウェア要件の分析・表現には、示したい対象に応じて図や手法を使い分けます。ユースケース図は、アクターとシステムが提供する機能との関係を表し、対象範囲を明らかにします。業務の手順そのものを示す図ではありません。

アクティビティ図は業務や処理の流れを表し、分岐、並行処理、同期を示せます。機能と利用者の関係を表すユースケース図とは、描く対象が異なります。

DFDはデータの流れ、E-R図は業務で扱う実体とその関連を表す手法です。BPMNは業務プロセスを共通の記法で表すものです。過去の出題で扱った補足として、BPMNにより業務の流れを統一的な表記で共有できる点が問われています。記法だけで実績の定量分析やデータモデルの自動生成ができるという意味ではありません。

トレーサビリティは、要求の根拠と、それを反映する設計・テストなどの成果物との対応をたどれる状態です。変更時に関係する成果物を追跡すれば、影響箇所を確認し、求められる品質に照らして変更を検証できます。追跡可能であることだけで、要求の正しさや品質の達成が保証されるわけではありません。

UMLの多重度は、関連の一方のインスタンスに結び付く、もう一方のインスタンス数の範囲を表します。業務上、各対象に関連する記録が必須なら最小数は1、任意なら0です。上限が要件で決まっていない場合は、特定の有限値を置かず、上限なしとして表します。

適用条件と例

たとえば、図書貸出システムの要件を整理するとき、まず対象にする業務と外部との境界を決めます。利用者がどの機能を使うかを示すならユースケース図、貸出申込みから確認までの処理順や条件分岐を示すならアクティビティ図が向いています。書籍や貸出記録の実体と関連を整理するならE-R図、業務間のデータの受け渡しを追うならDFDが候補です。

業務の手順を関係者間で共有する際は、BPMNの共通記法で流れを表現できます。要求を決める途中で画面や操作のイメージが曖昧なら、利用者へのヒアリングで必要なことを確かめたり、モックアップやプロトタイプを評価して仕様の漏れや実現可能性を早めに確認したりします。目的に応じて手法を選びます。

要求と成果物の対応を表で管理する例では、各要求に根拠を記録し、対応する設計項目や確認項目を結び付けます。要求が変わったらその行から関連箇所をたどり、影響する設計やテストを見直します。この追跡は変更の影響調査に役立ちますが、変更の承認や品質確認そのものに代わるものではありません。

多重度を決めるときは、まず業務条件から関連が必須か任意かを判断し、次に上限が定められているかを確認します。たとえば、各会員に登録記録が必ず一つ以上あり、記録数の上限が指定されていないなら、会員ごとの記録数は最小1、上限なしとします。図を読むときは、多重度がどちら側の個数を示すかも確認します。