システム化に対するニーズと要求／要件
システム化に対してステークホルダが最初に抱く意図は，十分な合理性と形式性を伴わないことが多い。この意図を分析，検討することによって初めて，システム化の要求／要件となる。
共通フレーム 2007 では，関連用語を以下のように使い分けている。
ニーズと要求／要件は，プロセスによって相対的なものである。企画プロセスは，経営や市場のニーズから事業要件を導く。事業要件は，次の要件定義プロセスにとってはニーズであり，このプロセスでさらに検討を重ねて業務要件を作り上げる。
要求と要件
ともに requirement の訳語である。国際規格では，例えば次のように定義されている。
requirement : 製品またはプロセスの運用／機能／設計上の特性を識別する分で，曖昧性がなく，テスト可能で，測定可能で，（顧客または内部の品質保証ガイドラインに）受け入れられるために必要であるもの
ISO/IEC 26702:2007 システム工学プロセスの適用及び管理
つまり，requirement は，事業目的や業務目的に照らして「本当に必要か」が十分検討され，「どうなれば要求が満たされたことになるのか」を示す手段まではっきりしており，曖昧性のない形式で書かれたものでなければならない。
共通フレーム 2007（第 2 版）では「要求」を通常の訳語として用い，特に合理性や形式性を伴うことを強調するときに「要件」を用いる。
要件定義
辞書によると，要件とは「求められる条件のこと」，定義（define）とは「物事の意味・内容を他と区別できるように，言葉で明確に限定すること」である。
システム化における要件定義とは，「ユーザ企業の事業目標の達成のため，情報システムに求められるものを定め，その範囲を明らかにすること」といえる。
要件定義プロセスの活動内容
共通フレーム 2013 によれば，要件定義プロセスの活動内容には，利害関係者の識別，要件の識別，要件の評価，要件の合意などがある。
利害関係者の識別
システムのライフサイクルの全期間を通して，どの工程でどの関係者が参画するのかを明確にする。
要件の識別
利害関係者から要件を漏れなく引き出し，制約条件や運用シナリオなどを明らかにする。
要件の評価
抽出された要件を確認して，矛盾点や曖昧な点をなくし，一貫性がある要件の集合として整理する。
要件の合意
矛盾した要件，実現不可能な要件などの問題点に対する解決方法を利害関係者に説明し，合意を得る。
要件定義におけるシステムアーキテクトの役割
システムアークテクとは，要件定義において，ユーザ要求をヒアリングし，その要求を正しく理解した上で，システムの要件としてドキュメントにまとめ，ユーザに確認する。
しかし，ユーザから提示された要求に漏れがあったり，ユーザ要求の意味を取り違えたりすると，システムから出力された情報が想定したものと異なったり，必要な情報の提供のタイミングが遅くなったりするなど，本来，ユーザが求めているシステムにはならないことがある。したがって，システムアーキテクトは，次のような点に留意して，ユーザ要求をヒアリングし，その要求を正しく理解することが大切である。
- ユーザから提示された個々の要求に矛盾がないか。
- ユーザ要求として提示されるべき業務手順や法的な制約などが，ユーザ部門内では自明のこととして，省略されていないか。
その上で，要件としてまとめるために，対象業務をモデル化したり，ユーザ要求を可視化したりする。その際，ユーザとの認識の相違をなくすために，次のような工夫を行うことが重要である。
- モデルを分かりやすく表記するために UML を用いたり，言葉の定義を統一するために用語辞書を作成したりする。
- 現行業務とシステム構築後の業務の変更点を明確にするために，両者の対比表を作成する。
- システムによって実現する機能と運用によって行う作業を明確にするために，業務の流れ，処理のタイミングを記述した業務フロー図を作成する。
（出典）平成21年度 秋期 システムアーキテクト試験 午後Ⅱ 問題 問1「要件定義について」
要求や要件の分類
要件定義の領域では，PMI (Project Management Institute) と IIBA (International Institute of Business Analysis) という 2 つの国際組織がそれぞれ知識体系をまとめあげている。
これらの知識体系の中で，要求は「誰が出した要求か？」という視点で，ビジネス要求，ステークホルダ要求，ソリューション要求，および，特殊な移行要求の 4 つに分類されている。
- ビジネス要求 (Business requirement)
- ステークホルダー要求 (Stakeholder requirement)
- ソリューション要求 (Solution requirement)
- 機能要求 (functional requirements)
- 非機能要求 (non-functional requirements)
- 移行要求 (Transition requirements)
さらに，ソリューション要求は機能要求と非機能要求に分類できる。
ニーズ
要求／要件以前のステークホルダの意図，要望，思い，夢などである。必要性が十分検討されていないか，曖昧な状態のものである。企画プロセスや要件定義プロセスは，ニーズを十分検討し，要求／要件まで変換するプロセスと考えられる。
参考文献
- 共通フレーム 2013
- 上村 有子（エディフィストラーニング），「図解即戦力 要件定義のセオリーと実践方法がこれ１冊でしっかりわかる教科書」，技術評論社，2020年7月11日
- 平成21年度 秋期 システムアーキテクト試験 午後Ⅱ 問題 問1「要件定義について」
更新履歴
- 2022年12月9日 新規作成
- 2022年12月17日 共通フレーム 2013 の要件定義プロセスの活動内容を追加
- 2023年3月21日 参考文献に平成21年度 秋期 システムアーキテクト試験 午後Ⅱ 問題 問1「要件定義について」を追加
