機能要件と非機能要件の特徴

features functional requirements

このチュートリアルでは、タイプ、機能、機能要件と非機能要件の比較、およびビジネス要件と機能要件の比較を例を挙げて説明します。

機能要件は、ソフトウェアシステムが何をすべきかを定義します。ソフトウェアシステムまたはそのモジュールの機能を定義します。機能性は、システムからの出力に対するテスト対象のシステムへの入力のセットとして測定されます。

システムでの機能要件の実装は、システム設計フェーズで計画されますが、非機能要件の場合は、システムアーキテクチャドキュメントで計画されます。機能要件は、非機能要件の生成をサポートします。

学習内容：

• 機能要件と非機能要件
  • 機能要件
    • 機能要件の種類
  • ビジネス要件と機能要件
  • 非機能要件
    • 非機能要件の種類
  • 機能要件から非機能要件を導き出す
• 機能要件と非機能要件
• 結論
  • 推奨読書

機能要件と非機能要件

機能要件

例を参考にして、機能要件とは何かを理解しましょう-

例： 自動車ADASプロジェクトでは、サラウンドビューシステムの機能要件は「リアカメラが脅威またはオブジェクトを検出する必要がある」である可能性があります。ここでの非機能要件は、「カメラセンサーによって脅威が検出されたときにユーザーへのアラートを表示する速度」である可能性があります。

別のものを取る 例 インフォテインメントシステムプロジェクトの。ユーザーはここでHMIからBluetoothを有効にし、Bluetoothが有効になっているかどうかを確認します。 注意 、ユーザーがBluetoothを有効にすると、他のBluetoothサービスが有効になります（灰色から太字）。

無料のリアルタイムマルウェア保護2017

したがって、機能要件は、ユーザーがタスクを実行したときの特定のシステム結果について説明します。一方、非機能要件は、システムまたはそのコンポーネントの全体的な動作を提供し、機能上ではありません。

機能要件の種類

機能要件には、機能テストの一部として測定できる次のコンポーネントが含まれる場合があります。

＃1）相互運用性： 要件は、ソフトウェアシステムが異なるシステム間で相互運用可能かどうかを説明します。

例： 車内エンターテインメントシステムのBluetooth機能要件については、ユーザーがBluetooth対応のAndroidベースのスマートフォンをQNXベースのインフォテインメントシステムにペアリングすると、電話帳をインフォテインメントシステムに転送したり、電話デバイスからインフォテインメントシステムに音楽をストリーミングしたりできるはずです。

したがって、相互運用性は、2つの異なるデバイス間の通信が可能かどうかをチェックします。

別の 例 Gmailのようなメールサービスシステムからです。 Gmailでは、Yahoo.comやRediffmail.comなどの別のメール交換サーバーからメールをインポートできます。これは、電子メールサーバー間の相互運用性のために可能です。

＃2）セキュリティ： 機能的 要件は、ソフトウェア要件のセキュリティ面を説明します。

例： システムをセキュリティの脅威から保護するコントローラーエリアネットワーク（CAN）を使用するADASサラウンドビューカメラベースのシステムのサイバーセキュリティベースのサービス。

別の 例 ソーシャルネットワーキングサイトのFacebookからです 。 ユーザーのデータは安全であり、部外者に漏洩してはなりません。このFacebookの例が、Facebookでの最近のデータ侵害の発生と、Facebookが直面する結果により、読者にセキュリティのより広い範囲を提供することを願っています。

＃3）精度： 精度とは、システムに入力されたデータがシステムによって正しく計算および使用され、出力が正しいことを定義します。

例： コントローラエリアネットワークでは、CAN信号値がECU（ABSユニット、HVACユニット、インストルメントクラスターユニットなど）によってCANバスを介して送信されると、別のECUが送信されたデータが正しいかどうかを識別できます。 CRCチェック経由。

別の 例 オンラインバンキングソリューションからのものである可能性があります。ユーザーが資金を受け取るとき、受け取った金額はアカウントに正確に入金される必要があり、精度の変動は受け入れられません。

＃4）コンプライアンス： コンプライアンス機能要件は、開発されたシステムが業界標準に準拠していることを検証します。

例： Bluetoothプロファイル機能（つまり、A2DPを介したオーディオストリーミング、HFPを介した通話）がBluetoothSIGリリースプロファイルバージョンに準拠しているかどうか。

別の 例 カーインフォテインメントシステムでのアップルカープレイのそれである可能性があります。インフォテインメントのアプリはから証明書を取得します 林檎 Apple Webサイトに記載されているすべての前提条件が、サードパーティのCar Playデバイス（この場合はインフォテインメント）によって満たされている場合。

別の 例 鉄道チケットシステム用のWebベースのアプリケーションから取得できます。 Webサイトは、サイバーセキュリティガイドラインに従い、アクセシビリティの点でWorld WideWebに準拠している必要があります。

要件フォームの例：

いくつかの例で、機能要件が何であるかをすでに見てきました。ここで、IBMDOORSなどの要件管理ツールに統合した場合の機能要件がどのようになるかを見てみましょう。要件管理ツールで機能要件を文書化する際に考慮すべき複数の属性があります。

以下は、考慮すべきいくつかの属性です。

1. オブジェクトタイプ： この属性は、要件ドキュメントのどのセクションがこの属性の一部であるかを説明します。それらは、見出し、説明、要件などである可能性があります。ほとんどの場合、「要件」セクションは実装とテストのために考慮され、見出しと説明セクションは、より良い理解のための要件のサポート説明として使用されます。
2. 担当者： 要件管理ツールで要件を文書化した作成者。
3. プロジェクト/システム名： 要件が適用されるプロジェクト、 例えば、 「XYZOEM（相手先ブランド供給）のインフォテインメントシステム、自動車会社、またはABCバンキング有限会社のWebアプリケーション」。
4. 要件のバージョン番号： このフィールド/属性は、顧客の更新またはシステム設計の変更により要件が複数の変更を受けた場合に、要件のバージョン番号を通知します。
5. 要件ID： この属性は、一意の要件IDを示します。要件IDは、データベース内の要件を簡単に追跡したり、コード内の要件を効率的にマッピングしたりするために使用されます。また、バグ追跡ツールで欠陥をログに記録する際に、要件への参照を提供するために使用することもできます。
6. 要件の説明： この属性は、要件を説明する最も重要な属性の1つです。この属性を読むことにより、エンジニアは要件を理解することができます。
7. 要件ステータス： 要件ステータス属性は、要件管理ツールの要件のステータス、つまり、プロジェクトが承認、保留、拒否、または削除されたかどうかを示します。
8. コメント： この属性は、責任者または要件マネージャーに、要件に関するコメントを文書化するオプションを提供します。 例： 機能要件について考えられるコメントは、「要件を実装するためのサードパーティソフトウェアパッケージへの依存」である可能性があります。

DOORSからのスナップショット

ビジネス要件から機能要件を導き出す

これは、「セクションの一部としてすでに説明されています。 ビジネス要件から機能要件を導き出す ' 下 要件分析 論文。

ビジネス要件と機能要件

この違いは大まかにカバーされています 要件分析 論文。しかし、私たちはしようとします 以下の表で、さらにいくつかのポイントを強調してください。

非機能要件

非機能要件は、「システムが何をすべきか」（機能要件）ではなく、「システムがどうあるべきか」について述べています。それらは主に、顧客やその他の利害関係者からの入力に基づく機能要件から導き出されます。非機能要件の実装の詳細は、システムアーキテクチャドキュメントに記載されています。

非機能要件は、構築されるシステムの品質面を説明します。パフォーマンス、移植性、使いやすさなど。機能要件とは異なり、非機能要件はどのシステムでも段階的に実装されます。

URPS （ユーザビリティ、信頼性、パフォーマンス、およびサポート性）から FURPS （機能性、使いやすさ、信頼性、パフォーマンス、およびサポート性）ソフトウェア開発者の品質を測定するためにIT業界で広く使用されている品質属性は、すべて非機能要件でカバーされています。さらに、他の品質属性もあります（詳細は次のセクションにあります）。

ウィキペディアでは、移植性や安定性などのさまざまな品質属性が存在するため、非機能要件を「ilities」と呼ぶことがあります。

非機能要件の種類

非機能要件は、以下のサブタイプで構成されます（網羅的ではありません）。

＃1）パフォーマンス：

非機能要件のパフォーマンス属性タイプは、システムパフォーマンスを測定します。 例： ADASサラウンドビューシステムでは、「車のイグニッションを開始してから2秒以内にリアカメラビューが表示されます」。

別の 例 パフォーマンスの向上は、インフォテインメントシステムのナビゲーションシステムによるものである可能性があります。 「ユーザーがナビゲーション画面に移動して目的地に入ると、ルートは「X」秒以内に計算されます」。もう1つ 例 Webアプリケーションのログインページから。 「ログイン後にユーザープロファイルページが読み込まれるまでにかかる時間。」

システムパフォーマンスの測定は負荷の測定とは異なることに注意してください。負荷テスト中に、システムのCPUとRAMをロードし、システムのスループットを確認します。パフォーマンスの場合、通常の負荷/ストレス条件でシステムスループットをテストします。

＃2）使いやすさ ：

ユーザビリティは、開発中のソフトウェアシステムのユーザビリティを測定します。

例えば 、モバイルWebアプリケーションが開発され、お住まいの地域での配管工と電気技師の空き状況に関する情報が提供されます。

このアプリへの入力は、現在地からの郵便番号と半径（キロメートル単位）です。しかし、これらのデータを入力するために、ユーザーが複数の画面を閲覧する必要があり、データ入力オプションがユーザーにすぐに表示されない小さなテキストボックスに表示される場合、このアプリはユーザーフレンドリーではないため、アプリの使いやすさはとても低い。

＃3）保守性 ：

ソフトウェアシステムの保守性は、システムの保守のしやすさです。開発中のシステムの平均故障間隔（MTBF）が低い場合、または平均修理時間（MTTR）が高い場合、システムの保守性は低いと見なされます。

保守性は、循環的複雑度を使用してコードレベルで測定されることがよくあります。循環的複雑度は、コードが複雑でないほど、ソフトウェアの保守が容易になることを示しています。

例： デッドコード（他の関数やモジュールで使用されていないコード）の数が多い、if / else条件の過度の使用、ネストされたループなどのために非常に複雑な、またはシステムが巨大でコードが実行されている場合のソフトウェアシステムが開発されています何百万行ものコードになり、適切なコメントはありません。このようなシステムは保守性が低いです。

別の 例 オンラインショッピングのウェブページである可能性があります。ユーザーが製品の概要を把握できるように（これはメモリを節約するために）Webサイトに多くの外部リンクがある場合、このWebサイトの保守性は低くなります。これは、外部のWebページのリンクが変更された場合、オンラインショッピングのWebサイトでも更新する必要があり、頻繁に更新する必要があるためです。

＃4）信頼性 ：

信頼性は可用性のもう1つの側面です。この品質属性は、特定の条件下でのシステムの可用性を強調します。保守性と同様にMTBFとして測定されます。

例： ADASサラウンドビューカメラシステムのリアビューカメラやトレーラーなどの相互に排他的な機能は、相互に干渉することなくシステム内で確実に機能するはずです。ユーザーがトレーラー機能を呼び出すとき、両方の機能が車のリアカメラにアクセスするため、リアビューが干渉しないようにする必要があります。

別の 例 オンライン保険金請求システムから。ユーザーが請求レポートを開始してから関連する経費請求書をアップロードする場合、システムはアップロードが完了するのに十分な時間を与える必要があり、アップロードプロセスをすぐにキャンセルしないでください。

＃5）移植性：

移植性とは、基盤となる依存フレームワークが同じままである場合に、ソフトウェアシステムが異なる環境で動作する能力を意味します。

例： 自動車メーカー向けに開発されたインフォテインメントシステム（Bluetoothサービスまたはマルチメディアサービス）のソフトウェアシステム/コンポーネントは、2つのインフォテインメントシステムは完全に異なりますが、コードをほとんどまたはまったく変更せずに別のインフォテインメントシステムで使用できるようにする必要があります。 。

別のものを取りましょう 例 WhatsAppから。メッセージングサービスは、IOS、Android、Windows、タブレット、ラップトップ、および電話にインストールして使用することができます。

＃6）サポート性：

ソフトウェアシステムの保守性とは、サービス/技術専門家がソフトウェアシステムをリアルタイム環境にインストールし、実行中にシステムを監視し、システムの技術的な問題を特定し、問題を解決するためのソリューションを提供する能力です。

保守性を促進するようにシステムが開発されていれば、保守性は可能です。

例： ソフトウェアの更新についてユーザーに定期的なリマインダーポップアップを提供し、問題をデバッグするためのログ/トレースメカニズムを提供し、ロールバックメカニズムによる障害からの自動回復（ソフトウェアシステムを以前の動作状態状態にロールバックします）。

別の 例 から Rediffmail。 Webベースのメールサービスのバージョンが更新された場合、システムにより、ユーザーは新しいバージョンのメールシステムに切り替えて、古いバージョンを数か月間そのままにしておくことができました。これにより、ユーザーエクスペリエンスも向上します。

＃7）適応性：

システムの適応性は、動作を変更せずに環境の変化に適応するソフトウェアシステムの能力として定義されます。

EclipseでJavaプロジェクトを開始する方法

例： 車のアンチロックブレーキシステムは、すべての気象条件（暑いまたは寒い）で標準に従って機能するはずです。別の 例 Androidオペレーティングシステムのものである可能性があります。さまざまなタイプのデバイスで使用されます。スマートフォン、タブレットコンピューター、およびインフォテインメントシステムであり、高い適応性があります。

上記の7つの非機能要件に加えて、次のような多くの要件があります。

アクセシビリティ、バックアップ、容量、コンプライアンス、データ整合性、データ保持、依存関係、展開、ドキュメント、耐久性、効率、悪用可能性、拡張性、障害管理、フォールトトレランス、相互運用性、変更可能性、操作性、プライバシー、読み取り可能性、レポート、復元力、再利用性、堅牢性、スケーラビリティ、安定性、テスト容易性、スループット、透明性、統合性。

これらの非機能要件をすべてカバーすることは、この記事の範囲外です。ただし、これらの非機能要件タイプの詳細については、 ウィキペディア。

機能要件から非機能要件を導き出す

非機能要件はさまざまな方法で導き出すことができますが、最もよく試され、テストされた方法は機能要件から導き出されます。

この記事のいくつかの場所ですでに取り上げたインフォテインメントシステムの例を見てみましょう。ユーザーは、インフォテインメントシステムで多くのアクションを実行できます。曲の変更、曲のソースのUSBからFMまたはBluetoothオーディオへの変更、ナビゲーションの宛先の設定、ソフトウェアアップデートによるインフォテインメントソフトウェアのアップデートなど。

＃1）非機能要件の収集：

機能要件の一部である、ユーザーによって実行されるタスクをリストします。 UMLユースケース図（各楕円形）にユーザーアクションが記載されたら、すべてのユーザーアクションに関連する質問（各長方形）を開始します。これらの質問への回答は、非機能要件を提供します。

＃2）非機能要件の分類：

次のステップは、質問を通じて特定した非機能要件の分類です。この段階で、考えられる回答を確認し、考えられる非機能カテゴリまたはさまざまな品質に回答を分類できます。

下の画像では、回答から特定された可能な品質属性を確認できます。

機能要件と非機能要件

機能要件と非機能要件とは何か、そしてそれらがどのように導き出されるかについては、すでに見てきました。機能要件と非機能要件の主な違いを見てみましょう。

結論

要件は、ソフトウェアシステムを開発するための基本的な構成要素を形成します。機能要件を備えたシステムを構築することは可能ですが、その能力を決定または測定することはできません。そうは言っても、高品質の動作するソフトウェアシステムを持つためには、ビジネス要件から派生した高品質の機能要件を持つことが非常に重要です。

したがって、機能要件はソフトウェアシステムの実装の方向性を示しますが、非機能要件はエンドユーザーが経験する実装の品質を決定します。

推奨読書

• ソフトウェア要件仕様（SRS）をテストする方法は？
• 機能テストと非機能テスト
• 要件なしでアプリケーションをテストする方法は？
• SDLCの要件分析と収集とは何ですか？
• 要件管理における5つの致命的な間違いとそれらを克服する方法
• 機能要件と非機能要件の特徴
• 要件トレーサビリティマトリックス（RTM）を作成する方法：サンプルとサンプルテンプレート
• トップ20以上の最高の要件管理ツール（完全なリスト）