非機能要件（NFR）作成ルール

本ドキュメントは、品質保証・運用設計・テスト設計のために 非機能要件（Non-Functional Requirements: NFR）を統一形式で記述する標準ルールです。 NFR は「性能・可用性・セキュリティ等の品質要求」を、測定可能・検証可能な形で定義し、後工程（設計・実装・運用・試験）で解釈ブレを起こさないことを目的とします。

1. 全体方針

• NFR は「品質要求（Quality Attribute）」であり、対象（何に）＋条件（いつ）＋指標（何を）＋基準（どれくらい） を明確に書きます。
  • 一覧表で記述する場合、この4要素は同じ行の「内容」「指標」「基準」「備考」などに 分割して記載しても構いません（ただし合否判定に必要な情報が欠けないこと）。
  • 例: 「在庫照会APIは、平常時の P95 応答時間 500ms 以内である」
• 曖昧な表現（例: 「高速」「安定」「十分」「強固」）は禁止し、観測・計測できる事実に落とします。
• 実装詳細（例: 物理テーブル名、SQL、具体ライブラリ設定、クラス/関数名）は記載しません。
• NFR は「守るべき制約・合格基準」です。運用で実現するもの（監視、バックアップ、手順）も NFR として扱ってよいですが、要件は“結果”として書き、手順は最小限に要約します。
• 1ファイル = 1 受入対象（品質要求のまとまり）を基本とします。
  • 例: 性能（主要画面/API）, 可用性・復旧, セキュリティ, 運用性・監視 など
  • 肥大化する場合は、カテゴリやサブシステム単位で分割し、下位文書側で part_of に上位NFRを指定します。

2. ファイル命名・ID規則

• ファイル名: nfr-<番号>-<短い日本語名>.md （例: nfr-0010-性能.md）
• Frontmatter:
  • id: nfr-performance, nfr-availability のように小文字ハイフン形式。
  • title: 「非機能要件: 性能」など。

推奨:

• カテゴリ別に分割する場合、nfr-performance-api, nfr-security-access-control のように 範囲が分かる ID にします。
• 上位の NFR（例: nfr-performance）が下位文書（例: nfr-performance-api, nfr-performance-ui）を持つ場合、下位側で part_of: [nfr-performance] を指定します（上位側に下位IDを列挙しない）。

3. 推奨 Frontmatter 項目

Frontmatter は docs/handbook/shared/schemas/spec-frontmatter.schema.yaml の制約に従います。

項目	説明	必須
id	NFR ID（nfr-...）	○
type	architecture 固定（品質要求の合意文書として扱う）	○
title	非機能要件名（例: 非機能要件: 性能）	○
status	draft/ready/deprecated	○
part_of	上位NFR ID（分割している場合）	任意
based_on	根拠となる仕様ID（BPS/BR/UIS/EAPIS/TSL/ADR 等）	任意
supersedes	置き換え関係（古仕様→新仕様）	任意

推奨:

• tests に、NFR を満たすことを判定する システム受入条件（SAC） やテスト仕様 ID を列挙します。
• based_on に、対象となる主要仕様 ID（例: eapis-..., uis-..., bps-...）を列挙し、範囲を明確にします。

4. 本文構成（標準テンプレ）

各 NFR ファイルは以下の見出しを順番に並べます。

1. 要件分類
2. 概要
3. 非機能要件
4. メモ / 将来課題

5. 記述ガイド詳細

5.1 要件分類

信頼性/可用性/保守性/完全性/機密性・安全性/性能/運用性/操作性 など。必須／任意は以下の通りです。

要件	説明	必須
信頼性	障害・誤動作が起きにくく、起きても影響を抑えられること	○
可用性	利用可能であること、停止時間を抑えること	○
保守性	障害検知・原因特定・復旧・変更がしやすいこと	○
完全性	データ/処理の正しさ・矛盾の防止、改ざん検知・追跡性	○
機密性・安全性	不正アクセス防止、権限制御、監査、情報漏えい防止	○
性能	応答時間、スループット、同時接続数などが業務上許容できること	任意
運用性	監視、バックアップ、ログなど、運用が明確で実施しやすいこと	任意
操作性	誤操作防止、学習容易性、アクセシビリティ等、利用時の負荷が過大でないこと	任意

5.2 概要

• 1〜3文で「どの品質を、どの範囲に対して、何のために」定めるかを書きます。
• 可能なら、対象仕様（API/画面/業務プロセス等）を言及し、based_on と整合させます。

任意（レビューが速くなる場合のみ）:

• スコープ（対象外）を 1〜3 行で明記してよいです。
  • 例: 「対象外: バッチ処理の性能（別 NFR で扱う）」

5.3 非機能要件

NFR は 一覧表 を基本とし、必要に応じて補足を続けます。

5.3.1 一覧表（必須）

最小の列は次を推奨します。

列	目的
id	一意な要件 ID（nfr-<短い英小文字ハイフン>）
内容	人が読める要件（対象＋条件＋指標）。合否判定の閾値は「基準」に書いてよい
指標	測定/観測の対象（例: 応答時間、エラー率、稼働率、RTO/RPO など）
基準	合否の閾値（例: P95 500ms、稼働率 99.9%、RTO 1時間、保持期間 7年 など）
備考	前提条件、除外、測定/検証方法、補足

推奨の追加列（レビュー/検証が難しい場合に追加）:

• 対象 NFR が適用される範囲（画面/API/バッチ/システム全体、または ID）
• 条件 計測・運用の前提条件（平常時/ピーク時、同時数、データ量など）
• 検証方法 合否判定の観測点（負荷試験、監視、監査ログ等）
• 優先度 Must/Should/Could 等、または High/Medium/Low

5.3.2 書き方のコツ

• “どれくらい”は 単位まで書きます（ms、秒、RPS、GB、日、年、% 等）。
• 性能は「平均」よりも、レビューしやすい指標（P95/P99、最大、スループット）を優先します。
• 可用性は 除外条件（メンテ時間、外部サービス障害の扱い等）を備考に明記します。
• 復旧は可能なら RTO/RPO を使い、「誰が何を見て合否判定するか」を備考に記載します。
• セキュリティは“機能”ではなく 要求として書きます（例: 「権限がない利用者は参照できない」＋監査ログ要件）。

5.4 メモ / 将来課題

• 未確定の前提（例: ピーク時の定義、想定データ量、外部依存のSLA）
• 将来追加したい NFR（例: 監査ログの検索性、DR訓練頻度、保守窓の短縮）

6. 禁止事項

項目	理由
物理テーブル名・物理カラム名・SQL全文	概念レベル逸脱、変更に弱い
実装クラス/関数名、特定ライブラリの設定値の列挙	実装依存で変更に弱い
「高速」「安定」「強固」など曖昧表現	検証不能
“前提”なしの数値（条件が不明）	合意不能、試験設計不能

7. よくある誤りと対策

• 指標がない（「性能を確保する」） → 対象＋条件＋指標＋基準に分解して表に落とす
• 条件がない（ピーク/平常が不明） → 「平常時/ピーク時の定義」を備考に明記
• 検証できない（測れない） → 監視/試験/ログ等の観測点を備考に追記
• 例外（除外）が曖昧 → メンテ時間・外部障害の扱いを明記

8. サンプル（最小）

メタ情報

---
id: nfr-performance
type: architecture
title: 非機能要件: 性能
status: draft
part_of: []
based_on: []
supersedes: []
---

要件分類

性能

概要

主要な画面操作と主要 API が、平常時およびピーク時において業務上許容できる時間内で完了することを定義する。

非機能要件

id	内容	指標	基準	備考
nfr-perf-ii-api-normal	在庫照会APIは、平常時に応答時間が基準内である	応答時間（P95）	500ms	検証: 負荷試験。平常時: 20 RPS を想定
nfr-perf-ii-api-peak	在庫照会APIは、ピーク時に性能が基準内である	スループット / 応答時間（P95）	100 RPS / 800ms	ピーク時: 16〜18時相当。外部IF遅延は別途切り分け
nfr-perf-acc-overall	会計確定は、平常時に完了までの時間が基準内である	完了までの時間	平常時 2 秒以内	対象: レジ業務。検証: E2E + タイム計測

メモ / 将来課題

• ピーク時の同時接続数・データ量の確定

9. 生成 AI への指示テンプレート

生成 AI に非機能要件（NFR）を作らせるときは、以下のような指示を与えます。

• 以下のルールに従って、非機能要件（NFR） を 1 ファイル作成してください。出力は Markdown とします。
• 目的: 性能・可用性・セキュリティ等の品質要求を、測定可能・検証可能な形で定義し、後工程（設計・実装・運用・試験）で解釈ブレを起こさないこと。
• 禁止: 物理テーブル名・物理カラム名・SQL全文、実装クラス/関数名、特定ライブラリの設定値の列挙、クリック手順など UI 操作の逐語列挙

出力フォーマット

• 先頭に YAML Frontmatter を付与し、以下の形式で記述してください（id / type / title / status は必須、type は architecture 固定）：

  ---
  id: nfr-<英小文字とハイフンで構成したID>
  type: architecture
  title: 非機能要件: <対象名>
  status: draft # draft / ready / deprecated
  part_of: []
  based_on: []
  supersedes: []
  ---

• 本文は次の見出し（日本語）をこの順序で必ず含めてください：

  1. 要件分類
  2. 概要
  3. 非機能要件
  4. メモ / 将来課題

記述ルール（重要）

• 各要件（表の各行）の 内容 は、必ず「対象（何に）＋条件（いつ）＋指標（何を）」を含む文章にしてください。
• 合否判定の閾値は、表の 基準 に数値・単位まで具体化してください。
• 曖昧な表現（例: 「高速」「安定」「十分」「強固」）は禁止し、観測・計測できる事実に落としてください。
• 備考 には、前提条件・除外条件・測定/検証方法（負荷試験、監視、監査ログ等）を必要な範囲で記載してください。
• 全体を 業務用語で統一し、略語を使う場合は一般的な略語のみとしてください。一般的でない略語は、初出で正式名称を併記してください。

要件分類

• 「要件分類」には、このファイルが扱う分類を 1〜3 個程度、箇条書きまたは1行で記述してください。
• 分類の候補: 性能 / 信頼性 / 可用性 / 保守性 / 完全性 / 機密性・安全性 / 運用性 / 操作性

非機能要件（表）

• 非機能要件 には、少なくとも 5〜15 行程度の一覧表を作成してください。
• 表は原則として次の列を含めてください：
  • id / 内容 / 指標 / 基準 / 備考
• 指標 には「何を測るか」を、基準 には「合否の閾値」を記載してください。