#今回読んだ本
はじめよう！ 要件定義 ～ビギナーからベテランまで
#「要件定義」とは
そもそも「要件定義」とはなにか。
前提部分から考え直してみると、「要件定義」に対する考え方が少しずつ明確になっていく。
##「要件」とは
「注文(オーダー)」と考えるとわかりやすい。
つまり、「作って欲しい人が、作る人に出す、依頼事項(リクエスト)」。
##それを踏まえると...
「依頼事項を明確に定める(定義する)」ことこそが、「要件定義」。
##なぜ要件定義をするのか
納品するためには、「作ってほしい人と作る人の間に合意事項を形成する必要」があるから。
(これがずれていると、トラブルになる可能性も)
#「要件」を整理するために...
##「要望」と「要求」
「こんなことがしたい」「こんなことができたら」という思いこそが「要望」。
その要望を言葉にしたものが「要求」。
##「要求」を検討する
出来るか出来ないかという「可否判断」。
その判断だけでなく、「代替案」も検討する。
###「代替案」
「不可能の場合に提案するもの」というイメージがあるが、「更に良い方法がある」ときに出すものでもある。
#「要件定義」を行う、その前に
##「企画」を確認する
作るからには、そこには何かしらの「企画意図」がある。
その意図から外れないようなソフトウェアを作らないといけない。
##「全体像」を描く
「システム」を中心に、「利用者」を配置した図を書く。
利用者それぞれに、「そのソフトウェアを使って行うこと」を書く。
そうすることで、「システム」の利用者と利用意図の概略を整理できる。
##利用者の「行動シナリオ」
いわゆる「業務フロー」を整理することで、以下の内容を明確にする。
- 「ソフトウェアを利用するタイミング」
- 「ソフトウェアを利用する理由」
- 「ソフトウェアを利用することで具体的に達成する仕事」
###データのINPUTとOUTPUT
システムの利用箇所も踏まえた「行動シナリオ」を整理する際には、
データのINPUTとOUTPUTが必ず明確になるように検討する。
またデータの受け渡しだけでなく、その「保管場所」を意識することも必要。
#実際の要件定義
##「UI」を考える
###UIを構成する要素
以下の3つの要素で構成される。
- データ項目
- 操作項目
- レイアウト
###画面のラフイメージを描く
ラフイメージを描くことで...
- 「データ項目」(値の表示項目や、入力項目)を設計できる
- 「操作項目」(ボタンなど、操作するもの)を設計できる
###「導線(画面遷移)」を考える
レイアウトと画面遷移のイメージができたら、そこに「イベントトリガー」を書く。
この「イベントトリガー」とは、「ボタンを押す」などの「ユーザの操作」を指す。
##「機能」を考える
###画面遷移図から機能を洗い出す
- 「出力」を決める
- 遷移先画面を考えて、渡すべき「出力」を考える
- すなわちソフトウェアの「成果物」
- 「入力」を決める
- 遷移元画面を元に「入力」を考える
#個人的なポイント
##ドキュメントを書くことの重要さ
作り込まなくてもよいので、何かしらドキュメント化して整理することが必要だと感じた。
(頭の中で整理するのは限界がある。アウトプットした方が整理しやすい。)
特に「画面遷移図」。
設計するうえで、ラフで良いので作った方が「システムの処理の流れ」や「ユーザの操作の流れ」が明確になる。
#参考URL
Part1 今こそ「基本設計」のスキルを見直す