何でもそうですが、何かを作ろうと思ったら、まず設計図を書くことから始めます。
家でもそうですし、車でもそうです。
簡単なものなら設計図なしでもなんとかなりますが、そこそこのものを作る場合には
・大きさは?
・最終的な形は?
・色は?
・各部をどう作る?
などを決めておかなければなりません。
犬小屋を作るときでさえ最初にしっかりと考えておかないと、作っている途中で「はた」と困ってしまいます。

システムを作る場合も同じように設計は重要です。
ちょっとしたプログラムなら別ですが、それなりのプログラムを作るのに設計書を書かない人はまずいません。
しかし、この設計書というものがなかなか曲者なんですよね。

設計書にはいくつかの種類がありますが、基本的には必要な要件や全体をどう作るかということから、考えられる問題点、それを解決する方法など様々なことを紙にまとめておくものです。
もちろん、お客様に見せて確認を取る必要があるものは、お客様が見て理解できる内容にしておかなければなりません。
自分で読むだけなら良いのですが、他人に見せて理解してもらう資料、となるとなかなか難しい。

お客様が見てわかるのは、まず見た目、次に特徴、機能、制限事項というように、外からみた大きな部分がほとんどです。
内部の細かい点はお客様に説明してもわからないことが多いですから、それはシステム屋さんが頑張って考えます。
ということで、お客様向けの設計書は、
・画面イメージ
・レポートイメージ
・操作方法
・容量や制限(どけだけ登録できるのか、何件以上でできなくなるのか、など)
などが中心の資料になります。
お客様としては実際に操作するだけですから、別に中身を理解する必要はありませんし、期待通りに動いてくれればOKということになります。

しかし、紙で作った設計書には「動き」の要素を盛り込むのが難しいという問題があります。
このため、実際に使ってみると設計書で考えていたイメージと違う、という話が出てくるわけですね。
お客様はシステムのプロではありませんので、設計書を見て実際の動きを理解することは難しいです。
でも後々問題にならないように、なんらかの方法でお客様に「最終的な動きを理解してもらう」ということが必要になってきます。

「動き」を理解してもらうには、動かしてみることが一番の近道です。
これを解決する方法として、昔からプロトタイプというものが使われてきました。
事前に「似たもの」を作って、検証する、問題点を洗い出す、などを行い、設計書に反映させようと言うものです。
しかし、システム開発の場合、以前のプロトタイプは見た目を確認するためだけの「動かない」ものだったり、製造工程に入ってから試験のために作ってみた「遅い段階でできあがる」ものだったりと、これから作るものを「お客様にイメージさせる」ものではないことがほとんどでした。
求めるプロトタイプを作るために、時間や費用がかかるからです。

ただし、システムも大規模化、複雑化していますから、早い段階で問題点を洗い出すためにも、プロトタイプなどを使った検証は重要になると思います。
最近は、早い段階でのプロトタイプ作成が難しいことから、スパイラルモデルのように「設計とプロトタイピングを繰り返し」て開発する手法も注目されていますし、アジャイル開発のように「開発対象を多数の小さな機能に分割」して行なうことも行なわれています。
いずれも、早い段階で「動きを見せる」ことにより問題点を見つけ出し、設計にフィードバックしていくことができます。

システム開発では早い段階で「動き」をどう見せるか、ということを考えておくことが重要だと思います。