(Translated by https://www.hiragana.jp/)
要求工学 - Wikipedia コンテンツにスキップ

要求ようきゅう工学こうがく

出典しゅってん: フリー百科ひゃっか事典じてん『ウィキペディア(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. Bibcode2013arXiv1304.0116R. doi:10.1007/s00766-012-0161-4. 

外部がいぶリンク

[編集へんしゅう]