トップダウン分析フェーズとは、システム化を検討する適用業務について現状および改訂内容をできるかぎり洗い出して、整理するフェーズです。
したがって、もっともＳＥの折衝及び整理能力が問われるフェーズです。
ユーザは、現状のビジネスがどうなっているかということと、今後どうしていきたいかということしかわかりません。もちろんＳＥはそれさえもわからない（本人が該当適用業務のユーザで、すでに業務を知っているという例外を除いて）わけですから、ここはひたすら教えていただくしかありません。
要領よく情報を引き出すための工夫として、ユーザ側に作成済の文書があればそれを徹底活用することや、インタビュー内容をあらかじめ用意して提出しておき、ユーザ側で事前準備してもらうことなどがあげられます。
それでは、ユーザ側で事前準備してもらうための要領を説明します。
当フェーズで重要なことは、ビジネスルールをユーザに本当に記入してもらうことです。
システム開発者用の特殊な道具や開発手法をユーザに押し付けると、余計に時間がかかってしまったり、記入していただけないことがありますので、現状分析の書式を規定せず、書きやすい用紙を使って書きやすいように書いてもらうことにしています。それでも多忙などを理由に書いていただけない場合は、インタビューなどで情報を引き出し、開発者側で記入することはいうまでもありません。
また、このフェーズでは100点満点の結果を求めないことが重要です。
事務規則や業務上のルールなどは、急に言われても思い出せるもではないと思います。
その時点で思い出せるものだけ引き出せれば、それが結果的に20点であろうと30点であろうとこの時点では十分です。
これらの情報はシステム設計の完了時点で100点に近づいていくもので、これらの情報の完成をギブアップしているわけではありません。
逆にこの段階で100点を目標としユーザ承認を得てからでないと次のフェーズへ移行しないという方法論（フェーズドアプローチ）は『これ以上思いつかない』といっている人に『思いつけ』と強制しているようなものです。
現段階でまとめることができるのも（こと）をまず並べて、必要な分析を加えたら速やかに次のフェーズへ移ることが賢明です。
少なくとも、この時点でこういうことをまとめる必要があるのだな、という意識をユーザに持っていただければ十分です。
たとえは、次のフェーズのビジネス運用を設計している途中で、またはその次のフェーズの画面および帳票を設計している途中で、これらの情報を思い出すきっかけはいくらでもあります。
あとは、システム開発者であるＳＥがこれらの情報の重要性を正しく認識していれば、部分的にトップダウン分析に戻ればいいわけです。（結果的に繰り返しトップダウン分析を行うことになります。）
