機能要件
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/01/11 05:39 UTC 版)
ナビゲーションに移動 検索に移動機能要件 (英: functional requirement)とは、ソフトウェア工学とシステム工学の分野では、システムまたはそのコンポーネントに必要な機能や性能の定義のこと。機能は、入力から出力までの間の動作の仕様として記述される[1]。
機能要件には、計算、技術的な詳細、データの操作と処理、およびシステムが実行する内容を定義するその他の機能が含まれる[2]。システムの振る舞いに関する要件は、すべてのケースについて説明を入れる。これらはユースケースに取り込まれる。機能要件は、設計または実装に制約（パフォーマンス要件、セキュリティ、信頼性など）を課す非機能要件（「品質要件」とも呼ばれる）で補足される。一般に、機能要件は「システムは<要件>を実行する必要がある」という形式で表されるが、非機能要件は「システムは<要件>である必要がある」という形式を取る[3]。 機能要件を実装するための計画はシステム設計で詳しく説明され、非機能要件はシステムアーキテクチャで詳しく説明される[4] [5]。
要求工学で定義されているように、機能要件はシステムの特定の結果を指定する。これは、コストや信頼性などの全体的な特性を指定する非機能要件とは対照的である。機能要件はシステムのアプリケーションアーキテクチャを推進し、非機能要件はシステムの技術アーキテクチャを推進する[4]。
場合によっては、要求分析担当者は、一連の機能要件を収集して検証した後、ユースケースを生成する。機能要件の収集と変更の順番は、大まかに言えば「ユーザー/利害関係者の要求→分析→ユースケース→組み込み」である。利害関係者は要求を行い、システムエンジニアは要件の側面について話し合い、観察し、理解しようとする。ユースケース、エンティティ関係図、およびその他のモデルは、要件を検証するために構築される。文書化され承認された場合、要件は実装/組み込まれる[6]。 各ユースケースは、1つ以上の機能要件を通じて動作シナリオを示している。多くの場合、要求分析担当者は一連のユースケースを引き出すことから始める。このユースケースから、ユーザーが各ユースケースを実行できるようにするために実装する必要のある機能要件を導き出すことができるためである。
プロセス
一般的な機能要件には、一意の名前と番号を付け、簡単な要約、理論的解釈を添える。この情報は、読者が要件が必要な理由を理解し、システムの開発を通じて要件を追跡するのに役立つ[7]。 要件の核心は、必要な動作の説明であり、明確で読みやすいものである必要がある。説明されている動作は、組織またはビジネスルールに由来する場合もあれば、ユーザー、利害関係者、および組織内の他の専門家との会議を通じて発見される場合もある。 ユースケースの開発中にも、多くの要件が明らかになる可能性がある。これが発生した場合、要求分析担当者は、機能要件の中に仮のプレースホルダー要件を作成し、後で詳細を調査して、内容を埋める。
関連項目
関連項目
- ^ “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 2018年6月15日閲覧。
- ^ “Supplement 4-A, A Procedure for Requirements Analysis”. Systems Engineering Fundamentals. United States Government US Army. (2001). ISBN 978-1484120835. オリジナルの31 January 2017時点におけるアーカイブ。 2016年3月18日閲覧。
- ^ Loucopoulos, P. (2005). “Chapter 4: Requirements Engineering”. Design Process Improvement: A Review of Current Practice. Springer-Verlag. pp. 116–139. ISBN 9781846280610
- ^ 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
- ^ “Chapter 6: Impact Analysis”. Engineering and Managing Software Requirements. Springer Science & Business Media. (2006). pp. 117–42. ISBN 9783540282440
- ^ 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 2018年6月15日閲覧。
- ^ Stellman, Andrew; Greene, Jennifer (2005). “Chapter 6: Software requirements”. Applied Software Project Management. O'Reilly Media. pp. 97–130. ISBN 9780596553821 2018年6月15日閲覧。
機能要件
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2018/11/02 06:50 UTC 版)
津波救命艇が満たすべき機能要件として、津波救命艇ガイドラインには、概略次の内容が規定されている。 強度要件、許容加速度毎秒10メートルでの正面衝突、毎秒5メートルでの側面衝突においても形状を維持し、強度を損なわないこと。 毎秒10メートルでの正面衝突時に本体に作用する最大加速度が15G以下であること。 衝突時、搭乗者に作用するHPC（頭部性能基準）が1,000以下であること。 不沈性及び復原性定員及び装備品をすべて載せた状態で、通常時及び内部に浸水した場合において、沈まず、十分な復原性を有していること。 漂流時の姿勢保持漂流時の横揺れ等による避難者等への影響を軽減するため、船体形状、付加物の設置等の設計上の配慮を行うこと。 居住性避難者が一般人であること、災害時であること、閉鎖空間であること等による避難者の心理状況を考慮し、内部空間の大きさ及び色彩、座席等の内装品についての設計上の配慮をすること。 避難者保護措置等漂流時、衝突時等に、避難者の負傷を最小限にするよう内装に適切な保護措置を施すこと。 固定装置及び装備品出入口、採光窓、トイレ、照明器具、行動指導書等の固定装置を設けること。 救助までの期間を7日間と想定し、発煙筒、生存指導書、応急医療具、船酔い薬、保温具等の装備品を搭載すること。 通信設備有事の際、自身の現在位置等を発信するため、EPIRB等の通信設備を搭載できる設計とすること。 本体の色、表示項目漂流中、早期発見・救助のため、艇体を見やすい色とし、識別番号等を表示すること。 設置架台等設置架台、搭乗設備が、台風等による強風、津波に先立つ地震等により移動、転倒、破損等することがないように設計すること。 その他本体の材料に強化プラスチック（FRP）、浮力材を使用する場合は、船舶救命設備規則第9条の全閉囲型救命艇の材料及び浮力材の基準に適合すること。 40年以上の継続使用を想定した維持管理のためのマニュアルを作成し、利用者に供与すること。
※この「機能要件」の解説は、「津波救命艇」の解説の一部です。
「機能要件」を含む「津波救命艇」の記事については、「津波救命艇」の概要を参照ください。
- 機能要件のページへのリンク
