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