要求工学

この記事は英語版の対応するページを翻訳することにより充実させることができます。（2021年8月） 翻訳前に重要な指示を読むには右にある[表示]をクリックしてください。 英語版記事を日本語へ機械翻訳したバージョン（Google翻訳）。 万が一翻訳の手がかりとして機械翻訳を用いた場合、翻訳者は必ず翻訳元原文を参照して機械翻訳の誤りを訂正し、正確な翻訳にしなければなりません。これが成されていない場合、記事は削除の方針G-3に基づき、削除される可能性があります。 信頼性が低いまたは低品質な文章を翻訳しないでください。もし可能ならば、文章を他言語版記事に示された文献で正しいかどうかを確認してください。 履歴継承を行うため、要約欄に翻訳元となった記事のページ名・版について記述する必要があります。記述方法については、Wikipedia:翻訳のガイドライン#要約欄への記入を参照ください。 翻訳後、{{翻訳告知|en|Requirements engineering|…}}をノートに追加することもできます。 Wikipedia:翻訳のガイドラインに、より詳細な翻訳の手順・指針についての説明があります。

要求工学（ようきゅうこうがく、英: requirements engineering、RE）^[1]は、工学設計プロセス（英語版）で要件を定義、文書化、および維持するプロセスのこと^[2]。これは、システム工学とソフトウェア工学で一般的である。

要求工学という用語が最初に使用されたのは、おそらく1964年の会議論文「メンテナンス、保守性、およびシステム要求工学」 ^[3]であったが、 1990年代後半まで一般的に使用されることはなかった。1997年3月のIEEE Computer Societyチュートリアル発刊^[4]と、International Requirements Engineering Conferenceに発展した要求工学に関する一連の会議体が設立され、一般で使用されるようになった。

ウォーターフォールモデルでは^[5]、 要求工学が開発プロセスの最初のフェーズとして提示される。ソフトウェアのRational Unified Process （RUP）を含む後の開発方法では、要求工学がシステムの存続期間を通じて継続することを前提としている。

システム工学の実践の一部である要求管理は、International Council on Systems Engineering（INCOSE）のマニュアルにも記載されている。

活動[編集]

要求工学に関連するかつどうは、開発中のシステムの種類と関連する組織による実践方法によって大きく異なる^[6]。 これらには次のものが含まれる。

1. 要件の聞き出し - 開発者と利害関係者が会う。後者は、ソフトウェア製品に関する彼らのニーズとウォンツについて尋ねられる。
2. 要求分析と交渉 - 要件が特定され（開発が反復的である場合は新しい要件を含む）、利害関係者との対立が解決される。書面ツールとグラフィカルツールの両方（後者は設計段階で一般的に使用されるが、この段階でも役立つと感じる人もいる）は、補助としてうまく使用されている。書面による分析ツールの例：ユースケースとユーザーストーリー。グラフィカルツールの例： UML ^[7]およびLML 。
3. システムモデリング - 一部の工学分野（または特定の状況）では、製品の建設または製造を開始する前に、製品を完全に設計およびモデル化する必要がある。したがって、設計段階は事前に実行する必要がある。たとえば、契約を承認して署名する前に、建物の設計図を作成する必要がある。多くの分野ではライフサイクルモデリング言語を使用してシステムのモデルを導出するが、他の分野ではUMLを使用することもある。注：ソフトウェア工学などの多くの分野では、ほとんどのモデリング活動は、要求工学の活動ではなく、設計活動に分類する。
4. 要求仕様 - 要件は、要件仕様（RS）と呼ばれる正式な成果物に文書化されており、検証後にのみ正式になる。 RSには、必要に応じて、書面による情報とグラフィカル（モデル）情報の両方を含めることができる。例：ソフトウェア要件仕様（SRS）。
5. 要求検証 - 文書化された要件とモデルが一貫しており、利害関係者のニーズを満たしていることを確認する。最終ドラフトが検証プロセスに合格した場合にのみ、RSが公式になる。
6. 要求管理 - 開始以来、システムの開発中、さらには使用後まで（変更、拡張など）、要件に関連するすべての活動を管理する。

これらは時系列の段階として提示されることもあるが、実際には、これらの活動にはかなりのインターリーブがある。

要求工学は、ソフトウェアプロジェクトの成功に明らかに貢献することが示されている^[8]。

問題[編集]

ドイツでのある限られた研究では、要求工学の実装で発生する可能性のある問題が示され、回答者に実際の問題であることに同意するかどうかを尋ねた。結果は一般化できるものとして提示されなかったが、主に認識された問題は不完全な要件、移動するターゲット、およびタイムボックスであり、通信の欠陥、トレーサビリティの欠如、用語の問題、および不明確な責任がより少ない問題であることが示唆された^[9]。

批判[編集]

要求工学の重要な側面である問題の構造化は、設計パフォーマンスを低下させると推測されている^[10]。 いくつかの研究は、要求工学プロセスに欠陥があり、要件が存在しない状況になる可能性があることを示唆している。ソフトウェア要件は、設計上の決定を要件として誤って表現しているような錯覚として作成される可能性がある^[11]。

関連項目[編集]

• 要求分析：ソフトウェア工学に焦点を当てた要求工学。
• Requirements Engineering Specialist Group（RESG）
• International Requirements Engineering Board（IREB）
• International Council on Systems Engineering（INCOSE）
• IEEE 12207 「システム工学とソフトウェア工学–ソフトウェアライフサイクルプロセス」
• The Open Group Architecture Framework (TOGAF)（第17章）
• 操作の概念（ConOps）
• 業務管理
• ソフトウェア要件
• ソフトウェア要件仕様
• ソフトウェア工学知識体系（SWEBOK）
• 設計仕様
• 仕様 (技術基準)
• 正式仕様
• ソフトウェア品質
• 品質管理
• スコープ管理

脚注[編集]

外部リンク[編集]

• 29148-2011 - Systems and software engineering — Life cycle processes — Requirements engineering. (2011). 1–94. doi:10.1109/IEEESTD.2011.6146379. ISBN 978-0-7381-6591-2. http://ieeexplore.ieee.org/servlet/opac?punumber=6146377 ("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 - http://standards.ieee.org/findstds/standard/29148-2011.html")
• Systems Engineering Body of Knowledge
• Requirements Engineering Management Handbook by FAA
• International Requirements Engineering Board (IREB)
• IBM Rational Resource Library by IEEE S