デジタル技術を活用して新たなサービスを立ち上げたり、既存のビジネスを変革したりするDX（デジタルトランスフォーメーション）。DXの実践において、従来型の基幹系システム開発プロジェクトとは構想フェーズでの作業が大きく異なる。そのうち最も重要な作業の1つが、「サービス要求定義」のプロセスである。
基幹系システム開発プロジェクトの構想フェーズの主な作業は、新規開発、システム移行、システム統廃合などの構想を固めることだ。これらの場合、取り組むべき課題の解決策は、ERP（統合基幹業務システム）パッケージの採用検討や開発言語の見直しなど、製品や技術の検討が中心になる。つまり、ある程度「何をするか」が明確なので、効果やコスト試算、開発計画などの「どうやってやるか」に重きが置かれる。
一方DXプロジェクトの構想フェーズは、「何をするか」を定義するところから始まる。例えばB2C（消費者向け）のサービス構想策定作業の場合、誰（どんな消費者）に、なぜ、どのようなサービスを提供するのかを決めていく。このフェーズで適切なアウトプットを出せなければ、新しいサービスを立ち上げたとしても誰も使わないものになりかねない。DXプロジェクトの成否は構想フェーズにかかっていると言っても過言ではない。
この構想フェーズでやるべきプロセスの1つが「サービス要求定義」だ。構想フェーズの作業プロセスは大きく4つに分けられる。具体的には、誰の課題に対して何を提供するのかを決める「サービス企画」、サービスを具体化するとどんな機能になるのかを検討する「サービス要求定義」、サービスをどのように提供するのかを決める「事業戦略・計画」、構想フェーズの次に何をするのかを決める「次フェーズ計画」――である。
このうちサービス要求定義は、開発するシステムの要求や業務要求を定義するプロセスだ。サービス企画で決まったサービスのアイデアを受けて、それを具体化する。ここでいう「要求」とは、サービスとして何を提供・実現したいのかを示す。誰がどんなシーンで、どのようなシステム機能を使うのか、どんなデータが発生するか。サービスを開発・提供することでどのような業務が発生するかを検討する。
サービス要求要求定義の手順は、以下のようになる。まずサービスの登場人物（アクター）と利用シーン（ユースケース）を整理する「アクター／ユースケース整理」を実施。そしてそれぞれの利用シーンをフローにして具体化する「ユースケース分析」を行う。アクターそれぞれがいつ何をするのかをフローとして整理し、操作画面があるサービスの場合は画面イメージも用意して、利用シーン・利用方法を具体化していく。
ユースケース分析を通じてサービスの内容を細部まで詰めたら、それを基にシステムに必要な機能を整理して、最後にサービスの提供メニューや商品を決定する「システム機能要求整理」「業務機能要求整理」を実施する。
