The devil is in the details.

—Common proverb

非機能要件

非機能要件（NFR）は、ソリューションの設計をガイドし、関連するバックログ全体に対する制約となるシステム品質です。

機能要件が特定のインプットに対するシステムの応答を指定するのに対して、非機能要件は、以下のような様々なシステム品質や属性を指定するために使用されます。

パフォーマンス - システムがリクエストにどれくらい早く応答すべきか
拡張性 - システムがユーザーの増加やワークロードの増加をどれだけうまく処理できるか
セキュリティ - システムが不正アクセスやデータ侵害に対してどれだけしっかりと保護するか
ユーザビリティ - システムがどれだけ使いやすいか
保守性 - システムを更新し、変更するのはどれほど簡単か

NFRは、通常、各イテレーション、PI、またはリリースの完了の定義（DoD）の一部として再検討される持続的な品質と制約です。 NFRはチームバックログ、ARTバックログ、ソリューショントレインバックログ、そしてポートフォリオバックログに影響を与えます。

詳細

非機能要件 (NFR) は、「システム品質」を指定することを目的としており、その機能性に直接関連しないさまざまなシステムの属性です。これらの属性は、システムが何をするのかではなく、それがどれほどうまくやるのかを示します。それとは対照的に、機能要件は、ケイパビリティ、フィーチャー、そしてストーリーとして表現され、それらはシステムが様々なインプットに対してどのように反応するかを定義します。それらは些細なことに見えるかもしれませんが、NFRはシステムの成功にとって同じくらい重要です。 NFRを満たさないと、ビジネス、顧客、市場、または適用可能な規制や基準のニーズを満たさないシステムが生じる可能性があります。いくつかのケースにおいてのコンプライアンス違反は、コスト、リコール、プライバシー、セキュリティ、安全性リスク、法的リスクなど、重大な問題を引き起こすことがあります。

NFRの適切な識別と実装は重要です。ソリューションの詳細が過剰に指定されている場合、コストがかかりすぎるか、実行不可能になるかもしれません。詳細が不十分な場合、システムは意図した使用には不適切になる可能性があります。システムのスコープに関わらず、NFRを探求し、定義し、実装するための適応的でインクリメンタルなアプローチは、アジャイルチームにとって重要なスキルです。

NFRはバックログを制約する

NFRは、図1が示すように、SAFe全体のバックログに関連付けられています。しかし、NFRはバックログ項目ではありません。バックログ項目はバックログに入ってきたあと、実装されると出ていきます。 NFRは、システムの設計と開発に対する持続的な制約です。例えば、「アプリケーションスイート内のすべてのプロダクトはSAMLベースのシングルサインオンを要件とする」といった要件を考えてみてください。シングルサインオンは機能要件であり、SAML（Security Assertion Markup Language）の選択は制約です。新たなバックログ項目がサインオン機能を必要とする場合、その受け入れ基準にはSAMLを含める必要があります。

NFRは、アジャイルリリーストレイン（ART）とバリューストリームが作成するソリューションの重要な属性であるため、チーム、ART、およびソリューショントレインのバックログに影響を与えます。ポートフォリオバックログは、通常、複数のソリューションに対する品質（規制基準など）のためのNFRも必要とする場合があります。アジャイルチームは、作り込み品質の実践を用いてNFRテストを加速し、それを継続的に行います。チームは、関連するNFRを自分たちの完了の定義に含め、それをローカルの設計と実装の決定に対する制約として使用し、NFRテストの責任を負います。

図2で示されているように、NFRはバックログに対する制約としてモデル化されています。

図2 NFRはバックログと関連付けられ、システム設計を制約する

NFRは、SAFe要件モデルに説明されているように、任意のバックログ項目を制約する可能性があります。ほとんどのNFRは、システムが制約を満たしていることを確認するために、1つ以上のシステム品質テスト（理想的には自動化されたもの）を必要とします。

NFRのタイプ

一般的に、NFRには2つのタイプがあります。「システム品質」と「デザイン制約」です。それぞれが以下のセクションで説明されています。

システム品質

NFRは、しばしばさまざまシステム品質（注、英文で「..ilities」と表示される品質特性）を説明する、アーキテクチャの上で重要な要件です。それらは、バックログを通過する機能要件と同じくらい、あるいはそれ以上に重要です。プロダクトマネジメントとソリューションマネジメント、そしてチームと共に、システムアーキテクトとソリューションアーキテクトは、しばしばNFRを特定し確立する責任を負っています。図3は、開発中に考慮すべきNFRソースの比較的包括的なリストを示しています。

図3 NFRの対象となる可能性があるシステム属性の例 [1]

デザインの制約

これらのシステム品質に加えて、別のタイプのNFRがシステム設計に大きな影響を及ぼすことがあります。一部のデザイン選択肢を選ぶ自由を制限する「デザインの制約」があります。この例は以下の通りです。

システムデザインは、承認されたベンダーからのハードウェアコンポーネントのみを使用する必要がある（サイバーフィジカルシステム）
シングルサインオンはSAMLプロトコルを使用する必要がある
オープンソースのコンポーネントは、事前に法務部門による承認が必要
すべてのユーザーデータは暗号化され、企業のデータベースに保存するべきである
Java、Python、およびJavascriptプログラミング言語は一般的な使用は承認されているが、他の開発言語は事前に承認が必要

もちろん、イノベーションを支えるためには、これらは可能な限り少なく、規模の経済、セキュリティ、またはソリューションセットの他の重要な側面を提供する中央集権的な決定を反映する必要があります。

機能要件、NFR、およびデザイン制約は、システムのスコープと品質を定義します。 NFRとデザイン制約の両方を理解することで、チームはシステムの設計についてより情報に基づいた決定を下すことができ、それがステークホルダーのニーズを満たしながら、任意の制限を遵守することを確認します。

NFRを指定する

ソリューションインテントはNFRと機能要件を含み、固定対可変のソリューションインテントの経済性を理解する上で重要な役割を果たします。

ソリューションインテントは、NFR、それらが影響を与える他の仕事の項目、およびそれらを検証するテストとの間のトレーサビリティのリンクも提供できます。 NFRは、固定対可変のソリューションインテントの経済性を理解する上で重要な役割を果たします。（図4）

図4 NFRはソリューションインテントで捉えられる

他の要件と同様に、一部のNFRは事前に固定された、既知のものです（例、アドベンチャーライドは12人を収容）。一方で、他のものは可変で（最大車両負荷時の加速度は、xG以上）それらは時間とともに洗練されます。

他のすべての要件と同様に、NFRも明確さを定量化する必要があります。これにより、目標を誰もが明確に理解できます。図5は、図3で議論されたいくつかのプロパティを使用してNFRを定義する例を提供しています。

ステップ1では、その名前、規模、および測定方法を含むNFRの品質を定義する。
ステップ2では、NFRの測定可能なバリューを定量化する。これには、現在の測定されたバリュー（ベースライン）、達成するバリュー（目標）、そして受け入れられないバリュー（制約）が含まれる。

図5は、自動運転車の速度制限検出のNFRを指定する例を含んでいます。平均的に、ユーザーは現在、マイルごとに0.1回手動で速度を設定し、自動化されたソリューションの結果を置き換えます。新しいシステム機能は、マイルあたり0.01回に改善するべきですが、実装中はマイルあたり0.15回以下にする必要があります。

図5 ステップとNFRを指定する例

以下の基準はNFRを定義するのに役立ちます。

制約付き - NFRは特定の制約付きのコンテキストを持つ必要がある。例えば、飛行機の飛行制御の信頼性は、インフォテインメントシステムよりもはるかに高くなければならない。
独立性 - NFRは、他のシステム品質を考慮せずに評価し、テストできるように、互いに独立している。
交渉可能 - NFRの交渉可能性は、経済的パフォーマンスの重要な側面である。
テスト可能 - NFRは、客観的な指標でテスト可能である。

NFRはソリューション開発に影響を与える

非機能要件は、ソリューション開発とテストに大きな影響を与えることがあります。そのため、アーキテクトと開発者は、それらを指定する際に注意を払うべきです。例えば、「99.999％の可用性」という表現は素晴らしく聞こえるかもしれませんが、「99.98％の可用性」に比べ開発努力は10倍以上必要です。 NFRの影響は、要件を定義する人々によってよく理解されなければなりません。

多くの場合、セットベースデザインを適用することで、NFRを範囲（例えば、99.98や99.999）として指定することにより、複数の選択肢を持ち続けることができます。チームはソリューション領域を探索し、より良い経済的決定につながる追加の知識を得ます。 99.999の信頼性には確かにバリューがあるかもしれません。または、システムのオペレーション環境の他の部分で調整を行うことで、信頼性を下げる方がコスト効率が高いかもしれません。重量、体積、または電圧などの物理的な制約は、ソリューションの開発に同様の影響を与えます。コストとバリューをより理解するために決定を先送りすることは、しばしば経済状況を改善することにつながります。

ソリューションの経済的フレームワーク(図6)は、NFRを評価するための基準を提供します。 NFRでは、コストやその他の考慮事項とのトレードオフを考慮します。さらにNFRはサプライヤーにも影響を与え、彼らの知識と懸念はNFR要件と経済的フレームワークに反映される必要があります。

図6 NFRの経済的トレードオフの決定を導く5つの変数

NFRは、現在または将来、追加の仕事を必要とする場合があります。一度にすべて実装する必要がある場合もありますが、その他の場合、チームはインクリメンタルなアプローチを取ることができます。

一度にすべて実装 - 一部のNFRは新たな懸念事項として現れ、すぐに実装が必要となる。例えば、規制の変更により、組織は指定された時間制約内に対応することが求められ、対応できない場合、違反となるリスクがある。
ストーリーごとのインクリメンタルな実装 - その他の場合には、チームに選択肢がある。例えば、アジャイルチームは、1つのストーリーごとにパフォーマンスをインクリメンタルに改善することができる。

実装は、NFRの適切なレベルを決定するために、いくつかの学習サイクルを可能にする方法で行うべきです。 ARTの構造は、NFRの実装にも影響を与えることがあります。例えば、アーキテクチャ層を中心に組織されたARTは、NFRを実装しテストすることが難しいと感じるでしょう。主にストリーム適応チームで設計されたトレインは、NFRを実装、テスト、維持するのが容易になります。アジャイルアーキテクチャの実践を適用することで、NFRの開発を支援し、要件が進化するにつれて柔軟性を維持するのに役立ちます。

非機能要件のテスト

エクストリームプログラミングの支持者であり、『アジャイルソフトウェア開発宣言』[3]の共著者であるブライアンマリックは、アジャイルテストとテストマトリクスの先駆者となり、テストの整理に役立つ分類法を提供しました。このアプローチは、『アジャイルテスト』 [4]でさらに発展し、『アジャイルソフトウェア要件』[4, 5]で大規模実施へと拡張されました。図7は、何をテストし、いつテストするかについてのガイダンスを含む最新のマトリクス[6]を説明しています。

図7のアジャイルテストマトリクスの第4象限は、システムがそのNFRを満たすことを確認するためのシステム品質テストを概説しています。 NFRは、しばしば一連の特殊な自動テストツール（例えば、負荷とパフォーマンスのテストツール）やコンプライアンスを検証するための内部ソリューションの遠隔測定を必要とします。

図7 NFRは、アジャイルテストマトリクスの第4象限に存在する

その大規模なスコープとツールの要件のため、NFRのテストはシステムチームの助けを必要とするかもしれません。任意のシステムの変更がNFRとの適合性を侵害する可能性があるため、これらのテストは継続的に、または少なくとも実際的な場合に実行する必要があります。この作り込み品質をサポートするために、チームはNFRのテストを自動化し、他のテストと連続して実行するか、必要に応じてオンデマンドで実行するべきです。

詳しく学ぶ

[1] Non-functional requirement. Wikipedia. Retrieved October 13, 2023, from https://en.wikipedia.org/wiki/Non-functional_requirement

[2] Gilb, Tom. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Butterworth-Heinemann, 2005.

[3] Manifesto for Agile Software Development. http://AgileManifesto.org/

[4] Crispin, Lisa, and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley Professional, 2009.

[5] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.

[6] Gregory, Janet, and Lisa Crispin. More Agile Testing: Learning Journeys for the Whole Team. Addison-Wesley Professional, 2014.

Leffingwell, Dean, and Ryan Shriver. Nonfunctional Requirements (System Qualities) Agile Style. Agile 2010.

最終更新: 2023年10月13日