さっきの
要求仕様は、どこまで書くべきなのか？（要求分析は、どこまで詳細化するべきか）
http://blog.goo.ne.jp/xmldtp/e/9760b1dd3f3eb3b0bdd676118ad388b8
なんだけど、結論が
機能要件は、出力と、入力データ、利用する関数・演算を決める
非機能要件は、事前に決めた非機能項目チェックリストをチェックする
となっていた。
でも、実は、要求仕様書をここまで決めて書くことは、
無いとは言わないが少ない。
実際には、「機能要件の合意形成ガイド」にあるように、機能要件は、外部設計完了時までに完了していれば良い。だから、上述の例でも、グラフと表の位置は、「見てから決める」ということにして、決めていない。
では、要求仕様書はどこまで決めておけばいいのか・・・
ということだけど・・・
「設計者が困らない程度」
に書いておき、要求仕様書が書き終わった段階で
「技術的に実現方法がわからない関数がない」
状態にしないといけない。
たとえば、位置を決めるというのは、設計者がどうすればいいかわかる。
（あとでレイアウト図を出して、このへん？このくらい？とユーザーさんに聞けばよい）
これは、先に延ばしてOK
しかし、グラフの場合で、棒グラフをグラデーションしたいなんていうとき、
技術的に出来るかどうかは、確認しないと分からない
（ライブラリを使う場合、Excelでグラフ表示しようとすると、
グラデーションのライブラリが利かない可能性あり）
こういう部分は、要求仕様書が書き終わる前に、確認しておくべきこと。
PDFへの出力方法も同様。
具体的には、
出力は、出力する「もの」の名前（帳票名、PDFファイル名、画面名など）と、
これを出力しないと意味が無いというくらい大事な項目、
テーブルでは、テーブル名と
主キー（自テーブル、他テーブル（外部キーになる））
入力データは、上記の出力データが出力できることを
確認できる程度
は必要。それ以上は、書かなくてもゆるされるかもしれない
非機能は、なんかしないといけない機能について述べる
けど、チェックしたんなら、全部出したほうがいい
なお、入出力に関しては、全体テンプレートがあるのなら、
全体テンプレートの内容を要求仕様書に書くかどうかは別として、
要求仕様書完成前までに出来ていると安心できる。
さらに、１～２個の画面例を作っておくとリスクは軽減する。
このほかの入出力（PDFなど）も、１～２個の例を作っておくとリスクは激減する。
実際の工数超過は、項目が１、２項目追加されたというより、
そのような表示は無理！ということによる仕様変更のほうが大きい。
たとえば、JQuery Mobileを利用して、AJAX+SPAを実現しようとしたとき、
AJAXを使って画面を書き換えようとしたら、画面リドローが起こらず、
画面が書き換わらないとか
IEで、位置を合わせようとしたら、X,Y座標を送っても、
その後位置合わせロジックが動いて、指定したところに
フォーム部品が動かない
などによる仕様変更のほうが、項目を１０個足すなどというより、
仕様変更度合いが大きい。
（前者は、SPAから、画面切り替えにプログラムを変えることになるし、
後者は、setTimeoutで30ミリ秒後くらいに実行させるとうまくいくことあり）
このような危ない橋を渡らない為には、画面サンプル（一番難しそうな）を
作ってしまうことである。
なので、１～２個の例を作っておくとリスクは軽減する。
特に、デザイナーに画面周りデザインを頼む場合、いまだと、Javascriptまで
有る程度書いてくれる。。。けど、デザイナーによってくせがあるので、
どういう風に書くな・・・だから、こう仕様を切ろうという目安をつけるためにも
テンプレート作成までしてしまうと安心だけど、
これは、お金のかなる話（デザイナー代）なので、この段階で踏み切れるかどうかは
疑問だったりする・・・
要求仕様は、どこまで書くべきなのか？（要求分析は、どこまで詳細化するべきか）
http://blog.goo.ne.jp/xmldtp/e/9760b1dd3f3eb3b0bdd676118ad388b8
なんだけど、結論が
機能要件は、出力と、入力データ、利用する関数・演算を決める
非機能要件は、事前に決めた非機能項目チェックリストをチェックする
となっていた。
でも、実は、要求仕様書をここまで決めて書くことは、
無いとは言わないが少ない。
実際には、「機能要件の合意形成ガイド」にあるように、機能要件は、外部設計完了時までに完了していれば良い。だから、上述の例でも、グラフと表の位置は、「見てから決める」ということにして、決めていない。
では、要求仕様書はどこまで決めておけばいいのか・・・
ということだけど・・・
「設計者が困らない程度」
に書いておき、要求仕様書が書き終わった段階で
「技術的に実現方法がわからない関数がない」
状態にしないといけない。
たとえば、位置を決めるというのは、設計者がどうすればいいかわかる。
（あとでレイアウト図を出して、このへん？このくらい？とユーザーさんに聞けばよい）
これは、先に延ばしてOK
しかし、グラフの場合で、棒グラフをグラデーションしたいなんていうとき、
技術的に出来るかどうかは、確認しないと分からない
（ライブラリを使う場合、Excelでグラフ表示しようとすると、
グラデーションのライブラリが利かない可能性あり）
こういう部分は、要求仕様書が書き終わる前に、確認しておくべきこと。
PDFへの出力方法も同様。
具体的には、
出力は、出力する「もの」の名前（帳票名、PDFファイル名、画面名など）と、
これを出力しないと意味が無いというくらい大事な項目、
テーブルでは、テーブル名と
主キー（自テーブル、他テーブル（外部キーになる））
入力データは、上記の出力データが出力できることを
確認できる程度
は必要。それ以上は、書かなくてもゆるされるかもしれない
非機能は、なんかしないといけない機能について述べる
けど、チェックしたんなら、全部出したほうがいい
なお、入出力に関しては、全体テンプレートがあるのなら、
全体テンプレートの内容を要求仕様書に書くかどうかは別として、
要求仕様書完成前までに出来ていると安心できる。
さらに、１～２個の画面例を作っておくとリスクは軽減する。
このほかの入出力（PDFなど）も、１～２個の例を作っておくとリスクは激減する。
実際の工数超過は、項目が１、２項目追加されたというより、
そのような表示は無理！ということによる仕様変更のほうが大きい。
たとえば、JQuery Mobileを利用して、AJAX+SPAを実現しようとしたとき、
AJAXを使って画面を書き換えようとしたら、画面リドローが起こらず、
画面が書き換わらないとか
IEで、位置を合わせようとしたら、X,Y座標を送っても、
その後位置合わせロジックが動いて、指定したところに
フォーム部品が動かない
などによる仕様変更のほうが、項目を１０個足すなどというより、
仕様変更度合いが大きい。
（前者は、SPAから、画面切り替えにプログラムを変えることになるし、
後者は、setTimeoutで30ミリ秒後くらいに実行させるとうまくいくことあり）
このような危ない橋を渡らない為には、画面サンプル（一番難しそうな）を
作ってしまうことである。
なので、１～２個の例を作っておくとリスクは軽減する。
特に、デザイナーに画面周りデザインを頼む場合、いまだと、Javascriptまで
有る程度書いてくれる。。。けど、デザイナーによってくせがあるので、
どういう風に書くな・・・だから、こう仕様を切ろうという目安をつけるためにも
テンプレート作成までしてしまうと安心だけど、
これは、お金のかなる話（デザイナー代）なので、この段階で踏み切れるかどうかは
疑問だったりする・・・