機能要件 (英: functional requirement)とは、ソフトウェア工学とシステム工学の分野では、システムまたはそのコンポーネントに必要な機能や性能の定義のこと。機能は、入力から出力までの間の動作の仕様として記述される[1]。
機能要件には、計算、技術的な詳細、データの操作と処理、およびシステムが実行する内容を定義するその他の機能が含まれる[2]。システムの振る舞いに関する要件は、すべてのケースについて説明を入れる。これらはユースケースに取り込まれる。機能要件は、設計または実装に制約（パフォーマンス要件、セキュリティ、信頼性など）を課す非機能要件（「品質要件」とも呼ばれる）で補足される。一般に、機能要件は「システムは<要件>を実行する必要がある」という形式で表されるが、非機能要件は「システムは<要件>である必要がある」という形式を取る[3]。 機能要件を実装するための計画はシステム設計で詳しく説明され、非機能要件はシステムアーキテクチャで詳しく説明される[4] [5]。
要求工学で定義されているように、機能要件はシステムの特定の結果を指定する。これは、コストや信頼性などの全体的な特性を指定する非機能要件とは対照的である。機能要件はシステムのアプリケーションアーキテクチャを推進し、非機能要件はシステムの技術アーキテクチャを推進する[4]。
場合によっては、要求分析担当者は、一連の機能要件を収集して検証した後、ユースケースを生成する。機能要件の収集と変更の順番は、大まかに言えば「ユーザー/利害関係者の要求→分析→ユースケース→組み込み」である。利害関係者は要求を行い、システムエンジニアは要件の側面について話し合い、観察し、理解しようとする。ユースケース、エンティティ関係図、およびその他のモデルは、要件を検証するために構築される。文書化され承認された場合、要件は実装/組み込まれる[6]。 各ユースケースは、1つ以上の機能要件を通じて動作シナリオを示している。多くの場合、要求分析担当者は一連のユースケースを引き出すことから始める。このユースケースから、ユーザーが各ユースケースを実行できるようにするために実装する必要のある機能要件を導き出すことができるためである。
プロセス
一般的な機能要件には、一意の名前と番号を付け、簡単な要約、理論的解釈を添える。この情報は、読者が要件が必要な理由を理解し、システムの開発を通じて要件を追跡するのに役立つ[7]。 要件の核心は、必要な動作の説明であり、明確で読みやすいものである必要がある。説明されている動作は、組織またはビジネスルールに由来する場合もあれば、ユーザー、利害関係者、および組織内の他の専門家との会議を通じて発見される場合もある。 ユースケースの開発中にも、多くの要件が明らかになる可能性がある。これが発生した場合、要求分析担当者は、機能要件の中に仮のプレースホルダー要件を作成し、後で詳細を調査して、内容を埋める。
関連項目
関連項目
