私は機能中毒者だった。ジェームス・テイラ

非機能要求の概要

非機能要求(NFR、もしくはシステム品質)は安全性、信頼性、保守性、拡張性、可用性など(しばしば、「……性」)のようなシステムの属性として説明される。システムの設計に関して、非機能要求はシステム設計上の制約や制限になる可能性もある(この場合、設計制約と呼ばれているかもしれない)。これらの要件は、システム全体の使いやすさと有効性を保証するものであり、機能的なフィーチャーやユーザーストーリーと同じくらい重要である。これらの要求のいずれかを満たさない場合には、内部ビジネス、ユーザーや市場のニーズや規制、そして標準機関によって課した要件を満たさないシステムになる結果となる。
非機能要求は、機能要件と異なって、永続的な品質と制約であり、通常各反復もしくはリリース(PI)における「完了の定義」の一部として見直される。
SAFeでは、NFRはチーム、プログラムとポートフォリオの3つのレベルで存在する。ポートフォリオレベルの非機能要求は、複数のプログラムに適用される。プログラムレベルの非機能要求は、1つのプログラムに適用され、よりきめ細かなチームレベルの非機能要求に分解し、関連のプログラムにあるチームに適用される。

詳細

さまざまな非機能要求

従来では、システム利用において、全体的な適合性に影響を与える、すべての種類の要求を考慮する手段の1つとしては、頭文字「FURPS」により考える方法がある。これは、機能(Functionality)、使いやすさ(Usability)、信頼性(Reliability)、性能(Performance)、サポートのしやすさ(Supportability)を意味している(参考文献[1])。機能要求は大いにユーザーストーリーフィーチャーで表現される。「URPS」はNFRのプレースホルダーである。それぞれ少し違うかもしれないが、NFRはシステムの成功に、機能要求と同様に重要である。1つの観点では、これらの項目は新たな開発への制約と考えられる。各々がこれらで構築されるシステムの一部分に対して、その設計の自由度をある程度減らすものである。例えば「スイート内の全プロダクトでSAMLベースのシングルサインオンを実装しなければならない」(この場合、SSOは機能要求であり、それに基づくSAMLが制約である)。非機能要求はビジネス上の重要な課題を幅広い範囲でカバーできる。これらの課題は機能要件によってうまく対処されていない。システム設計者への備忘録として、これらの潜在的な要件の十分詳細なリストを図1で示す。

 図1. 非機能要求の例(参考文献[1])

図1. 非機能要求の例(参考文献[1])

各レベルにある非機能要求

図2に示すように、非機能要求はSAFeの3つのレベルで存在する。

Figure 2. NFRs occur at all three levels

図2. NFRが3つのレベルに存在する

システム品質は確実にプログラムが作業しているソフトウェアシステムのレベルに存在するため、プログラムレベルがNFRに対する最も分かりやすい場所であるかもしれない。しかしながら、実装やプロセスの観点から、チームレベルで見えたNFRが重要である。実は、品質の作りこむ方法を促進し、NFRテストの後回しあるいはシステムチームへの任せっぱなしを防ぐため、すべてではないかもしれないが、ほとんどのプログラムのNFRはチームレベルによって受け継がれなければならない。アジャイルチームは関連のあるプログラムレベルのNFRを自分たちの完了の定義に取り入れ、設計と実装に関する局所の意思決定時に制約として利用し、また、自分たちで一定的なNFRテストを実行する。これは共通なよいルールである。もし、チームがこのルールを適用できない場合、主要なNFRに満たせないコードを開発してしまう可能性がある。また、プロセスの後期でNFRを追加するために(可能な場合)、かなりコストがかかるだろう。

ポートフォリオレベルにも同様に一定的なNFRが必要だろう。これは主にシステムを横断する固有な品質のためである。例えば、シングルサインオンの場合、オープンソースの利用に関する制限、共通のセキュリティ要件、規制の標準など。特定のポートフォリオレベルのNFRがまだ整っていないという多く場合、それを実装のため、おそらくアーキテクチャーエピックが利用されるだろう。また、ポートフォリオレベルのNFRはビジネスやアーキテクチャーエピックの成功基準上に自然に表れるかもしれない。

 バックログの制約としてのNFR

図3に示すように、SAFeでは、非機能要求はバックログへの制約と考えられる。

 図3. NFR制約を持つバックログ

図3. NFR制約を持つバックログ

SAFeの要求メタモデルでモデリングされたように、特定の非機能要求は件~複数件のバックログ項目に対する制約であるかもしれない。システムが制約を満たすことを確認するため、数多くの非機能要求は1回~複数回のシステム品質テストが必要である。図4に示す。

 図4. バックログ項目、非機能要求とシステム品質テストの関連性

図4. バックログ項目、非機能要求とシステム品質テストの関連性

非機能要求とアジャイル分析

このような制約を課すことによって、非機能要求はシステム機能性に幅広い範囲で影響を与えるかもしれない。また、それはアジャイル分析にて重要な要素である。特に、以下の作業は明示的に非機能要求として考慮に入れなければならない。

非機能要求の定義

適切に非機能要求を定義するために、以下の基準を考慮に取り入れなければならない。

  • 境界を作る。境界の文脈が欠けた場合、一部の非機能要求は不適切となる(ひどい場合害になる)。例えば、性能に関する考慮はメインのアプリケーションにとって非常に重要だが、システム管理とサポートアプリケーションにとって、不適切である(あるいは高価すぎる)
  • 独立する。非機能要求はお互い独立していなければならない。それにより、他のシステム品質を考慮せずに、あるいは影響を出さずに、評価とテストができる。
  • 交渉可能である。非機能要求のビジネス駆動力と境界の文脈に対する理解から交渉可能性が生まれる。「99.9999%の可用性」のような簡単な文は、「99.999%の可用性」より桁違い大きいので、工数を増加させる可能性がある。年間稼働時間の8時間の追加分は余分な10倍の工数に値するか?もしそうであれば、そうしよう。それ以外の場合……
  • テスト可能である。テストできない場合、出荷できない。そのため、非機能要求は、客観的な、測定可能なかつテスト可能な基準で記載しなければならない。

実装のアプローチ

非機能要求を満たすために、(現在、もしくは将来的に)いくつかの作業を行うことを規定している。即時に非機能要求を実装しなければならない場合があっても、チームはよりインクリメンタルなアプローチで取り組むことができる場合もある。

  1. すべて即時に実装する。一部の非機能要求は新しく、差し迫ったアーキテクチャーフィーチャーとして現れる。理論的には交渉できたり、できなかったりするだろうが、とにかく、今、それらを行わなければならない。例えば、金融派生商品取引の新たな規制には、すぐに対応しない場合、会社が市場から完全に排除される、あるいは、規制違反を引き起こす可能性がある。
  2. 個々のストーリーをインクリメンタルに実装する。場合によって、チームには選択肢がある。例えば、図5に示すように、「持続的な性能の向上」に関するニーズについて、1回1つのストーリーで、時間とともに対処していくことができる。
図5. システムにNFRを適用する時のインクリメンタルなシナリオ

図5. システムにNFRを適用する時のインクリメンタルなシナリオ

非機能要求のテスト

図6. アジャイルテストの4象限(参考文献[1]と[2]から引用)

図6. アジャイルテストの4象限(参考文献[1]と[2]から引用)

図6に示すアジャイルテストの4象限(参考文献[1]と[2])の観点から見るのが、非機能要求のテストを見るには最もよい。象限4、システム品質テストはほとんどの非機能要求テストの基礎である。これらテストスコープと重要性によって、非機能要求テストは、迅速かつ信頼性の高いテストが開発を高速化させることから、多くの場合、システムチームとアジャイルチーム間のコラボレーションを必要とする。予期せぬ技術的負債の拡大防止のために、可能な限り、チームはこれらのテストを自動化する。また、少なくともオンデマンドで対応しなければならない。

 図7. より実践的なNFRテスト戦略を作成するために、システムチームとアジャイルチームは協力し合う

図7. より実践的なNFRテスト戦略を作成するために、システムチームとアジャイルチームは協力し合う

しかしながら、時間がたつにつれて、回帰テストの累積成長率は、テストを自動化していた場合であっても、あまりにも多くのリソースと処理時間を消費するかもしれない。最悪の場合、非機能テストが、ある特定の場面でしか実用的ではない、または特殊なリソースや人でないと実施できないかもしれないことを意味する。図7に示されているように、実用性と継続的な使用を担保するために、チームは多くの場合、削減したテストスイートとテストデータを作成しなければならない。上記はアイデアに過ぎないように見えるかもしれないが、実際にシステムの品質向上に有益なものであり得る。

  • チームがローカルで削減したテストスイートを適用できる時、テストデータやテストアプローチでの不整合を発見することができる。
  • チームは、新しいユニークなテストを作成することがあり、そのいくつかは、システムチームによって採用され、大きなセットを構築するのに役立つ。
  • テストインフラ及び構成は、継続的に改善されるようにする。
  • チームは非機能要求の影響への実用的な理解を得る。その理解がビジネスとアーキテクチャーフィーチャーの見積もりを向上させるに役に立つ。

しかし、それでも、いくつかケースでは、非機能要求がテストできる環境を、日次的にチームが用意できない場合がある(例:車両誘導ソフトのフィールドテスト)。これらのケースでは、以下のアプローチが利用できる(参考文献[3])。

  • 仮想化されたハードウェアを利用する
  • シミュレーターを作成する
  • 類似する環境を構築する

すべての場合において、効率的に非機能要求をテストすることには、いくつかの思考と創造力が必要である。そうしないと、高コストで重いテストが実質的な技術的負債のリスクを増加させるかもしれない。最悪の場合、システム障害を招くかもしれない。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Crispin, Lisa & Gregory, Janet. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009.(邦訳:実践アジャイルテスト テスターとアジャイルチームのための実践ガイド、翔泳社、2009)

[3] Larman, Craig & Vodde, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.

Last update 11 June, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.