inhouse_se
inhouse_se 非機能要件とは、要するに**機能以外のアプリケーションの構造に影響を与えかつサービスの成功基準となるもの**である

非機能要件一覧

# 非機能要件とは 非機能要件とは、次の3つを満たすものである。 - ドメインによらない、設計に関する考慮事項を明らかにするもの - 設計の構造的な側面に影響を与えるもの - アプリケーションの成功に必要か重要なもの 要するに、**機能以外のアプリケーションの構造に影響を与えかつサービスの成功基準となるもの**である IPAの非機能要件 # 非機能要件一覧
## アーキテクチャ運用特性一覧
アーキテクチャの運用特性は、パフォーマンス、スケーラビリティ、弾力性、可用性、信頼性といった能力を対象としている。
### 可用性
システムがどのくらいの期間利用できるか(24時間365日運用する場合には、障害が発生した場合の対応措置も含められる)
### 継続性
障害復旧能力
### パフォーマンス
ストレステスト、ピーク分析、使われる機能の使用頻度などをもとにした、必要となる容量、応答時間の分析などが含まれる
### 回復性
処理の持続性要件 ``` 災害時にシステムをどれだけ早くオンラインに戻す必要があるのか。 ``` データのバックアップ戦略やハードウェア複製の要件に影響する内容でもある
### 信頼性/安全性
システムがフェイルセーフである必要があるか、人命に関わるようなミッションクリティカルなものであるかを評価する。 障害が発生したときに多額の費用が会社にかかるのだろうか。
### 堅牢性
実行中にインターネットが切れた場合や、停電やハードウェア障害が発生した場合に、エラーや境界条件を処理できるかどうか。
### スケーラビリティ
ユーザー数やリクエスト数が増えてもシステムが動作すること
## アーキテクチャ構造特性
アーキテクトは、コードの構造にも注目しなければならない。 優れたモジュール性、生業されたコンポーネント間の結合、読みやすいコード、その他多くの内部的な品質評価が求められる。
### 構成用意性
エンドユーザーがソフトウェアの設定を簡単に変更できること。
### 拡張性
新しい機能をプラグインで追加可能にすること。
### インストール容易性
必要な全てのプラットフォームへのインストールの容易さ
### 活用性/再利用性
複数の製品で共通のコンポーネントを利用できること。
### ローカライゼーション
データフィールドの入力画面や問い合わせ画面、レポート、マルチバイト文字の要件、 単位や通貨などが他言語に対応していること
### メンテナンス容易性
変更の適用やシステムの拡張がどれだけ容易に行えるか。
### 可搬性
システムは複数のプラットフォームで動作する必要があるか? Linux OSだけでなく、WindowsやMacOSに対応しているか?
### アップグレード容易性
サーバーやクライアント上で、アプリケーション/ソリューションの旧バージョンから 新バージョンへのアップグレードを簡単/迅速に行える能力
## アーキテクチャの横断的特性
多くの非機能要件が簡単に分類できる一方で、分類できないが重要な設計上の制約や考慮事項を形成するものも多い。
### アクセシビリティ
色覚障害や難聴などの障害を持つユーザーへの配慮
### 認証
ユーザーが何者かを確認するためのセキュリティ要件
### 認証
ユーザーが特定のアプリケーションの機能のみにアクセスするコオtができるというセキュリティ要件
### 合法性
システムはどのような法的制約の中で運用されているのか - データ保護 - 米企業改革法 - GDPR などなど
### プライバシー
従業員から取引を隠せるか(取引が暗号化されていて、DBAやネットワークアーキテクチャでさえも取引をみることができなくなっているか)
### セキュリティ
データベース内でデータを暗号化する必要があるか? 社内システム間の通信を暗号化する必要があるか?
### サポート用意性
アプリケーションにはどの程度の技術的なサポートが必要か> - デバッグ可能性 - ログのレベル などなど
### ユーザービリティ
ユーザー目線でのアプリケーションを使いこなすために必要なトレーニングのレベル  
## 非機能要件一覧
title:非機能要件一覧 description:非機能要件とは、要するに**機能以外のアプリケーションの構造に影響を与えかつサービスの成功基準となるもの**である category_script:True img:https://www.ipa.go.jp/files/000066109.png