ソフトウェアエンジニアリングにおける機能要件とは何ですか?
機能要件とは何ですか?
A 機能要件 (FR) は、ソフトウェアが提供する必要があるサービスの説明です。 ソフトウェア システムまたはそのコンポーネントについて説明します。 関数は、ソフトウェア システムへの入力、その動作、および出力に他なりません。 これは、計算、データ操作、ビジネス プロセス、ユーザー インタラクション、またはシステムがどのような機能を実行する可能性があるかを定義するその他の特定の機能です。 ソフトウェアエンジニアリングにおける機能要件は、機能要件とも呼ばれます。 機能仕様.
ソフトウェア エンジニアリングおよびシステム エンジニアリングでは、機能要件は、送信者の必要性に関する高レベルの抽象的な記述から、詳細な数学的機能要件の仕様まで多岐にわたります。 機能的なソフトウェア 要件は、システムの意図された動作を把握するのに役立ちます。
機能要件文書には何を含めるべきですか?
機能要件ドキュメントの書き方は次のとおりです。
システムの機能要件には、次のものが含まれる必要があります。
- 各画面で行われる操作の詳細
- データ処理ロジックをシステムに組み込む必要がある
- システムレポートまたはその他の出力の説明が含まれている必要があります
- システムによって実行されるワークフローに関する完全な情報
- システム内のデータの作成/変更/削除を誰に許可するかを明確に定義する必要があります。
- システムが適用される規制およびコンプライアンスのニーズをどのように満たすかについては、機能文書に記載する必要があります。
機能要件の利点
ここでは、典型的な機能要件ドキュメントを作成する利点/利点を示します。
- アプリケーションの機能要件に記載されているすべての機能をアプリケーションが提供しているかどうかを確認するのに役立ちます。
- 機能要件ドキュメントは、システムまたはそのサブシステムの XNUMX つの機能を定義するのに役立ちます。
- 機能要件と要件分析は、不足している要件を特定するのに役立ちます。 これらは、期待されるシステム サービスと動作を明確に定義するのに役立ちます。
- 機能要件の収集段階で検出されたエラーは、最も安価に修正できます。
- ユーザーの目標、タスク、アクティビティをサポートする
機能要件の種類
最も一般的な機能要件タイプは次のとおりです。
- トランザクション処理
- ビジネスルール
- 認定要件
- 報告要件
- 管理機能
- 認可レベル
- 監査追跡
- 外部インターフェース
- 履歴データの管理
- 法的要件および規制要件
機能要件の例
以下は一般的な機能要件の例です。
- ソフトウェアは、ABC Contact Management System に対して顧客を自動的に検証します。
- 販売システムでは、ユーザーが顧客の販売を記録できるようにする必要があります。
- アプリケーション内のすべてのウィンドウの背景色は青になり、0 進数の RGB カラー値は 0000xXNUMXFF になります。
- 管理レベルの従業員のみが収益データを表示する権利を持っています。
- ソフトウェア システムは銀行 API と統合される必要があります。
- ソフトウェアシステムは合格するはずです セクション508 アクセシビリティ要件。
非機能要件と機能要件
ここでは、機能要件と非機能要件の主な違いを示します。 ソフトウエアエンジニアリング:
Parameters | 機能要件 | 非機能要件 |
---|---|---|
それは何ですか | 動詞 | Attributes |
要件 | それが必須です | 強制ではありません |
捕獲タイプ | ユースケースでキャプチャされます。 | それは品質属性として捉えられます。 |
最終結果 | 製品の機能 | 製品の特性 |
キャプチャ | 捕獲が簡単 | 捕獲が難しい |
DevOps Tools Engineer試験のObjective | ソフトウェアの機能を検証するのに役立ちます。 | ソフトウェアのパフォーマンスを検証するのに役立ちます。 |
重点分野 | ユーザーの要件に焦点を当てる | ユーザーの期待に集中します。 |
ドキュメント | 製品の機能を説明する | 製品の仕組みについて説明します |
テストの種類 | システム、統合、エンドツーエンドなどの機能テスト APIテスト, etc. | パフォーマンス、ストレス、ユーザビリティなどの非機能テスト セキュリティテスト, etc. |
テストの実行 | テストの実行は、非機能テストの前に行われます。 | 機能テスト後 |
製品情報 | 製品の特徴 | 製品のプロパティ |
機能要件のベストプラクティス
機能要件ドキュメントを作成するための重要なベスト プラクティスは次のとおりです。
- XNUMX つの要件を XNUMX つに組み合わせないでください。 要件を細分化してください。
- 各要件を可能な限り完全かつ正確にする必要があります。
- 文書にはすべての技術要件が記載されている必要があります。
- すべての要件を目的と原則にマッピングし、ソフトウェア配信の成功に貢献します
- インタビュー、ワークショップ、カジュアルなコミュニケーションを通じて要件を引き出します。
- 要件に重大な影響を与える既知の検証済みの制約がある場合、それは文書化する必要がある重大な状態です。
- すべての前提を文書に記載する必要があります。
機能要件作成時の間違い
機能要件ドキュメントの作成時によくある間違いをいくつか示します。
- 開発者を混乱させる可能性のある不当な追加情報を入れること
- 要件文書に十分な詳細が記載されていない。
- 要件自体を除く、ルールや例、範囲指定ステートメントや目標を追加します。
- 要件を完全、正確、かつ明確に記述するために絶対に必要な重要な情報が省略されています。
- 一部の専門家は、要件が変更されると、正しい真実を見つける代わりに、文書化した要件を擁護し始めます。
- 目的または原則にマッピングされていない要件。
重要な教訓
- ソフトウェアエンジニアリングにおける機能要件を説明する: 機能要件はシステムまたはそのコンポーネントを定義します。
- 機能要件ドキュメントには、データ処理ロジックと、システムによって実行されるワークフローに関する完全な情報が含まれている必要があります
- 機能要件と要件分析は、不足している要件の特定に役立ちます
- トランザクションの修正、調整、キャンセル、ビジネス ルール、認証要件、レポート要件、管理機能、認可レベル、監査追跡、外部インターフェイス、履歴データ管理、法的または規制上の要件など、さまざまな種類の機能要件があります。
- XNUMX つの要件を XNUMX つに結合しないことをお勧めします。 要件を細分化してください。
- 開発者を混乱させる可能性のある不当な追加情報を機能要件文書に含めることは避けるべきです。 これらの要件が実際のテスト手順にどのように反映されるかを理解するには、このガイドを参照してください。 機能テスト.