しまった！昨日の
ベームの見積もりの不確実性の図やマコネルの不確実性コーンは、JQueryやREST、ＣＩ時代にも有効か？
http://blog.goo.ne.jp/xmldtp/e/e5a0154e483aaff790d930cbcdd65649
の前に、こっちを書かないといけないんだった。じゃないと意味が通じない・・・
要求分析は、詳細化していくと、どこまでも詳細化できてしまう。
では、どこで止めるべきか？
というお話。
まず、このとき、機能要件と非機能要件で分ける。
１．機能要件で、データの入出力を決める
（GUIの様子とかではなく、項目とその文字種、桁数などまで）
２．非機能要件は、それ以外のUIや、性能などを決める
とする。
そしてこのとき、以下の事前準備が出来ているとする
【事前準備】
・非機能要求に関しては、非機能項目のチェックリストが挙がっていて、
（非機能要求グレードを創造してもらうと良い）
そのチェックリストにチェックを入れると、どのように実現すればいいのか
技術的に分かっている（＝リファレンスモデルがある）
例：GUIの場合、
データの型が決まってしまえば、どのJQueryを使えばよいかが分かり、
どのようなチェックをするかも決まっていて（桁数チェック等）
それがすぐに実装可能になっていること（JSをインクルードして、datatypeを指定すればよい等）
DBアクセス性能の場合
DBアクセスモジュールが容易に作成でき、速度が足りない場合、DBをアップデートしたり、
メモリキャッシュを使ったりするという技術的にどうすればよいかが分かっていて、
それが容易に切り替えられるように、DI等でプログラミングされている
■機能要件は何処まで決めればいよいか
まず、出力の項目を決めないといけない。
そして、出力するプロセスにおいて、何を入力するかを決めないといけない
さらに、入力したものが、「開発者が知っている」関数、演算方法等を利用し、
出力が作成できなければならない
例：月次売上高をPDF出力する
出力項目
・年月 売上高の表
・年月を横軸、売上高を縦軸にしたグラフ
（位置関係は設計時に決めるものとする）
入力項目
売上データ
・年月日日時 バスケットNo 売上金額
とあったとき、入力項目から出力を作成するには
・売上データを年月ごとに合計する
・その合計値を表に書く
・その合計値を元にグラフを書く
・PDF出力する
となる。
このとき、位置関係は設計時に（見ながら）決めるとした場合、
位置がわからないと書き出せないが、それは決めないとしたの
だから、ここでは抜けているけど、決めない。
合計値を表に書くといった場合は、表は想像つくので、これもよしと仮にする
しかし、上記の場合、グラフの出力は、棒グラフ、折れ線グラフの２とおり考えられる
どちらだかわからない。したがって、棒グラフ、折れ線グラフのどちらにするかは
決めるべきである（これがExcelのように瞬時に切り替えられ、表示してみないと
分からないというのであれば、ここで決めなくてもよい）
ここで問題なのは、PDF出力である。
これは、想像はつく。しかし、その技法が分からない場合はありえる。
このように、「出力は分かるが、入力からどのように出力を生成するか技術的に分からない」
ものは、要求仕様とは別に、技術的に調査しておく必要がある。
この部分の調査がないと、あとで話がひっくり返る（仕様変更になる）
■非機能要件は何処まで決めればよいか
「開発者が知っている」非機能要件実現方法の中から、今回、どれを選ぶかを
きめる。前述の【事前準備】により、非機能項目チェックリストで、どれを選べば、
どのように実装すればよいか決まっていることになっている。
したがって、事前に決めた非機能項目チェックリストをチェックすれば良いことになる。
■この結果
機能要件は、出力と、入力データ、利用する関数・演算を決めれば、
（その関数・演算が実現できるものであれば）、
仕様が確定するとすぐにプログラミングできることになるので
ここまで決めてあげればいいことになる。
非機能要件は、事前に決めた非機能項目チェックリストをチェックすれば
プログラミングできることになるので、ここまで決めてあげればいいことになる。
そして、項目が増えても、項目種別が増えない限り、工数が増えないように
クラス化されているとしたら、機能要件で項目が増えても、それに伴って
工数は増えない。
さらに、機能要件が増えても、
出力と、入力データ、利用する関数・演算から
自動的にプログラミングが生成できる場合には
（高速開発）工数は増えない
・・・ベームさんやマコネルさんがいうようにはならないのではないの？
（あれは、
「関数・演算が実現できるかどうか不明」、
「非機能要件のコーディングとテストが、項目増加によって増える」
「そもそも、非機能要件とコードの関係が整理されていない」
という状況で起こるもので、たしかにJQueryのセレクタとCIが出る前はそうだった
けど、今はそうじゃなくなってきてない？）
というのが、きのうの話です
ベームの見積もりの不確実性の図やマコネルの不確実性コーンは、JQueryやREST、ＣＩ時代にも有効か？
http://blog.goo.ne.jp/xmldtp/e/e5a0154e483aaff790d930cbcdd65649
の前に、こっちを書かないといけないんだった。じゃないと意味が通じない・・・
要求分析は、詳細化していくと、どこまでも詳細化できてしまう。
では、どこで止めるべきか？
というお話。
まず、このとき、機能要件と非機能要件で分ける。
１．機能要件で、データの入出力を決める
（GUIの様子とかではなく、項目とその文字種、桁数などまで）
２．非機能要件は、それ以外のUIや、性能などを決める
とする。
そしてこのとき、以下の事前準備が出来ているとする
【事前準備】
・非機能要求に関しては、非機能項目のチェックリストが挙がっていて、
（非機能要求グレードを創造してもらうと良い）
そのチェックリストにチェックを入れると、どのように実現すればいいのか
技術的に分かっている（＝リファレンスモデルがある）
例：GUIの場合、
データの型が決まってしまえば、どのJQueryを使えばよいかが分かり、
どのようなチェックをするかも決まっていて（桁数チェック等）
それがすぐに実装可能になっていること（JSをインクルードして、datatypeを指定すればよい等）
DBアクセス性能の場合
DBアクセスモジュールが容易に作成でき、速度が足りない場合、DBをアップデートしたり、
メモリキャッシュを使ったりするという技術的にどうすればよいかが分かっていて、
それが容易に切り替えられるように、DI等でプログラミングされている
■機能要件は何処まで決めればいよいか
まず、出力の項目を決めないといけない。
そして、出力するプロセスにおいて、何を入力するかを決めないといけない
さらに、入力したものが、「開発者が知っている」関数、演算方法等を利用し、
出力が作成できなければならない
例：月次売上高をPDF出力する
出力項目
・年月 売上高の表
・年月を横軸、売上高を縦軸にしたグラフ
（位置関係は設計時に決めるものとする）
入力項目
売上データ
・年月日日時 バスケットNo 売上金額
とあったとき、入力項目から出力を作成するには
・売上データを年月ごとに合計する
・その合計値を表に書く
・その合計値を元にグラフを書く
・PDF出力する
となる。
このとき、位置関係は設計時に（見ながら）決めるとした場合、
位置がわからないと書き出せないが、それは決めないとしたの
だから、ここでは抜けているけど、決めない。
合計値を表に書くといった場合は、表は想像つくので、これもよしと仮にする
しかし、上記の場合、グラフの出力は、棒グラフ、折れ線グラフの２とおり考えられる
どちらだかわからない。したがって、棒グラフ、折れ線グラフのどちらにするかは
決めるべきである（これがExcelのように瞬時に切り替えられ、表示してみないと
分からないというのであれば、ここで決めなくてもよい）
ここで問題なのは、PDF出力である。
これは、想像はつく。しかし、その技法が分からない場合はありえる。
このように、「出力は分かるが、入力からどのように出力を生成するか技術的に分からない」
ものは、要求仕様とは別に、技術的に調査しておく必要がある。
この部分の調査がないと、あとで話がひっくり返る（仕様変更になる）
■非機能要件は何処まで決めればよいか
「開発者が知っている」非機能要件実現方法の中から、今回、どれを選ぶかを
きめる。前述の【事前準備】により、非機能項目チェックリストで、どれを選べば、
どのように実装すればよいか決まっていることになっている。
したがって、事前に決めた非機能項目チェックリストをチェックすれば良いことになる。
■この結果
機能要件は、出力と、入力データ、利用する関数・演算を決めれば、
（その関数・演算が実現できるものであれば）、
仕様が確定するとすぐにプログラミングできることになるので
ここまで決めてあげればいいことになる。
非機能要件は、事前に決めた非機能項目チェックリストをチェックすれば
プログラミングできることになるので、ここまで決めてあげればいいことになる。
そして、項目が増えても、項目種別が増えない限り、工数が増えないように
クラス化されているとしたら、機能要件で項目が増えても、それに伴って
工数は増えない。
さらに、機能要件が増えても、
出力と、入力データ、利用する関数・演算から
自動的にプログラミングが生成できる場合には
（高速開発）工数は増えない
・・・ベームさんやマコネルさんがいうようにはならないのではないの？
（あれは、
「関数・演算が実現できるかどうか不明」、
「非機能要件のコーディングとテストが、項目増加によって増える」
「そもそも、非機能要件とコードの関係が整理されていない」
という状況で起こるもので、たしかにJQueryのセレクタとCIが出る前はそうだった
けど、今はそうじゃなくなってきてない？）
というのが、きのうの話です