• 定義: プロジェクトやシステムに直接的または間接的に影響を受ける、あるいは影響を与える個人・組織・グループのこと。
• 同義語: 利害関係者
• 説明:
  • 顧客、エンドユーザー、経営層、開発チーム、保守担当者、外部連携先システム担当者など、システムに関わるすべての関係者を含む。
  • 各ステークホルダーは異なる視点や要望を持ち、それらを調整・合意形成することが要件定義の重要な活動となる。
• 例: 経理部門(利用者)、IT部門(管理者)、経営層(意思決定者)、保守ベンダー(運用担当者)

• 定義: プロジェクトに対して資金提供や意思決定の権限を持ち、プロジェクトの成功に責任を負う個人または組織のこと。
• 同義語: プロジェクトオーナー、発注者、出資者、顧客側責任者
• 説明:
  • プロジェクトの立ち上げを決定し、予算を承認し、最終的な成果物を受け入れる権限を持つ。
  • 通常は顧客側の経営層や事業責任者がスポンサーとなり、プロジェクト目的を定義する立場にある。
• 例: 経営企画部長(プロジェクト発起人)、情報システム部門長(予算承認者)、事業部門責任者(成果物受入者)

• 定義: そのプロジェクトの最高責任者・スポンサー(通常は、顧客側の経営層)が最終的に達成したい目標や立ち上げの意図。
• 例: グローバルな製品在庫を最適化し、在庫切れをなくし、受注機会の損失を削減する。

• 定義: 設計・実装または開発プロセスに対して選択肢を制限する、プロジェクト外部からの強制的かつ変更困難で、クリアしなければならない条件のこと。
• 説明:
  • 設計や実装、開発プロセスに対して外部から課される制限であり、しばしば設計選択肢を制限する=設計の自由度を制約する。
• 例: 法規制を遵守すること、〇百万以内に開発費が収まること、開発言語は Java に限定する

• 定義: 計画や要件、仕様を定める上で、仮に置く条件。証拠や実証なしに確実であると「仮定」して進める条件のこと。
• 説明:通常は後で検証し、誤りがあればリスク対応または計画修正が求められる。
• 例: 業務部門が毎週レビューに参加できる、利用者数は最大1,000人を想定する、既存DBは現行のスキーマのまま利用可能である

• 定義: 設計・実装・テスト可能にするために、完全・正確・検証可能 (complete, correct, verifiable)な形に表現した文書や、その内容を指す。
• 略語: Spec
• 同義語: 仕様書
• 説明:
  • ISO/IEC/IEEE 29148:2018(要求工学)では、要件 (requirements) を「完全・正確・検証可能 (complete, correct, verifiable)」に記述する文書として定義される。
• 例: ユーザーIDとパスワードを入力すると認証処理を行い、成功時はダッシュボード画面を表示する

• 定義: ステークホルダー間の「認識・方向性の一致した状態」を指す。
• 同義語: コンセンサス
• 説明:
  • 全員が完全に賛成していなくても、主要メンバーが「これで進めることに納得した」状態。
  • 形式的な承認を得ない、心理的な合意によって、「認識のずれによる炎上」を防ぐ。
  • 後の承認と正式な合意の前提になる。
• 例: 利用部門、IT部門、開発側が要件の優先順位や実現方針について合意している。

• 定義: 特定の成果物や文書を、責任者や承認権限者が公式に「正式なものとして認める」行為。
• 説明:
  • 「この文書の内容で進めることを許可する」という意思表示の形式。通常は署名・電子承認・ワークフローなどの公式手段を伴う。
  • 合意を正式な合意として確定させ、正当性を与える手続き。
• 例: 顧客担当者が署名することで、正式な合意文書として承認される。

• 定義: 主に形式的・契約的な「合意」を指す。ある内容が合意に達した上で、承認によってそれが確定された状態。
• 同義語: 公式合意、契約的合意、アグリーメント
• 説明:
  • 書面や公式な承認を伴い、変更管理の起点になる状態。
  • 「承認」が責任者が正当性を与える行為であるのに対し、「正式な合意」は、複数の関係者が調整等によって達した合意が承認によって正式なものであると確定した状態である。
• 例: 要件定義書に顧客とベンダーが署名・押印することで、正式な合意とみなす。

• 定義: ステークホルダー(利害関係者)が抱く、漠然とした期待や希望のこと。
• 同義語: ステークホルダーニーズ、ニーズ
• 説明:
  • 必ずしも整理されておらず、具体性・実現性が不明確。
  • 背景にある問題意識や状況によって、要望に強弱がある。
  • プロジェクト目的をブレイクダウンしたとき、問題を解決する方法はいろいろ考えられるが、それをさらに絞り込むための「ステークホルダーの要望」を指す。
• 例: 経理部は業務をもっと効率化したい、営業部は顧客満足度を高めたい、経営陣はできるだけ安く済ませたい

• 定義: ステークホルダーの要望の背景にある、現状の困りごとや障害となっている事象のこと。
• 説明:
  • 「望ましい状態」と「現実の状態」とのギャップそのものを指す。
  • 問題を正しく特定・分析することで、解決すべき課題を明確化できる。
  • 「課題」は問題を解決するために取り組むと決定された具体的な目標であり、「問題」はその前提となる現状の困りごとを指す。
• 例: 在庫情報の更新が遅れて欠品が発生している、手作業での入力ミスが多発している、システム間でデータ連携ができていない

• 定義: 組織やシステムが目的を達成するために行う一連の活動や処理のこと。
• 説明:
  • 人・プロセス・ルール・情報・システムなどで構成され、価値を生み出す活動全体を指す。
  • システム開発では、現行業務(AsIs)を分析し、あるべき姿(ToBe)を定義する。
• 例: 受注業務、在庫管理業務、顧客対応業務、経理業務

• 定義: 業務上の問題を解決するために、組織が取り組むと決定した具体的な改善目標のこと。
• 説明:
  • 「問題」が現状の困りごとを指すのに対し、「業務課題」はそれを解決するために設定された目標や取り組み事項。
  • 業務課題は業務要件の前提となり、システム化の必要性を判断する材料となる。
• 例: 在庫情報の更新遅延を解消する、入力ミスを削減する、システム間データ連携を実現する

• 定義: システムまたは業務が満たすべき必要条件のこと。
• 説明:
  • 「何を実現するか」を明確にしたもので、「どのように実現するか」(設計)とは区別される。
  • 要件には業務要件とシステム化要件があり、それぞれ異なるレベルの具体性を持つ。
• 例: ユーザーは外出先からスマートフォンで在庫情報を確認できる、システムは99.9%以上の稼働率を維持する

• 定義: プロジェクト目的を達成するための、業務運用レベルの要件。
• 説明: 通常は、複数の業務要件が、プロジェクト目的からブレイクダウンされる。また、業務要件は、複数のシステム化要件にブレイクダウンされる。
• 例: 営業担当者は外出先から顧客情報を登録できる、グローバルな在庫の状態をリアルタイムに把握できる

• 定義: 業務要件を達成するために実現すべき新しい業務の形=ToBe(業務フロー、業務ルールなど)また、ToBeを実現するために、システムが満たすべき能力、特性、性質などの必要条件=システム要件、およびシステム化に付随する業務変更と、移行計画を明確化したもの。
• 説明:
  • システム化要件は、機能要件(Functional Requirement) と、非機能要件(Non-Functional Requirement) を持つ。
  • システム要件には、業務要件から直接導かれない「あたりまえ品質」が存在する。例えば暗号化通信の規格などは、顧客から要望がなくとも達成されていることが「あたりまえ」とされる。
• 例: 営業担当者は外出先から新システムで在庫状況を閲覧できる、各倉庫の入出庫情報をリアルタイムに1つのシステムに集約する、TLS2.0 で暗号化通信を行う

• 定義: システム化要件を実現するための、システムの構造・仕組み・方式を技術的に具体化したもの。
• 説明: 「何を実現するか」を定めた要件に対し、「どのように実現するか」を明確にする活動。基本設計と詳細設計に分けられることが多い。
• 例: 顧客情報はRDBMSで管理する、認証機能はOAuth2.0で実装する、画面はReactで構築する

• 定義: ユーザーや外部システムから見た、システムの振る舞いや入出力の仕様のこと。
• 説明:
  • 基本設計対象の一部。システムの利用者や他システムとのインターフェースに関する仕様であり、顧客やユーザーとの合意対象となる設計項目。
  • 画面レイアウト、帳票フォーマット、API仕様、データ形式など、システムの「外側から見える部分」を定義する。
• 例: ログイン画面にはユーザーIDとパスワードの入力欄を配置する、CSV出力は文字コードUTF-8で行う

• 定義: システムの内部構造や処理方式に関する仕様のこと。
• 説明:
  • 基本設計の対象外。システム内部の構造や処理方法に関する仕様であり、主に開発者が実装のために扱う設計項目。
  • データベース物理配置設計、アルゴリズム、モジュール構成、クラス設計など、システムの「内側の実装方法」を定義する。
• 例: アクセス効率を考慮し顧客情報の検索結果は非正規化データモデルで保存する、認証トークンはRedisでキャッシュする

• 定義: ITシステムを目的別に分類する概念。本規格では SoR と SoE が含まれる。
• 説明:
  • システム開発の文脈では、特にアーキテクチャ設計、品質基準設定において、すべてのシステムを同一の設計原則・開発プロセスで扱うことの非効率性と、プロジェクト目的とシステム要件のミスマッチを避けるために用いられる。
  • 本規格では、プロジェクト特性に応じて、SoR / SoE 以外の類型を補助的に定義することを妨げない。ただし、SoR / SoE の定義を曖昧にしてはならない。
• 例: SoR(記録のためのシステム), SoE(つながりのためのシステム）

• 定義: 業務データの正本（Single Source of Truth）を正確・永続的に管理するシステム
• 説明:
  • データの正確性・完全性・一貫性が最重要
  • 外部仕様の変更頻度は低い（安定志向）
  • 厳格な統制、監査、セキュリティ、可用性、耐障害性が要求される
• 例: 基幹業務システム（会計、人事、販売管理）、マスタCRUD管理サイト

• 定義: 利用者との接点となり、業務遂行や体験を支援することを目的とするシステム
• 説明:
  • UI/UX 重視
  • 外部仕様の変更頻度が高い
  • 外部連携・マルチチャネル前提
  • 応答性能、拡張性、ユーザビリティ、迅速な変更・デプロイ能力が要求される
• 例: ECサイト、モバイルアプリ、ポータルサイト、CRMのフロント機能

以下の文章は、定義ではない。要求事項でもない。
基本概念の理解をより深めるための解説を記載する。

• 「要望」はインプット、「要件」は合意されたアウトプット。
• 要望をそのまま要件にしてしまうと、曖昧さ・矛盾・過剰品質を招く。

経営層（スポンサー）がプロジェクト目的を設定する。ステークホルダーの要望をインプットとして、要件を定義する。サンエム標準では、要求と要件を区別しない

graph TD

subgraph S[ステークホルダー]
    A[顧客責任者（スポンサー）]
    B[その他のステークホルダー]
end

A -->|設定する| C[プロジェクト目的]
S -->|現状への不満や期待| D[要望（Stakeholder Needs）]

C -->|ブレイクダウン| E[要件（Requirements）]
D -->|インプット| E

style S fill:#f0f9ff,stroke:#007acc,stroke-width:1px
style A fill:#ffffff,stroke:#007acc,stroke-dasharray: 3 3
style B fill:#ffffff,stroke:#007acc,stroke-dasharray: 3 3
style C fill:#e6f4ea,stroke:#3c8031,stroke-width:1px
style D fill:#fff3cd,stroke:#d39e00,stroke-width:1px
style E fill:#e0e0e0,stroke:#555,stroke-width:1px

要件定義では「前提（Assumption）」と「制約（Constraint）」はどちらも計画や要件を成り立たせる条件だが、性質と扱い方がまったく異なる。