さて、いままでの話で、要求分析を始めるために、出力帳票の分析をするという話とかかきましたけど、問題は、どこまで分析するか。
この分析は、あくまでも、仕様を固めるためのものだから、
１．このシステム開発で実現しようとする業務やビジネスモデルに対して、
２．このシステムの出力を利用して
３．その業務、ビジネスモデルが実現できることを、シナリオとして表せる
ということが大事で、３の内容が実現するために利用する、２の出力が分析対象になる。
つまり、開発するシステムを利用してできる業務、ビジネスモデルを明確に描き、その中で必要とされる出力を分析し、それに対応する入力を、そのあとで分析することになります。
通論とかは、この出力から入力が思い浮かばない場合や、抜けがないかどうかを確認するのに必要となります。
ちなみに、上記の「開発するシステムを利用してできる業務、ビジネスモデルを明確に描き」すなわち、上記１．２．３の３に相当するのが、ブログ「ウィリアムのいたずらが行った場合の「コピーされるほど儲かるシステム」の見積もり」の「（あ－１）まず、ユーザーの利用の仕方の絵を書く」にあたります。
現実的には、もらった資料を分析しながら、最終的に、こう利用するんだよねというシナリオを描き、そのあと、そのシナリオにもとづいて、資料を位置づけ、足りない資料を補う形になると思います。
で、この利用の仕方のシナリオが実現できるかどうかを確認するのに、フィージビリティスタディをやったり、プロトタイプをつくるのが、本来のあり方だとおもう。
で、問題は、そのビジネスモデルとか、業務とかは、なんについて書くか？ということ。
これは、放送大学大学院の経営システム１でやってたけど（すみません、詳しいページは忘れました。今度調べて、書き直しておきます）、以下の５つ
１．物の流れ
２．金の流れ
３．情報のながれ
４．人の流れのうち、業務の役割の流れ
５．人の流れのうち、インセンティブの流れ
この５つの流れについて、問題なく流れれば、システムとなる。
たとえば、今まで取り上げている夕食支援システムは、この流れで考えると崩壊する。
つまり、ものの流れとしては、発注表を出すので問題ない。
しかし、実際のシナリオを描いてみると、
■■ マクドナルドにて
１．夕食の発注表を担当の人が読み上げる
２．お店の人が、ご注文は、以上ですか？という
３．はいと答える
。。。このあと
４．お店の人のたまわく「お会計先によろしいですか」
がーん！お金を回収してないから、かえないじゃん！
つまり、夕食支援システムは、お金をどうするか（会社立替え？それともみんなから回収？）といった、「金の流れ」を決めない限り、このままでは、出来ないことになる。
ちなみに、放送大学の、このビジネスモデルの考え方の鋭いところは、インセンティブのシステムについて、考えていること。
これ、必要なければいいんだけど、代理店のシステムなんかだと、結構大切。
インセンティブの設計なんかがいい加減だと、矛盾したシステムになり、毎月、計算して、発送した後で、「すみません、いまの計算、間違えてました！」などというお知らせを送らないといけなくなるので、注意っす。
っていうことで、やっと、次あたりから、「コピーされるほど儲かるシステム」の、要求仕様作成のための分析に入れそうです。
