システム化計画と要件定義

要点と定義

企画プロセスでは、事業の目的や目標に照らし、システム化が必要な業務課題や経営上のニーズを明確にします。 共通フレームでは、企画プロセスの下位にシステム化計画の立案が位置付けられます。

要件定義では、利害関係者の種類、ニーズや要望、制約条件を識別します。 機能要件はシステムが行う処理などを定め、非機能要件は可用性や性能などの品質・運用条件を定めます。たとえば「検索結果を一覧表示する」は機能、「障害から所定時間内に復旧する」は非機能の観点です。

セキュリティバイデザインは、企画・設計段階からセキュリティを確保する考え方です。 移行テストでは、旧システムから新システムへの切替手順や、切替えに伴う問題を確認します。

適用条件と例

計画時には、まず事業上の課題を捉え、それを実現するための要件へ具体化します。たとえば、窓口の待ち時間を減らすことが事業課題なら、利用者の要望や業務上の制約を確認してから、必要な処理や運用条件を定めます。要件定義で利害関係者のニーズと制約を識別することが、その後の設計の前提になります。

要件を分類するときは、処理の有無と品質・運用条件を分けて考えます。予約内容を登録する機能と、繁忙時にも一定の応答時間を保つ条件は別の観点です。具体的な基準や数値は、対象業務の要求に応じて設定します。

セキュリティを企画・設計に組み込むという考え方は、完成後の対策追加ではなく、初期段階から確保を検討する点にあります。具体策はシステムの要件やリスクに応じて検討します。

移行テストは、切替えを伴う移行計画に対して実施し、手順の確実性や切替え時に起こり得る問題を確かめます。実データで性能を測ることや、機能が要求を満たすことの確認とは目的が異なります。

誤りやすい点

業務上の課題や経営上のニーズは企画で明確にし、利害関係者のニーズ・制約を識別するのは要件定義です。システム化計画の立案が企画プロセスに含まれることも、プロセスの位置付けを判断する手掛かりです。