前書き
どうも仕事で要件定義に近いことをすることになりそうなので、
お勉強がてらメモを取っていく。
誤りがあれば是非指摘して頂きたい。
以下参考文献
https://www.amazon.co.jp/gp/product/B00WHUP7UE/ref=ppx_yo_dt_b_d_asin_title_o05?ie=UTF8&psc=1
要件定義とは
要件定義＝発注側と受注側の間で合意された納品条件
噛み砕いて書くと
発注側が依頼を行い、それを受注側が判断し再提案などを行い、お互いに納得の出来る成果物を定めることを要件定義としている。
発注側が依頼を行うだけでは無いのは、様々な理由から不可能なことや代替え手段を提案したほうが良いことがある場合、
受注側からの提案により依頼内容からの変更があるため、このようになっている。
要件定義を行うプロセスとして
- 発注側に要望を出して頂く。
- 受注側が要望を検討する。
- 受注側が検討した内容を発注側に伝える。
- 発注側が伝えられた内容を検討する。
- 1~4を繰り返す。
- 検討しつくされた段階で、合意形成となる。
定義するべき要件
プログラミングを実際に行うために必要となる物を定義していくことが必要となる。
・UI
・機能
・データ
UIは画面と帳票を指す。
機能はViewを除いた大まかな機能一覧になる。
（ボタンを押したら印刷される等UIに結び付いた機能や定期的に実行されるbatのような機能もここに該当する）
データはそのままデータを指す。
例えばECサイトだと商品データとか売り上げデータとかその他もろもろ。
定義すべき要件の詳細の詰め方
準備
厳密には要件定義ではないが、要件定義を行うためには以下のものが無いと進まない上に、実際には無いこともあるらしいのでまとめる。
企画書を作る。
企画書と呼ばれるものが必要になる。
企画書には以下の物が記載されているのが望ましい。
・プロジェクト名称（例：A倉庫の在庫管理プロジェクト）
・プロジェクトの目的（例：現状、Excelで管理している在庫管理を効率的かつミスのないような物にしたい）
・目的達成のための成果物（例：JANによる在庫登録機能、在庫管理機能）
・作る物の説明（例：思いつかなかった）
・成果物を使用する人（例：倉庫内作業員、事務員）
・利用する人が得られる便益（例：効率的かつミスのない作業になるため、時間コストの削減になる）
・作るための体制（例：思いつかなかった）
・期限（例：12ヶ月～18ヶ月）
全体図を描く。
ユースケース図とシステム連携図と内部連携を一つにして水で薄めた様な図を書く。
詳細を埋めれば埋めるほど良いと思うけど、同じ図にするんじゃなくてある程度分けたほうが良い気がする。
本全部読んだけど要件定義の仕事が流れたので供養になった。