http://www.kumikomi.net/archives/2012/04/ep04agi1.php?page=3
細谷 泰夫
機器の設定を行う画面は，エンド・ユーザが使用する「機器の顔」とも言える重要な部分です．従来は，画面仕様書に画面イメージ，各表示項目の表示形式や説明，データの例などを詳細に記述していました（図3）．10画面あるとすると，10画面全てに対して，これらの詳細な記述を行います．そして，そうやって作成した画面仕様書をしっかりとレビューを重ねた後に，ソフトウェアの設計を行うことにより，手戻りを削減していました．
図3 画面レイアウトの表記例 出典：独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター；発注者ビューガイドライン（画面編）ver.1.0，2008年7月．
アジャイル開発だと，以下のようなやり方になります．
「アジャイルはイテレーションごとの課題に取り組むので，全体がどうなるかについては考えない」と思っておられる方もいるかと思いますが，それは誤解です．実際には，イテレーションの開始前に，「その時点で分かっている全体像」について分析を行います．今回の例だと，必要な設定機能を列挙し，その設定機能に必要な画面はどのようなものであるかを分析します．
そして分析した結果を何らかの形で残します．結果を残す目的は，細部を定義することではなく，各機能の目的を共有すること，そして，今後，その機能についてさらに詳細化したり，新たな要求による方針変更のための議論の出発点とするためです．成果物の形としてよく使われるのは，ホワイト・ボードの写し，画面をスケッチ風に簡単に作成できるソフトウェアで作成した画面スケッチなどです．画面や機能を「定義」するものではない点に注意してください．
全体を分析した結果の設定画面のスケッチなどの情報を基に，イテレーションで取り組む機能について詳細化を行います．Face To Faceのディスカッションにより，画面のデザインや，正常時およびイレギュラなケースでの振る舞いなどを決めていきます．
この詳細化の結果も，ホワイト・ボードの写しなどで残します．そして，その後の設計や実装，テストは，このホワイト・ボードの写しなどで共有した情報を基に行われます．
取り組んだ設定機能が動作するようになったら，動作するソフトウェアを用いたデモを行います．ここできちんと目的に合う機能や画面が実装されているかを関係者で確かめます．最初は思いつかなかったが，動作するソフトウェアを使ってみて初めて思いつくような要求も，フィードバックとして扱います．
従来の画面仕様書のようなドキュメントを作るタイミングをいつにするかについては，絶対的な基準はありませんが，製品を公式にリリースするタイミングや，数イテレーションごとなどのタイミングでドキュメントとして今までの現状をまとめます．ここでは，「今から作るソフトウェア」ではなく，「既に実際に動作しているソフトウェア」について記載することになります．
これは，あくまでも例であり，全てのコンテキストで同じやり方になるわけではありません．しかし，従来の開発とアジャイル開発のドキュメンテーションに対する姿勢の違いについては，理解していただけるのではないかと思います．