要求 工学
![]() | この
|
ウォーターフォールモデルでは[5]、
システム
活動
[要件 のき出 し -開発 者 と利害 関係 者 が会 う。後者 は、ソフトウェア製品 に関 する彼 らのニーズとウォンツについて尋 ねられる。要求 分析 と交渉 -要件 が特定 され(開発 が反復 的 である場合 は新 しい要件 を含 む)、利害 関係 者 との対立 が解決 される。書面 ツールとグラフィカルツールの両方 (後者 は設計 段階 で一般 的 に使用 されるが、この段階 でも役立 つと感 じる人 もいる)は、補助 としてうまく使用 されている。書面 による分析 ツールの例 :ユースケースとユーザーストーリー。グラフィカルツールの例 : UML [7]およびLML 。- システムモデリング -
一部 の工学 分野 (または特定 の状況 )では、製品 の建設 または製造 を開始 する前 に、製品 を完全 に設計 およびモデル化 する必要 がある。したがって、設計 段階 は事前 に実行 する必要 がある。たとえば、契約 を承認 して署名 する前 に、建物 の設計 図 を作成 する必要 がある。多 くの分野 ではライフサイクルモデリング言語 を使用 してシステムのモデルを導出 するが、他 の分野 ではUMLを使用 することもある。注 :ソフトウェア工学 などの多 くの分野 では、ほとんどのモデリング活動 は、要求 工学 の活動 ではなく、設計 活動 に分類 する。 要求 仕様 -要件 は、要件 仕様 (RS)と呼 ばれる正式 な成果 物 に文書 化 されており、検証 後 にのみ正式 になる。 RSには、必要 に応 じて、書面 による情報 とグラフィカル(モデル)情報 の両方 を含 めることができる。例 :ソフトウェア要件 仕様 (SRS)。要求 検証 -文書 化 された要件 とモデルが一貫 しており、利害 関係 者 のニーズを満 たしていることを確認 する。最終 ドラフトが検証 プロセスに合格 した場合 にのみ、RSが公式 になる。要求 管理 -開始 以来 、システムの開発 中 、さらには使用 後 まで(変更 、拡張 など)、要件 に関連 するすべての活動 を管理 する。
これらは
問題
[ドイツでのある
批判
[関連 項目
[要求 分析 :ソフトウェア工学 に焦点 を当 てた要求 工学 。- 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) 設計 仕様 仕様 (技術 基準 )正式 仕様 - ソフトウェア
品質 品質 管理 - スコープ
管理
脚注
[- ^ 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。
- ^ *Kotonya, Gerald; Sommerville, Ian (September 1998). Requirements Engineering: Processes and Techniques. John Wiley & Sons. ISBN 978-0-471-97208-2
- Chemuturi, M. (2013). Requirements Engineering and Management for Software Development Projects. doi:10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5
- ^ Dresner, K. H. Borchers (1964). Maintenance, maintainability, and system requirements engineering. SAE World Congress & Exhibition 1964. doi:10.4271/640591。
- ^ Thayer, ed (March 1997). Software Requirements Engineering (2nd ed.). IEEE Computer Society Press. ISBN 978-0-8186-7738-0
- ^ Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques (PDF). ICSE'87. pp. 1–9.
- ^ Sommerville, Ian (2009). Software Engineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1
- ^ “Uncovering Requirements With UML Class Diagrams Part 1”. tynerblain.com (7 March 2008). 14 March 2018
閲覧 。 - ^ 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.
- ^ 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.
- ^ Ralph, Paul; Mohanani, Rahul (May 2015). Is Requirements Engineering Inherently Counterproductive?. IEEE. doi:10.13140/2.1.3831.6321 .
- ^ 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.
外部 リンク
[- 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("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