【システム開発・要件定義】良い要件定義書を作る必須条件！「要求の持つべき8つの性質」｜情報処理問題1000本ノック

基本情報技術者試験、応用情報技術者試験、システムアーキテクト試験の「要件定義・ソフトウェア工学」分野で非常に重視される知識です。ユーザーやシステムが満たすべき「要求（Requirement）」が、手戻りなく正しく開発現場へ伝わるために備えておくべき『8つの高品質な性質』を整理して攻略しましょう。

■ 要求の持つべき8つの性質

国際標準規格（IEEE 830やISO/IEC/IEEE 29148など）でも定義されている、優れた要求（要件定義書）に求められる8つの属性と特徴です。

要求の性質	定義と説明	満たしていない場合のリスク
1. 明確性 (Unambiguous)	誰が読んでもたった1つの意味・解釈にしか受け取れない状態。曖昧な表現（「素早く」「適切に」など）を排除している。	発注者と開発者で捉え方がズレて、意図と異なるシステムが作られる。
2. 正確性 (Correct)	ユーザーや事業が本当に必要としている目的・事実・仕様を正しく記述している状態。事実誤認や嘘がないこと。	不要な機能を実装したり、業務ルールと反するシステムになってしまう。
3. 一貫性 (Consistent)	他の要求事項と矛盾・衝突していない状態。用語の使い方や条件指定が全体で統一されていること。	「A画面では必須だがB画面では任意」など設計上の混乱や不具合が発生する。
4. 完全性 / 完全性（完結性） (Complete)	必要な機能・条件・制約・例外処理（抜け漏れのない状態）が網羅・完結して書かれている状態。未定事項（TBD）が残っていないこと。	開発の終盤で考慮漏れが発覚し、大幅な手戻りや納期遅延が発生する。
5. 修正できること (Modifiable)	仕様変更があった際、構造的に容易かつ正確に修正・追記ができる状態。目次や見出し、冗長な重複記述のない整理された構成のこと。	1箇所の変更で修正漏れが発生し、仕様書の記述がバラバラになる。
6. 検証できること (Verifiable)	完成したシステムがその要求を満たしているか、テスト（客観的な数値や手順）によって合否判定・テスト確認ができる状態。	「使いやすいこと」など漠然としすぎて受け入れテスト（検収）が判定できない。
7. 優先付けできること (Ranked for Importance)	予算やスケジュールの制約に応じて、各要求に重要度や緊急度の順位（優先度）が設定されている状態。	コストや納期が厳しくなった際、どの機能を削ればよいか判断できない。
8. 追跡できること (Traceable)	要求ごとに一意のIDが付与されており、その後の設計・プログラム・テスト項目との対応関係を前後双方向に追跡（トレーサビリティ確保）できる状態。	要求がどのプログラムやテストケースに対応しているか分からなくなる。

試験対策の重要キーワード

• トレーサビリティ（追跡可能性）：「8. 追跡できること」の技術的裏付けです。要求IDと設計書・テスト項目を対応付けることで、仕様変更時の影響範囲特定やテスト漏れを防止します。
• スマート（SMART）の法則：要求の「検証可能性（数値化）」を設定する際のフレームワーク（Specific, Measurable, Achievable, Relevant, Time-bound）としてもよく対比されます。
• 非機能要件の明確化：「処理速度は早いこと」ではなく「応答時間は2秒以内（95パーセンタイル）」のように定量数値で記述することが「明確性」「検証可能性」を高めるポイントです。

※要求の性質は「料理のレシピ」で考えると理解しやすくなります。「美味しく作る（曖昧）」ではなく「塩を3g入れる（明確・検証可能）」、「手順が1行目と5行目で矛盾しない（一貫性）」、「材料の重要順（優先付け）」のように、誰が作っても同じ味を再現できるレシピを目指すのが要件定義の本質です。