要件定義
どこからどこまでを要件定義とするか、はプロジェクトによって異なる
要件定義のモチベーション
これを知らないと「要件定義が必要だから要件定義をする」になってしまうmrsekut.icon
「要件」を定義したい
開発の目的を明確にする
開発のゴールを明確にする
どこまで作れば「完成」なのか、完成の定義を決める
完成してからコレジャナイになるのを避ける
相互の期待値のコントロールをする
注文する側と、作る側の認識を合わせる
口頭の抽象的な議論を進めると無駄に期待が膨らむ可能性がある
高速でアニメーション盛り盛りのアプリケーションをイメージしている可能性がある
スケジュールなども加味して、この機能は含めません、などの判断を行う
流れ
要件定義を行う
人、モノ、金などの制限
これらの制限を加味して、理想のモデルの実現可能性を検討する
実現可能性が低い場合は、以下を修正して更新する
提案
要求の検討の結果を注文者に伝える
代替案の提案
NGである理由を伝える
どうやって移行するかを考える
対象とするスコープを確定させる
機能一覧、非機能一覧を作る
要件定義に含める項目の例
システム化の目的
システムの概要
その経緯、理由
システムの構成図
業務フロー
ユースケース図
機能一覧、機能の詳細
入出力要件
入力データ一覧、詳細
出力データ一覧、詳細
e.g. 帳票、UI
セキュリティ要件
品質・性能要求
導入・移行計画
スケジュール
ステークホルダー関係図
人員の体制
要件定義はWhat
要件定義のゴールは
「設計プロセスを円滑に進めるための
明確で具体的なインプット
を提供すること」
要件定義書って誰が読むん？
非エンジニア？エンジニア？
それによって前提をどこまで説明するかが大きく変わる
作る手順
例えば、最初に業務フローを書いて、全体感を掴んだ後に詳細に進めるとか
例えば、明日から実装を始めよう！となった時に、
ここの仕様決まってないじゃん！になるのを避けるようにイメージするとか
要件定義に時間を掛けすぎても仕方がない
どこかで線を引いて、そこまでにできる要件定義をしてしまい、
その後は、基本設計などを進めていく中で、詳細な要件定義をする
要件定義とはこういうもので、
後から変更すると大変なんだよ、ということを
ちゃんとユーザーと共有しておく必要がある
要件定義の段階で
要件化できなかった要求がある場合は、どういう制約があったのかを明確にする
よくある制約の例 ref 『要件定義のセオリー』.icon p.105
人: 技術者がいないなど
モノ: インフラ、環境、ツールが用意できないなど
金
時間
技術的困難
技術的制約
現状との乖離
用語を定める
表記ゆれしないように
導出項目を明記する
税額 = 金額 * 消費税のような値を扱う時、UI上では、税額と金額は現れるが、消費税は現れない
ここで要件定義時に、消費税の存在をちゃんと明記しておく必要がある
UIとしてのエラーメッセージ
異常系もちゃんと定義する
UI → 機能 → データの順に考える
画面遷移図を書く
画面内の表示項目、入力、操作
どういうイベントによって別の画面に遷移するのか
機能
出力、処理
でーた
ER図
ワークセットを階層構造にして表現すると良いかも？
定義すべき要件の内容
ソフトウェアを完成するために必要な情報
UI, 機能、データ
企画書
全体像
利用ttする実装技術(要求一覧)
実現したいこと一覧
行動シナリオ
概念データモデル
ラフイメージ、モックアップ
画面遷移図
項目の説明
機能の入出力定義
機能の処理定義
統合ERD
why→what→howの順序で設計書には書くと理解しやすい
要件定義より前に行うこと
企画
要求の一覧化と整理
全体像を描く
ユーザーの種類
ステークホルダー
各ユーザーが新システムとどういう関わり方をするか
を俯瞰したもの
連携するシステムも書いておく
連携先のシステム側の修正も必要になるかもしれない
どういうデータをやり取りするかも書いておく
システム内のモジュール同士の関係なども書いておく
実行する順序(フロー)がある場合、それも考慮する
雑なER図を書く
詳細なものは要件定義内で行う