非機能要件とは
非機能要件とは次の3つを満たすものと呼ばれます。
ドメインによらない、設計に関する考慮事項を明らかにするもの
設計の構造的な側面に影響を与えるもの
アプリケーションの成功に必要か重要なもの
要するに、機能以外のアプリケーションの構造に影響を与えかつサービスの成功基準となるものです。
以下はIPAによる非機能要件のイメージです。
非機能要件一覧をユーザーに出してもらう方法
非機能要件一覧をユーザーに決めてもらうために、次の方法を推薦します。
主なステークスホルダーに最終的なリストから最も重要な3つの特性を（順位をつけずに）選んでもらう
この方が合意を得やすいだけでなく、何が最も重要かの議論を促進しアーキテクトが重要なアーキテクチャ決定を下す判断のトレードオフ分析に役立ちます。
逆に、ステークスホルダーに対して全ての非機能要件を優先順位付けするのは主観的にはお勧めできません。なぜなら、優先順位付けに対してステークスホルダーは大抵反対するからです。
この場合、順位を付けずに3つだけ選んでもらうことが重要です。
https://www.altexsoft.com/blog/non-functional-requirements/
非要件定義一覧
アーキテクトとステークスホルダーの共通言語
ほとんどの非機能要件は事業のステークスホルダーの声に耳を傾け、協力して事業の観点から重要な項目をもとに決定されるはずです。
これは簡単なように見えるが、トラブルを招きやすい段階でもあることに注意しなければなりません。
問題は、アーキテクトとステークスホルダーが異なる言語を話すということにある
例えば、
アーキテクトは、スケーラビリティ、相互運用性、耐障害性、学習用意性、可用性について語る
ステークスホルダーは、合併や買収、ユーザーの満足度、市場投入までの時間、競争上の優位性について語る
すると、アーキテクトとステークスホルダーの話が噛み合わなくなるのだ。
また、それぞれが持っている知識もことなります。
アーキテクトは、ユーザーの満足度をサポートするためのアーキテクチャの作成方法がわからないし
ステークスホルダーは、なぜアプリケーションの可用性、相互運用性、学習用意性、耐障害性にこれほど議論が必要なのかがわからない
対応方法は、ドメインの関心ごとからアーキテクチャの対応表を使用することです。
次の表を片手に非機能要件を絞り込むことをお勧めします。
|:----|:----|
|合併・買収| 相互運用性、スケーラビリティ、適応性、拡張性|
|市場投入までの時間| アジリティ、テスト容易性、デプロイ容易性|
|ユーザー満足度| パフォーマンス、可用性、耐障害性、テスト用意性、デプロイ容易性、アジリティ、セキュリティ|
|競争優位性| アジリティ、テスト用意性、デプロイ容易性、スケーラビリティ、可用性、耐障害性|
|時間と予算| シンプルさ、フィジビリティ|
アーキテクトは一つの要素だけを見て判断してはいけない(具体例あり)
一つの要素だけに焦点を当てるアーキテクトもいますが、これはうまくいかないことがほとんどでしょう。
例えば以下のケースでは、アーキテクトがパフォーマンスのみに焦点を当てたために、後々に失敗を招いてしまいます。
ステークスホルダーが「規制要件のために、ファンドの最終価格設定を時間通りに完了させることが絶対に必要だ」と言ったとする。
下手なアーキテクトは、ドメインの関心事に基づいて、第一に考えるべきことはパフォーマンスだと判断したとする。
しかし、その判断をしたアーキテクチャは多くの理由から失敗する可能性が高いです。
必要なときに利用できなければ、どれだけ早くても意味がない(可用性)
ドメインが成長してより多くのファンドが得られたとしても処理が時間内容完了するように、拡張できなければ限界を迎える(スケーラビリティ)
システムは単に利用可能なだけでなく、計算中にシステムダウンしないように信頼性が高くなければならない(信頼性)
ファンドの最終価格決定処理で85%まで完了した際にクラッシュしてしまったら、途中から処理を再開できる必要がある(回復性)。
ファンド価格が正しく計算されていなければ意味がない(監査可能性)
これらの理由から、アーキテクトはパフォーマンスに加えて、可用性、スケーラビリティ、信頼性、回復性、監査可能性
にも対応しなければならないことがわかります。
非機能要件洗い出し手順(具体例あり)
シリコンサンドイッチ
|項目| 詳細|
|:----|:----|
|記述| 全国展開しているサンドイッチ店が、オンライン注文を実装したい|
|ユーザー数| 数千、数万|
|要件1| ユーザーが注文する時、道順を指し示すこと|
|要件2| 店舗が宅配サービスを行なっている場合には、届け先にサンドイッチを提供する|
|要件3| モバイル端末でのアクセシビリティ|
|要件4| 全国向けにデイリープロモーション用メニューを提供する|
|要件5| エリア限定メニューもが存在する|
|要件6| オンラインか直接、または配達時の支払いが可能。|
|追加コンテキスト1| サンドイッチ店はフランチャイズ|
|追加コンテキスト2| 親会社は近日中に海外展開を視野に入れている|
|追加コンテキスト3| 安い労働力で利益を最大化するのが企業のモットー|
最初の要件はスケーラビリティと弾力性
アーキテクトが最初に着目するべき点はユーザー数です。
現在は数千人だが、将来的には数百万人を視野に入れている、とても野心的なサンドイッチ店です。
|要件2| 店舗が宅配サービスを行なっている場合には、届け先にサンドイッチを提供する|
|:----|:----|
また、スケーラビリティは最上位のアーキテクチャ特性の一つだ。
また、リクエストのバーストにも対応できる能力、弾力性も必要となるだろう。
この二つは一見似ているようで異なる制約を持っています。
スケーラビリティは同時使用ユーザー数で緩やかに変化するものだ。ホテルの予約システムでは特別な販売やイベントがない限り、ユーザー数の増加は一定であるはずである。
弾力性は、ユーザー数のバーストに耐えられるかどうかの指標だ。同時接続数と言っても良い。チケットの販売システムや株価など即時性が求められるシステムではユーザー数が少ない状態から一気にバーストすることが多々ある。
今回の場合弾力性についての要件は明示されてはいませんが、暗黙的な要件として認識しておき再度確認する必要があるでしょう。
なぜなら、食事の時間帯のトラフィックのバーストの可能性は否定できないからです。
次の要件はパフォーマンス
|要件3| モバイル端末でのアクセシビリティ|
|:----|:----|
この要件は主にアプリケーションの設計に影響を与える内容です。
この要件は、ポータブルなWebサイトかさまざまなモバイル端末向けのネイティブアプリケーションを構築することを示しています。
しかし、アプリケーションのシンプルさを考えると、複数のプラットフォームに対応する必要はなさそうです。
設計としてはモバイルに最適化されたWebアプリケーションが最適ですね。
したがって、アーキテクトは、ページの読み込みをはじめとするモバイル特有の性質向けに、パフォーマンスに関わるいくつかのアーキテクチャ特性を定義したいと思うかもしれません。この部分については後ほどUXデザイナーやステークスホルダーと協力して決定する必要があるでしょう。
ここから弾き出した三つ目の非機能要件はパフォーマンスです。
ピーク時にパフォーマンスが悪いサンドイッチ店でサンドイッチを買いたいという人はいないでしょう。
パフォーマンスの概念についての詳しい説明はここでは省くとします。
カスタマイズ性
サンドイッチのプロジェクトで最後にサポートする必要のある要件は、カスタマイズ性です。
|項目| 詳細|
|:----|:----|
|要件4| 全国向けにデイリープロモーション用メニューを提供する|
|要件5| エリア限定メニューもが存在する|
|追加コンテキスト2| 親会社は近日中に海外展開を視野に入れている|
これらの項目は、レシピや地域販売やトラフィック情報など問題領域のいくつかの箇所には場所によって変更されるであろうカスタム動作の提供が含まれます。
であれば、アーキテクチャにはカスタム動作を容易にする能力を備えておく必要があるでしょう。
暗黙的な非機能要件
非機能要件の多くは、重要な構成要素であるにもかかわらず要件文書で指定されることはありません。
可用性
可用性とは、この場合ユーザーがサンドイッチ店のサイトに確実にアクセスできるということです。（たとえAWSの東京リージョンが吹っ飛んでも）
信頼性
信頼性とは、ユーザーがサイトとやりとりをしている間、サイトが稼働し続けることです。
接続が断続的に切れて、何度もログインし直さなければならないようなサイトから何かを購入したいと思う人は少ないでしょう。
セキュリティ
全てのシステムが持つ暗黙的な特性です。
とはいえ、セキュリティは知名度によって優先順位をつけることは可能であり、そのことはアーキテクチャの定義と結びつきます。
サンドイッチの店の場合、決済をサードパーティに任せると考える可能性がある。
最後にやるべきこと：最も重要でない非要件を決定する
一旦日要件定義を明らかにした後に、チームが行うと効果的なのは、最も重要でない非要件を決定することです。
サンドイッチのECサイトのケースならば、ソリューションはカスタマイズ性とパフォーマンスのどちらかを犠牲にすることかもしれません。
いずれの場合も正解ではなく、ただのトレードオフであることを肝に銘じておくこと。
非機能要件一覧
以下が、システムが担保できる非機能要件の一覧です。
非機能要件に所属する全ての能力は主に次の3つに分類されます。
アーキテクトは全ての要件を完全なレベルでサポートする必要はなく、トレードオフに基づいて取捨選択されます。
アーキテクチャ運用特性一覧
アーキテクチャの運用特性は、パフォーマンス、スケーラビリティ、弾力性、可用性、信頼性といった能力を対象としています。
システムが稼働している際にどれぐらいの能力を持てば対応できるのかの判断につながる指標です。
可用性
システムがどのくらいの期間利用できるか(24時間365日運用する場合には、障害が発生した場合の対応措置も含められる)
継続性
障害復旧能力のことです。
たとえ障害が起きても1秒で回復すれば問題はないでしょう。
パフォーマンス
ストレステスト、ピーク分析、使われる機能の使用頻度などをもとにした、必要となる容量のことです。
応答時間の分析などもここに含まれます。
回復性
処理の持続性要件のことです。例えば、
災害時にシステムをどれだけ早くオンラインに戻す必要があるのか。
など。
データのバックアップ戦略やハードウェア複製の要件に影響する内容でもあります。
信頼性/安全性
システムがフェイルセーフである必要があるか、人命に関わるようなミッションクリティカルなものであるかを評価します。
障害が発生したときに多額の費用が会社にかかるのだろうか。
エレベーターをコントロールするOSがwindows98だったら嫌ですよね。
堅牢性
実行中にインターネットが切れた場合や、停電やハードウェア障害が発生した場合に、エラーや境界条件を処理できるかどうかの能力です。
依存する要素が少なければ堅牢性は上がります。
スケーラビリティ
ユーザー数やリクエスト数が増えてもシステムが動作することです。
アーキテクチャ構造特性
アーキテクトは、コードの構造にも注目しなければなりません。
優れたモジュール性、生業されたコンポーネント間の結合、読みやすいコード、その他多くの内部的な品質評価が求められます。
構成用意性
エンドユーザーがソフトウェアの設定を簡単に変更できること。
configファイルなどを使わず、ソースコードに設定をハードコードディングしたシステムは構成用意性は低いでしょう。
反対にノーコードツールはなんでもできると言えますが、構成用意性が高すぎてユーザーでやるべきことが多すぎると言えるでしょう。
拡張性
新しい機能をプラグインで追加可能にすることを示します。
プラグインアーキテクチャは拡張性が最大限のモノシリックなアーキテクチャですね。
https://minegishirei.hatenablog.com/entry/2023/01/28/110836
インストール容易性
必要な全てのプラットフォームへのインストールの容易さのことです。
C#で作られたシステムをlinuxで動かすのは難しいですし、webはブラウザさえあればどこでも動かせられますのでインストール容易性は高いですね。
活用性/再利用性
複数の製品で共通のコンポーネントを利用できること。
ETLツールなどで使われるパイプラインアーキテクチャでこの項目が最大限でしょう。
https://minegishirei.hatenablog.com/entry/2023/01/28/101928
ローカライゼーション
データフィールドの入力画面や問い合わせ画面、レポート、マルチバイト文字の要件、
単位や通貨などが他言語に対応していること。
こちらもプラグイン形式で導入されることが多いです。
https://minegishirei.hatenablog.com/entry/2023/01/28/110836
メンテナンス容易性
変更の適用やシステムの拡張がどれだけ容易に行えるか。
拡張性と被るところもありますが、こちらはどちらかといえば運用目線の項目だ。
可搬性
システムは複数のプラットフォームで動作する必要があるかどうかの指標です。
Linux OSだけでなく、WindowsやMacOSに対応しているか?
webアプリであればそもそもどのプラットフォームでも動きますが、ネイティブアプリならではのメリットもあるので一概に評価できません。
アップグレード容易性
サーバーやクライアント上で、アプリケーション/ソリューションの旧バージョンから
新バージョンへのアップグレードを簡単/迅速に行える能力のことです。
プラットフォームに強く依存するアプリ（iOSアプリなど）ではこの項目はかなり強く吟味しなければなりません。
そのほかの非機能要件
多くの非機能要件が簡単に分類できる一方で、分類できないが重要な設計上の制約や考慮事項を形成するものも多い。
ここでは技術や運用目線、システムの要件などの分類以外の要件を提示します。
アクセシビリティ
色覚障害や難聴などの障害を持つユーザーへの配慮が必要かどうかという観点です。
認証
ユーザーが何者かを確認するためのセキュリティ要件。
認証
ユーザーが特定のアプリケーションの機能のみにアクセスするコオtができるというセキュリティ要件。
合法性
システムはどのような法的制約の中で運用されているのか、満たすべき要件。
などなど。
医療用のソフトウェアの販売はこれに該当しないかどうかを確認しなければなりません。
プライバシー
個人情報などが外部から遮断されているかどうかという要件です。
従業員から取引を隠せるか（取引が暗号化されていて、DBAやネットワークアーキテクチャでさえも取引をみることができなくなっているか）も確認しなければなりません。
セキュリティ
データベース内でデータを暗号化する必要があるか?
社内システム間の通信を暗号化する必要があるか？
サポート用意性
アプリケーションにはどの程度の技術的なサポートが必要か＞
デバッグ可能性
ログのレベル
などなど
ユーザービリティ
ユーザー目線でのアプリケーションを使いこなすために必要なトレーニングのレベル
まとめ
非機能要件に所属する全ての能力は主に次の3つに分類されます。
page:https://minegishirei.hatenablog.com/entry/2023/02/07/141149
edit:20240508 非機能要件のCTRが著しく低いため改修
