Loading article…
工学において、要求事項とは、作業の成果物が受け入れられるために満たされなければならない条件のことです。それは、材料、設計、製品、またはサービスによって満たされるべき条件を明示的、客観的、明確かつ多くの場合定量的に記述したものです。[ 1 ]
仕様書（またはスペック）とは、通常、製品開発の設計段階で開発者が、また検証プロセスでテスターが使用する一連の要件のことです。
アジャイルソフトウェア開発のような反復的かつ漸進的な開発手法では、要件は設計および実装と並行して開発されます。一方、ウォーターフォールモデルでは、設計や実装を開始する前に要件が完成します。
要求事項は、エンジニアリング設計、システムエンジニアリング、ソフトウェアエンジニアリング、エンタープライズエンジニアリング、製品開発、プロセス最適化など、多くのエンジニアリング分野で使用されています。
要件とは、顧客、組織、ユーザー、またはその他の利害関係者にとってシステムが価値と有用性を持つために必要な、または望ましい機能、属性、能力、特性、または品質を記述できる、比較的広範な概念である。
「要件」という用語は、少なくとも1960年代からソフトウェアエンジニアリングコミュニティで使用されています。[ 2 ]
IIBAのビジネス分析知識体系ガイド®バージョン2（BABOK） [ 3 ]によると、要件は次のとおりです。
この定義は、IEEE 610.12-1990: IEEEソフトウェアエンジニアリング用語標準用語集に基づいています。[ 4 ]
要件は、以下の2つの分野に関連すると言える。
製品要件とプロセス要件は密接に関連しています。製品要件はプロセス要件をサポートするために必要な自動化を規定するものであり、プロセス要件は製品要件をサポートするために必要な活動を規定するものと言えます。例えば、最大開発コスト要件（プロセス要件）は、最大販売価格要件（製品要件）の達成を支援するために課されることがあります。また、製品の保守性（製品要件）という要件は、特定の開発スタイル（オブジェクト指向プログラミングなど）、スタイルガイド、またはレビュー／検査プロセス（プロセス要件）に従うことを義務付けることで対処されることがよくあります。
要件は通常、開発の進行のさまざまな段階で生成されるタイプに分類され、その分類法は使用される全体的なモデルによって異なります。たとえば、次のスキームは、国際ビジネス分析協会がビジネス分析知識体系[ 5 ]で考案したものです（ FURPSと要件のタイプも参照）。
優れた要求の特性は、さまざまな著者によって述べられており、それぞれの著者は一般的に、自身の一般的な議論や対象となる特定の技術分野に最も適した特性を強調している。しかし、以下の特性は一般的に認められている。[ 8 ] [ 9 ]
要求事項の品質に影響を与える要素は他にも多数あります。要求事項がデータ整合性の規則に従う場合（例えば）、正確性／正当性、および妥当性／承認性も重要な要素となります。 トレーサビリティは、要求事項セットがニーズを満たしていること（要求事項以上のものも、それ以下のものも満たしていないこと）を裏付けます。
上記に加えて、外部から観測可能な要件、つまり、要件が製品の特性を規定しており、それが外部から観測可能またはユーザーが体験できるものであるという点も挙げられます。こうした支持者は、内部アーキテクチャ、設計、実装、またはテストに関する決定を規定する要件は制約である可能性が高く、要件文書の制約セクションで明確に記述されるべきだと主張します。これに対し、この見解には2つの点で問題があると反論されます。第一に、この見解では、ユーザーエクスペリエンスはユーザーには知覚できない要件によって支えられている可能性があることを認識していません。例えば、ユーザーにジオコーディングされた情報を提示するという要件は、外部のサードパーティビジネスパートナーとのインターフェースに関する要件によって支えられている可能性があります。インターフェース自体はユーザーには知覚できませんが、インターフェースを通じて取得した情報の表示は確かにユーザーには知覚できます。第二に、制約は設計の選択肢を制限するのに対し、要件は設計特性を規定します。例を続けると、Webサービスインターフェースを選択する要件は、シングルサインオンアーキテクチャと互換性のある方法に設計の選択肢を制限する制約とは異なります。
すべての要件は検証可能であるべきです。最も一般的な方法はテストによる検証です。テストによる検証が不可能な場合は、別の検証方法（分析、デモンストレーション、検査、設計レビューなど）を用いる必要があります。
要件の中には、その構造上、検証不可能なものがあります。例えば、システムが特定の特性を決して示してはならない、あるいは常に示さなければならないといった要件です。これらの要件を適切にテストするには、無限のテストサイクルが必要になります。このような要件は、検証可能なように書き直す必要があります。前述のとおり、すべての要件は検証可能でなければなりません。
ソフトウェアレベルでは検証不可能な非機能要件は、顧客の意図を示す文書として保管する必要があります。ただし、これらの要件は、実際に満たすことができると判断されたプロセス要件にまで遡って追跡することができます。例えば、バックドアがないという非機能要件は、ペアプログラミングを使用するというプロセス要件に置き換えることで満たすことができます。その他の非機能要件は、他のシステムコンポーネントにまで遡って追跡し、そのレベルで検証します。例えば、システムの信頼性は、システムレベルでの分析によって検証されることがよくあります。複雑な安全要件を持つ航空電子機器ソフトウェアは、 DO-178B開発プロセスに従う必要があります。
システムまたはソフトウェアの要件の導出につながる活動。要件エンジニアリングには、プロジェクトの実現可能性調査または概念分析フェーズ、要件の引き出し（利害関係者のニーズの収集、理解、レビュー、および明確化）、要件分析[ 10 ] 、分析（一貫性と完全性の確認）、仕様（要件の文書化）、および検証（指定された要件が正しいことの確認）が含まれる場合があります。[ 11 ] [ 12 ]
要求事項には、曖昧さ、不完全性、矛盾といった問題が生じやすい。厳密な検査などの手法は、これらの問題に対処する上で有効であることが示されている。要求事項の段階で解決できる曖昧さ、不完全性、矛盾は、製品開発の後期段階で発見された場合と比べて、修正にかかるコストが桁違いに少なくて済むのが一般的である。要求事項分析は、これらの問題に対処することを目的としている。
エンジニアリング上のトレードオフとして、曖昧すぎる要件と、詳細すぎて
アジャイル開発手法は、これらの問題を克服する方法として発展したもので、要件を高レベルで基準化し、詳細を必要な時に、あるいは最後に責任を負うタイミングで具体化していくというものです。
要件は通常、さまざまな関係者間のコミュニケーション手段として記述されます。つまり、要件は一般ユーザーと開発者の両方にとって理解しやすいものでなければなりません。要件を文書化する一般的な方法の1つは、システムが何を行うべきかを記述することです。例：「請負業者はxyz日までに製品を納品しなければならない。」その他の方法としては、ユースケースやユーザーストーリーなどがあります。
要件は一般的に時間とともに変化します。一度定義され承認された要件は、変更管理の対象となります。多くのプロジェクトでは、システムが完成する前に要件が変更されます。これは、コンピュータソフトウェアの複雑さと、ユーザーが実際に目にするまで何が欲しいのか分からないという事実が一因です。このような要件の特性から、要件管理に関する研究や実践が生まれています。
要求事項とは何か、そしてそれらをどのように管理・活用すべきかについては、様々な見解が存在する。業界を代表する二つの団体は、IEEEとIIBAである。これら二つの団体は、要求事項の定義において、異なるものの類似した見解を持っている。
多くのプロジェクトは、要件についてほとんど、あるいは全く合意がないまま成功している。[ 13 ]さらに、要件を規定すると創造性や設計パフォーマンスが低下する可能性があるという証拠もある。 [ 14 ]要件は、設計者が提供された情報に過度に気を取られるため、創造性や設計を妨げる。[ 15 ] [ 16 ] [ 17 ]より一般的には、ソフトウェア要件は、実際の要件が明らかでない状況で設計上の決定を要件として誤って表現することによって生み出される幻想であると示唆する研究もある。[ 18 ]
一方、ほとんどのアジャイルソフトウェア開発手法は、ソフトウェア要件を事前に厳密に記述する必要性に疑問を呈しており、要件は常に変化するものだと考えています。例えば、エクストリームプログラミングでは、ユーザーストーリー（インデックスカードに収まる、システムの機能の一側面を説明する短い要約）を使用して要件を非公式に記述し、開発者は顧客に直接確認を求める義務があると考えています。アジャイル手法は、一連の自動化された受け入れテストで要件を把握しようとします。
要件が時間とともに変化することで、スコープクリープが発生する可能性があります。要件管理では要件の変更は許可されていますが、適切に追跡されていなかったり、先行するステップ（ビジネス目標、次にユーザー要件）が追加の監視によって抑制されていなかったり、コストや潜在的なプログラム失敗として扱われていなかったりすると、要件の変更は容易に発生しやすくなります。要件の変更は開発者が作業を完了できる速度よりも速く発生しやすく、その結果、作業が後退してしまう可能性があります。
要件の分類体系は、どのフレームワークに基づいて運用するかによって複数存在します（例えば、IEEEの規定規格とIIBAや米国国防総省のアプローチなど）。異なる場や非公式な会話における用語やプロセスの違いは、混乱を招き、望ましいプロセスからの逸脱を引き起こす可能性があります。
人間が運営するプロセスは、ガバナンスにおける人間の欠陥の影響を受けやすく、利便性、欲望、政治的思惑などによって例外が生じたり、プロセスが本来進むべき手順から逸脱したり、完全に覆されたりする可能性があります。例としては、以下のようなものがあります。
米国国防総省のプロセスにおける要求事項の問題の歴史的例には、次のようなものがある。
