ウォーターフォールの工程の界面は何で分離していると思う

「先日お願いしたプロジェクト計画書のレビューおねがいします」
「早速はじめましょうか」
「最初に契約関連ですが、契約は請負で、期間は…から…までで」
「見積時と契約に変更はないようですね、プロジェクト憲章はどう書きましたか」
「事前に相談したときに教えてもらったように目標は定量的に書きました。これです」
「なるほど、いいじゃないですか。この目標はいいですね」
「次に進んでいいですか。次はスコープです。これは提案時からの変更はありません。まぁ今時点は、ですが」
「多少は変わるでしょうが、スタート時点は大事をお客様と確認しておくことは大切ですから、キックオフミーティングでは、スコープも共通の基準として認識してください」

「次はプロジェクトの工程に進んでいいですか」
システム開発手法はウォーターフォールを採用したのでしたね」
「そうです、ウォーターフォールです。局面は、記載のとおりに分割しています」
「ところで、この分割した局面は、何を界面として分割したのかな」
「界面、ですか。どういう意味ですか」
「例えば、要件定義はその前後に工程があるのだけれど、その前後と何を境目にして分けたのか、と言う意味です」
「要件定義ですか。要件定義は『要件』を抽出する工程で、次の基本設計は「方式」の仕様を決定する工程です。境目…ですか…。」

「じゃあ変えて、単体試験と結合試験ならどう」
「単体試験はモジュール、プログラムの機能の試験、ですね。結合試験はプログラムの連携試験です。そうか、単体試験はプログラム単体としてのインタフェース、機能の試験で、結合試験はプログラム間の試験だから、単体試験と結合試験はインターフェースが試験工程を分割している境目、ですね」

「そう。じゃあ、前に戻って、要件定義の前後の境目は何だと思う」
「うーん、なら要件定義と基本設計から。そうだなぁ。要件と方式だから…、システムで実現する要件とその要件の実現するシステムの概念、でしょうか」
「そう。100点じゃないけど。じゃあ、要件定義の前と要検定義はどう」
「…ちょっと思いつかないです」

「ほら、プロジェクト憲章で目的を書こう、といったじゃない」
「はい、それで書きましたが」
「それって何だと思う」
「お客様の実現したいこと、です」
「それってお客さまの事業の課題だよね」
「そうです」
「何で実現するかまでは言及していないけど」
「でもITで効率化してとかありました」
「そうだったっけ。なら、事業の課題はどのくらいの割合かはわからないけれど、ITで解決したいと思っているわけだ」

「そう…、それが要件定義の前なんですね」
「どうしてそう思う」
「要件定義ではシステム化する要件と運用で対応する要件に仕分けしますから」
「整理するとどうなるの、要件定義の前は」
「事業課題が前ですね。後続が要件定義です。事業課題はお客さまが実現したい課題で、要件定義では課題を整理して業務要件とシステム化する要件に仕分ける」
「そうそう」
「ところで、なんで工程の界面、でしたっけ。これを確認しているのですか」
「ほら、deliverablesを作るためのインプットやアウトプットの定義が正しいかなーとか、WBSが界面と会っているかなーとか気になってね」
「あっちょっと待ってください。自信ないなです…」