要件定義とは
要件定義とは・・・
「要求定義書を実現するためには、こうした機能・こういう性能が必要ですよ」という情報がまとめられたシステムの仕様定義。
システムが何をしなければならないのかを、プログラムの機能の他、DB・通信などを含めて、明確にしたもの。これが、後工程の基本設計(外部設計)の基となっていく。
システム開発の中での位置付け
１つのシステムが生み出されるまで
一般的なシステム創出のフロー
要求と要件の違い
システム開発における「要求」と「要件」の違いは、例えばこんな感じ。
要件定義書とは
文字通り、要求定義をドキュメントにしたもの。
厳密に決まったフォームはないが、要件定義によく盛り込まれるのは以下のような内容
- システムの概要と構想
- 現状把握と導入後の業務フロー
- システム要件
- 機能要件
- 入力要件と出力要件（インターフェース）
- 品質・性能・セキュリティ要件
要件定義の内容①：システムの概要と構想
欲しいシステムの全体像と実現方法をまとめる
●背景と目的：なぜ、システムを導入したいのか？現状抱えている課題は問題は何か？
●スコープ：今回実現したい内容は、どの部分までシステム化するのか？その範囲。
●スケジュール：システムのリリース時期、設計期間や実装・テスト期間について。
●体制図：開発チーム体制。PM, PL, SEメンバーにどんな人を何人あてがうのか。
規模が大きければ、機能や担当範囲によってチームを分けることも当然ある。
●費用：今回のシステム実現・運用・保守にかかるお金はいくらか？
開発時に、モノにかかる費用、人材にかかる費用など開発期間のイニシャルコストだけでなく、リリース後に運用していく上でのランニングコストなども考慮される。
要件定義の内容②：現状把握と導入後の業務フロー
現状と将来像を示す
●全くの新規システムを開発する場合：
現在の業務フローがどうなっているのか、新規システムを導入することでその業務はどう変化し、業務フローはどうなるのかを示す。
●既存システムを新システムに置き換える場合：
業務フローの変化に加え、現在のシステムが抱える問題・課題も踏まえた上での技術的な変更点を示す。
いずれも、AsIs/ToBeモデルなどの比較表現を使用し、今と未来の差をわかりやすく示す。
そのための役割分担（どんな体制で開発などを行なっていくのか）なども明示する。
要件定義の内容③：システム要件
システム要件の内訳
この項目では、以下のような内容をまとめる。
- 関連する他システムとの関係
- ネットワーク構成
- ハードウェア構成
- ソフトウェア構成
- 使用する言語、OS、DBMS、ミドルウェアのバージョン等
要件定義の内容④：機能要件
機能要件とは、必ず搭載すべき機能
ユーザー・クライアントから求められている機能。基本的な「何ができるのか」の部分。
システムとして満たされていることが絶対に必要なコア部分であり「搭載されていなければ困る」もの。
すなわち、これらの機能が搭載されていることは “当たり前” という前提になるので、満たされていても顧客満足度が大きく高まることは期待できない。
顧客満足度に直結するのは、後述する「品質」「性能」「セキュリティ」と言った、非機能要件の部分であることがほとんど。
要件定義の内容⑤：入力要件と出力要件
入力要件と出力要件（インターフェース）
この項目では、以下のような内容をまとめる。
- システム間 インターフェース
→ 物理層も含めたプロトコル（ネットワークの物理的接続や伝送方式）, 文字コードなど
- 接続端末 インターフェース
→ 通信プロトコル（TCP/IP, HTTP など、物理的ではない領域の通信方式）
- マンマシン インターフェース（ヒューマン インターフェース）
→ システムの中で、人間が見て触る部分の扱い。画面や帳票の方針・一覧など
要件定義の内容⑥：品質・性能・セキュリティ要件
システムのパフォーマンスに対する要件
24時間365日止まらないようにしたいのか？ 従業員1,000人のアクセスに耐えて欲しいのか？
など、システムを実際に利用する環境に耐えられるように、「これくらいの環境でも大丈夫にして欲しい」といった様なことがまとめられる部分です。
機能要件よりも、顧客満足度に大きく影響します。
- 処理能力、データ量
- ユーザビリティ
- 信頼性、冗長性能・保守性、改修のしやすさ
まとめ
●要件定義とは「要求の実現方法」の定義である
ここから、後工程である設計やテストの基となる情報が作り上げられていく。
●要件定義には概要などの他に、機能要件と非機能要件がある
機能要件は必達事項のため満足度はあまり高まらず、非機能要件は満足度を高めやすい。
●要件が本当に正しいかはテストまでわからない
様々な手法やノウハウ・知識や経験値などによって、できる限り「正しい要件」が作り上げられるが、本当にその要件で良かったのかは、設計や実装を終え、テストの工程が進んで評価することで明らかになっていくものである。そのリスクの存在も、頭の片隅にとどめておくとよい。
※最新の情報の取得・更新に努めておりますが、掲載内容については、その正確性、完全性、有用性、最新性等についていかなる保証もするものではありません。