要件定義や外部仕様などが完成した際にお客様へ説明を行う場合があります。
（というか殆どで説明しています）
この時に、文字が沢山書かれた資料だと説明もしづらいですし、聞く方もつらいと思います。
筆者は、レビューの際にはできるだけ画面の流れを多く示して説明するようにしています。
（時間ある時はパワポで紙芝居のように動きを見ていただけるようなものを作成します）
主なところだけ詳しく説明し、それ以外は流して説明。
詳しく書いた定義書（仕様書）は、プレゼン資料とともに参考資料扱いとして一緒に提出します。
（細かな部分は資料を読んでくださいということで）

昨今は、業務システムでもブラウザベースのシステムが主流になってきました。
フロント側の実装をスケルトンで先行実装することで画面モックアップの作成がやり易くなりました。
アプリケーション開発時代のように、Photoshopで絵を描く必要が無くなったのはうれしい限りです。
モックアップ画面の構築ですが、たしかに少々手間になってしまいます。
ですが、モックアップ画面であれば、お客様も完成時のイメージがつきやすいです。
紙芝居が詳しければ詳しいほどやり直しの可能性は低くなります。
そのためモックアップ画面の作成は、非常に重要なプロセスだと思っています。

モックアップ画面を作成するためには、画面設計がほぼ完了している必要があります。
要件定義の段階で説明するとなると、先行開発的な感じになってしまいます。
何となく、違和感を感じられるかも知れません。
ですが、モックアップ画面はできるだけ早い段階で構築し、顧客に共有することを勧めします。

画面ですが、プロトタイプ版として動作するレベルまで仕上げる必要はありません。
紙芝居で十分に商品説明ツールになり得ますので。