要求仕様「書」を、どこまで「書くか」？（実際、要求仕様書はどこで止めとくか）

さっきの


要求仕様は、どこまで書くべきなのか？（要求分析は、どこまで詳細化するべきか）
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まで
有る程度書いてくれる。。。けど、デザイナーによってくせがあるので、
どういう風に書くな・・・だから、こう仕様を切ろうという目安をつけるためにも
テンプレート作成までしてしまうと安心だけど、
これは、お金のかなる話（デザイナー代）なので、この段階で踏み切れるかどうかは
疑問だったりする・・・

要求仕様は、どこまで書くべきなのか？（要求分析は、どこまで詳細化するべきか）

しまった！昨日の


ベームの見積もりの不確実性の図やマコネルの不確実性コーンは、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が出る前はそうだった
　けど、今はそうじゃなくなってきてない？）

　というのが、きのうの話です