inhouse_se
inhouse_se 非機能要件一覧をユーザーに決めてもらうために、次の方法を推薦する。主なステークスホルダーに最終的なリストから最も重要な3つの特性を(順位をつけずに)選んでもらう

非機能要件を書き出すコツ(事例あり)

## 非機能要件一覧をユーザーに出してもらう方法
非機能要件一覧をユーザーに決めてもらうために、次の方法を推薦する **主なステークスホルダーに最終的なリストから最も重要な3つの特性を(順位をつけずに)選んでもらう** この方が合意を得やすいだけでなく、何が最も重要かの議論を促進し、アーキテクトが重要なアーキテクチャ決定を下す判断のトレードオフ分析に役立つ。 逆に、ステークスホルダーに対して全ての非機能要件を優先順位付けするのはお勧めしない。優先順位付けに対してステークスホルダーは大抵反対するからだ。 この場合、順位を付けずに3つだけ選んでもらうことが重要である。 https://www.altexsoft.com/blog/non-functional-requirements/ 非要件定義一覧
### アーキテクトとステークスホルダーの共通言語
ほとんどの非機能要件は事業のステークス掘るあーの声に耳を傾け、ともに協力して事業の観点から重要な項目をもとに決定される これは簡単なように見えるが、トラブルを招きやすい段階でもある 問題は、**アーキテクトとステークスホルダーが異なる言語を話すということにある** - アーキテクトは、スケーラビリティ、相互運用性、耐障害性、学習用意性、可用性について語る - ステークスホルダーは、合併や買収、ユーザーの満足度、市場投入までの時間、競争上の優位性について語る すると、アーキテクトとステークスホルダーの話が噛み合わなくなるのだ。 - アーキテクトは、ユーザーの満足度をサポートするためのアーキテクチャの作成方法がわからないし - ステークスホルダーは、なぜアプリケーションの可用性、相互運用性、学習用意性、耐障害性にこれほど議論が必要なのかがわからない 対応方法は、ドメインの関心ごとからアーキテクチャの対応表を使用することだ |ドメインの関心ごと| アーキテクチャ特性| |:----|:----| |合併・買収| 相互運用性、スケーラビリティ、適応性、拡張性| |市場投入までの時間| アジリティ、テスト容易性、デプロイ容易性| |ユーザー満足度| パフォーマンス、可用性、耐障害性、テスト用意性、デプロイ容易性、アジリティ、セキュリティ| |競争優位性| アジリティ、テスト用意性、デプロイ容易性、スケーラビリティ、可用性、耐障害性| |時間と予算| シンプルさ、フィジビリティ|
### アーキテクトは一つの要素だけを見て判断してはいけない(具体例あり)
一つの要素だけに焦点を当てるのは、下手なアーキテクトが行ってしまうミスの一つだ ステークスホルダーが「規制要件のために、ファンドの最終価格設定を時間通りに完了させることが絶対に必要だ」と言ったとする。 下手なアーキテクトは、ドメインの関心事に基づいて、第一に考えるべきことはパフォーマンスだと判断したとする。 しかし、その判断をしたアーキテクチャは多くの理由から失敗するだろう 1. 必要なときに利用できなければ、どれだけ早くても意味がない(可用性) 2. ドメインが成長してより多くのファンドが得られたとしても処理が時間内容完了するように、拡張できなければ限界を迎える(スケーラビリティ) 3. システムは単に利用可能なだけでなく、計算中にシステムダウンしないように信頼性が高くなければならない(信頼性) 4. ファンドの最終価格決定処理で85%まで完了した際にクラッシュしてしまったら、途中から処理を再開できる必要がある(回復性)。 5. ファンド価格が正しく計算されていなければ意味がない(監査可能性) これらの理由から、アーキテクトはパフォーマンスに加えて、可用性、スケーラビリティ、信頼性、回復性、監査可能性 にも対応しなければならない
## 非機能要件洗い出し手順(具体例あり)
### シリコンサンドイッチ
|項目| 詳細| |:----|:----| |記述| 全国展開しているサンドイッチ店が、オンライン注文を実装したい| |ユーザー数| 数千、数万| |要件1| ユーザーが注文する時、道順を指し示すこと| |要件2| 店舗が宅配サービスを行なっている場合には、届け先にサンドイッチを提供する| |要件3| モバイル端末でのアクセシビリティ| |要件4| 全国向けにデイリープロモーション用メニューを提供する| |要件5| エリア限定メニューもが存在する| |要件6| オンラインか直接、または配達時の支払いが可能。| |追加コンテキスト1| サンドイッチ店はフランチャイズ| |追加コンテキスト2| 親会社は近日中に海外展開を視野に入れている| |追加コンテキスト3| 安い労働力で利益を最大化するのが企業のモットー|
### 最初の要件はスケーラビリティと弾力性
アーキテクトが最初に着目するべき点はユーザー数だ。 現在は数千人だが、将来的には数百万人を視野に入れている。 ここはとても野心的なサンドイッチ店だ。 |要件2| 店舗が宅配サービスを行なっている場合には、届け先にサンドイッチを提供する| |:----|:----| **スケーラビリティ**は際上位のアーキテクチャ特性の一つだ。 また、リクエストのバーストにも対応できる能力、**弾力性**も必要となるだろう。 この二つは似ているが、異なる制約を持っている - スケーラビリティは同時使用ユーザー数で緩やかに変化するものだ。ホテルの予約システムでは特別な販売やイベントがない限り、ユーザー数の増加は一定であるはずである。 - 弾力性は、ユーザー数のバーストに耐えられるかどうかの指標だ。同時接続数と言っても良い。チケットの販売システムや株価など即時性が求められるシステムではユーザー数が少ない状態から一気にバーストすることが多々ある。 今回の場合、弾力性についての要件は明示されていないが、暗黙的な要件として認識しておく必要はあるだろう。 食事の時間帯のトラフィックのバーストの可能性は否定できないからだ。
### 次の要件はパフォーマンス
|要件3| モバイル端末でのアクセシビリティ| |:----|:----| この要件は主にアプリケーションの設計に影響を与える。 sこの要件は、ポータブルなWebサイトかさまざまなモバイル端末向けのネイティブアプリケーションを構築することを示している。 しかし、アプリケーションのシンプルさを考えると、複数のプラットフォームに対応する必要はなさそうだ。設計としてはモバイルに最適化されたWebアプリケーションが選ばれるだろう。 したがって、アーキテクトは、ページの読み込みをはじめとするモバイル特有の性質向けに、パフォーマンスに関わるいくつかのアーキテクチャ特性を定義したいと思うかもしれない。この部分については後ほどUXデザイナーやステークスホルダーと協力して決定する必要がある。 ここから弾き出した三つ目の非機能要件はパフォーマンスだ。 ピーク時にパフォーマンスが悪いサンドイッチ店でサンドイッチを買いたいという人はいない。 パフォーマンスの概念についての詳しい説明はここでは省く。
### カスタマイズ性
サンドイッチのプロジェクトで最後にサポートする必要のある要件は、カスタマイズ性だ。 |項目| 詳細| |:----|:----| |要件4| 全国向けにデイリープロモーション用メニューを提供する| |要件5| エリア限定メニューもが存在する| |追加コンテキスト2| 親会社は近日中に海外展開を視野に入れている| これらの項目は、レシピや地域販売、トラフィック情報など問題領域のいくつかの箇所には場所によって変更されるであろうカスタム動作の提供が含まれる。 であれば、アーキテクチャにはカスタム動作を容易にする能力を備えておく必要がある。
### 暗黙的な非機能要件
非機能要件の多くは、重要な構成要素であるにもかかわらず要件文書で指定されることはない。 - 可用性 可用性とは、ユーザーがサンドイッチ店のサイトに確実にアクセスできるということだ。 - 信頼性 信頼性とは、ユーザーがサイトとやりとりをしている間、サイトが稼働し続けることだ。 接続が断続的に切れて、何度もログインし直さなければならないようなサイトから何かを購入したいと思う人は少ないだろう。 - セキュリティ 全てのシステムが持つ暗黙的な特性だ。 とはいえ、セキュリティは知名度によって優先順位をつけることは可能であり、そのことはアーキテクチャの定義と結びつく。 サンドイッチの店の場合、決済をサードパーティに任せると考える可能性がある。
## 最後にやるべきこと:最も重要でない非要件を決定する
一旦日要件定義を明らかにした後に、チームが行うと効果的なのは、最も重要でない非要件を決定することだ。 サンドイッチの場合ならば、ソリューションはカスタマイズ性とパフォーマンスのどちらかを犠牲にすることかもしれない。 いずれの場合も正解ではなく、ただのトレードオフであることを肝に銘じておくこと。
## 非機能要件を書き出す方法(事例あり)
title:非機能要件を書き出すコツ(事例あり) description:非機能要件一覧をユーザーに決めてもらうために、次の方法を推薦する。主なステークスホルダーに最終的なリストから最も重要な3つの特性を(順位をつけずに)選んでもらう category_script:True img:https://www.altexsoft.com/media/2019/11/key-types-of-non-functional-requirements.png