コンテンツにスキップ

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

機能要件

出典: フリー百科事典『ウィキペディア(Wikipedia)』

機能要件 (: functional requirement)とは、ソフトウェア工学システム工学の分野では、システムまたはそのコンポーネントに必要な機能や性能の定義のこと。機能は、入力から出力までの間の動作の仕様として記述される[1]

機能要件には、計算、技術的な詳細、データの操作と処理、およびシステムが実行する内容を定義するその他の機能が含まれる[2]。システムの振る舞いに関する要件は、すべてのケースについて説明を入れる。これらはユースケースに取り込まれる。機能要件は、設計または実装に制約(パフォーマンス要件、セキュリティ、信頼性など)を課す非機能要件(「品質要件」とも呼ばれる)で補足される。一般に、機能要件は「システムは<要件>を実行する必要がある」という形式で表されるが、非機能要件は「システムは<要件>である必要がある」という形式を取る[3]。 機能要件を実装するための計画はシステム設計で詳しく説明され、非機能要件はシステムアーキテクチャで詳しく説明される[4] [5]

要求工学で定義されているように、機能要件はシステムの特定の結果を指定する。これは、コストや信頼性などの全体的な特性を指定する非機能要件とは対照的である。機能要件はシステムのアプリケーションアーキテクチャを推進し、非機能要件はシステムの技術アーキテクチャを推進する[4]

場合によっては、要求分析担当者は、一連の機能要件を収集して検証した後、ユースケースを生成する。機能要件の収集と変更の順番は、大まかに言えば「ユーザー/利害関係者の要求→分析→ユースケース→組み込み」である。利害関係者は要求を行い、システムエンジニアは要件の側面について話し合い、観察し、理解しようとする。ユースケース、エンティティ関係図、およびその他のモデルは、要件を検証するために構築される。文書化され承認された場合、要件は実装/組み込まれる[6]。 各ユースケースは、1つ以上の機能要件を通じて動作シナリオを示している。多くの場合、要求分析担当者は一連のユースケースを引き出すことから始める。このユースケースから、ユーザーが各ユースケースを実行できるようにするために実装する必要のある機能要件を導き出すことができるためである。

プロセス

[編集]

一般的な機能要件には、一意の名前と番号を付け、簡単な要約、理論的解釈を添える。この情報は、読者が要件が必要な理由を理解し、システムの開発を通じて要件を追跡するのに役立つ[7]。 要件の核心は、必要な動作の説明であり、明確で読みやすいものである必要がある。説明されている動作は、組織またはビジネスルールに由来する場合もあれば、ユーザー、利害関係者、および組織内の他の専門家との会議を通じて発見される場合もある。 ユースケースの開発中にも、多くの要件が明らかになる可能性がある。これが発生した場合、要求分析担当者は、機能要件の中に仮のプレースホルダー要件を作成し、後で詳細を調査して、内容を埋める。

関連項目

[編集]

関連項目

[編集]
  1. ^ “Chapter 4: Requirements - Writing Requirements”. Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254. CRC Press. (2017). pp. 89–93. ISBN 9781351831420. https://books.google.com/books?id=ZQMvDwAAQBAJ&pg=PA89 15 June 2018閲覧。 
  2. ^ “Supplement 4-A, A Procedure for Requirements Analysis”. Systems Engineering Fundamentals. United States Government US Army. (2001). ISBN 978-1484120835. オリジナルの31 January 2017時点におけるアーカイブ。. https://web.archive.org/web/20170131231503/http://www.dau.mil/publications/publicationsdocs/sefguide%2001-01.pdf 18 March 2016閲覧。 
  3. ^ Loucopoulos, P. (2005). “Chapter 4: Requirements Engineering”. Design Process Improvement: A Review of Current Practice. Springer-Verlag. pp. 116–139. ISBN 9781846280610 
  4. ^ a b Adams, K.M. (2015). “3.2 Definitions for Functional and Non-Functional Requirements”. Non-functional Requirements in Systems Analysis and Design. Springer. pp. 45–50. ISBN 9783319183442 
  5. ^ “Chapter 6: Impact Analysis”. Engineering and Managing Software Requirements. Springer Science & Business Media. (2006). pp. 117–42. ISBN 9783540282440 
  6. ^ MITRE Corporate Communications and Public Affairs. “Requirements Engineering: Eliciting, Collecting, and Developing Requirements”. The MITRE Systems Engineering Guide. MITRE Corporation. pp. 304–13. ISBN 9780615974422. https://www.mitre.org/publications/technical-papers/the-mitre-systems-engineering-guide 15 June 2018閲覧。 
  7. ^ Stellman, Andrew; Greene, Jennifer (2005). “Chapter 6: Software requirements”. Applied Software Project Management. O'Reilly Media. pp. 97–130. ISBN 9780596553821. https://books.google.com/books?id=IYdJocLVa8wC&pg=PA97 15 June 2018閲覧。