要件定義とは何か — システムに「何を作るか」を決める工程

導入

システム開発で「できあがったものが思っていたのと違う！」という事態を防ぐために欠かせないのが要件定義です。お客様の「こういうものが欲しい」を正確に文書化するこの工程は、開発全体の土台になります。

なぜ重要か

要件定義は、開発プロジェクトの成否を左右する最重要工程といっても過言ではありません。後工程で要件の漏れや誤解が判明するほど、手戻りにかかるコストは指数関数的に膨らんでいきます。テスト工程で「仕様と違う」と発覚した場合、設計から作り直しになることも珍しくありません。

試験の観点からも、要件定義はシステム開発ライフサイクル全体の理解を問う上でキーとなるテーマです。「機能要件と非機能要件の区別」「ヒアリングやユースケースといった手法」が繰り返し出題されています。実務においても、発注者とベンダーの間で「何を作るか」が書面として合意されていなければ、トラブルの原因になります。このように、要件定義の理解はITパスポートの学習範囲を超えた実践的な知識として身につける価値があります。

くわしく知ろう

要件定義とは、開発するシステムが「何をすべきか」をユーザーやステークホルダー（利害関係者）と合意し、文書として明確にする工程を指します。システム開発ライフサイクルの中でも最も上流に位置し、ここでの決定が後工程の設計・開発・テストに大きく影響します。

要件は大きく2種類に分けられます。機能要件とは「システムが実現すべき具体的な機能」のことで、たとえば「商品の検索ができる」「注文履歴を確認できる」といった内容が該当します。一方、非機能要件とは「性能・信頼性・セキュリティ・操作性」など機能以外の品質特性を指し、「1秒以内に検索結果を返す」「99.9%の稼働率を確保する」などが例として挙げられます。

要件定義でよく使われる手法として、ヒアリングとユースケースがあります。ヒアリングはユーザーにインタビューや質問票で要望を聞き取る手法で、潜在的なニーズを引き出す点で重要です。ユースケースは「誰が（アクター）・何をする（ユースケース）」という形式でシステムの使い方を整理したもので、要件の漏れを防ぐのに役立てられています。

この工程の成果物として要件定義書が作成され、以降の設計・開発フェーズの基準になります。

具体例で理解する

通販サイトを新規開発する場合、「商品を検索して購入できる（機能要件）」「スマートフォンでも快適に操作できる（非機能要件）」といった要件を、担当者へのヒアリングやユースケース図を使って整理します。この文書なしに開発を始めると、完成後に大幅な手戻りが発生することになります。

試験での出題パターン

【パターン1：機能要件か非機能要件かを選ぶ問題】

最も頻出のパターンで、「次の記述のうち非機能要件にあたるものはどれか」という形式で出題されます。「ユーザーがパスワードを変更できる」は機能要件、「システムの可用性は99.9%以上とする」は非機能要件、という判断を素早くできるように練習しておくと得点につながります。キーワードとして、性能・可用性・信頼性・セキュリティ・保守性が出てきたら非機能要件と結びつけるのがコツです。

【パターン2：要件定義の目的・位置づけを問う問題】

「システム開発工程のうち、最上流に位置する工程はどれか」「要件定義書の役割はどれか」という形式です。要件定義はシステム開発ライフサイクルの中で最も早い段階で実施され、後続の設計・実装・テスト工程すべての基準になるという点を押さえておきましょう。

よくある間違い・紛らわしいポイント

【機能要件と非機能要件の混同】

「セキュリティ対策を施す」という記述は一見すると非機能要件のように見えますが、「不正ログインをブロックする機能を実装する」という具体的な機能の話になれば機能要件になります。「何をするか（機能）」ではなく「どれくらいの水準で動作するか（品質）」という視点の違いで判断するとよいでしょう。

【ヒアリングとユースケースの目的の混同】

ヒアリングはユーザーから要望を聞き取る手法であり、ユースケースはその情報を「誰が・何をする」という形式で整理して漏れを防ぐ手法です。ヒアリングで集めた要求をユースケースとして図式化することで、システムの全体像を関係者と共有しやすくなります。2つは別の目的を持つ手法であり、対立するものではなく補完し合う関係にあります。

【要件定義書と仕様書の違い】

要件定義書は「何を作るか（What）」をまとめた文書で、システム仕様書は「どのように作るか（How）」を詳細化した文書です。試験では「発注者が求める機能をまとめた文書」と説明されれば要件定義書を指しています。

まとめ・試験ポイント

• 要件定義＝システムが「何をすべきか」をユーザーと合意し文書化する工程
• 機能要件＝システムが実現すべき具体的な機能（検索・注文など）
• 非機能要件＝性能・信頼性・セキュリティなど品質特性（可用性・保守性も含む）
• ユースケース＝「誰が・何をする」形式でシステムの使い方を整理
• 要件定義書が後工程（設計・開発・テスト）の基準となる
• 試験では機能要件と非機能要件の区別を問う問題が頻出