k2works/analyzing-non-functional

非機能要件定義

性能、セキュリティ、可用性、保守性、拡張性の非機能要件を測定可能な形で定義する。

非機能要件は「システムがどう振る舞うべきか」を定義する。機能要件だけでシステムを作ると、性能劣化・セキュリティ脆弱性・障害時の長時間停止といった問題が本番で初めて発覚する。数値目標を先に定めることで、アーキテクチャ選定とテスト戦略に明確な基準を与える。

参照ドキュメントとテンプレート

| 種類 | パス | 備考 | |------|------|------| | ガイド | @docs/reference/非機能要件定義ガイド.md | 非機能要件定義の進め方詳細 | | テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する | | 入力 | @docs/requirements/requirements_definition.md | 要件定義 | | 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ | | 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ | | 入力 | @docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ | | 成果物 | docs/design/non_functional.md | 非機能要件定義 |

性能要件

ユーザー体験に直結する指標を定義する。曖昧な「速い」ではなく、具体的な数値で定義せよ。

• レスポンスタイム: 画面操作ごとの応答時間目標（p50/p95/p99）を設定する
• スループット: 単位時間あたりの処理件数を定義する
• 同時接続数: ピーク時の同時接続ユーザー数を見積もる

セキュリティ要件

守るべき資産とリスクに応じたセキュリティ対策を定義する。過剰防衛はコストの無駄、過小防衛はインシデントの元。

• 認証・認可: 認証方式（OAuth2、SAML 等）と認可モデル（RBAC、ABAC 等）を決定する
• データ暗号化: 通信経路と保存データの暗号化方式を定義する
• 監査ログ: 誰が・いつ・何をしたかを追跡可能にする

可用性要件

ビジネスインパクトに応じた稼働目標を設定する。99.9% と 99.99% ではコストが桁違いになることを意識せよ。

• 稼働率目標: SLA として定義する稼働率を設定する
• 障害復旧時間（RTO）: 障害発生からサービス復旧までの目標時間を設定する
• データ復旧時点（RPO）: データ損失の許容範囲を設定する

保守性要件

運用チームが日常的に必要とする機能を定義する。

• ログ出力: ログレベル・出力先・保持期間を定義する
• 監視項目: メトリクス収集の対象と閾値を設定する
• アラート設定: 通知先と重要度レベルを定義する

拡張性要件

将来のスケールに備えた設計指針を定義する。

• スケーラビリティ: 水平/垂直スケーリングの方針を定める
• 将来の拡張性: 想定される拡張シナリオと対応方針を記載する

作成の進め方

1. 入力ドキュメント（要件定義、アーキテクチャ設計）を確認する
2. @docs/reference/非機能要件定義ガイド.md を読み込む
3. 各カテゴリの非機能要件を測定可能な数値で定義する
4. docs/design/non_functional.md として出力する

途中から再開する場合

既存の docs/design/non_functional.md がある場合は、まずその内容を確認する。不足しているカテゴリや数値の見直しが必要な部分のみを修正する。

Example:

ユーザー: 「性能要件は定義した。セキュリティ要件を整理したい」
回答: 既存の non_functional.md の性能要件を確認し、
      セキュリティ要件の定義に進む。認証・認可方式、
      暗号化方式、監査ログの要件を具体的な数値・方式で定義する。

注意事項

• 機能要件とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
• 非機能要件は必ず測定可能な形で定義する。「高速であること」ではなく「p95 で 200ms 以内」のように書け
• SLA/SLO を明確に定義し、ビジネス側との合意を取る前提で記載する
• タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）

関連スキル

• orchestrating-analysis — 分析フェーズ全体のワークフロー案内
• analyzing-architecture — 前段のアーキテクチャ設計
• analyzing-operation — 後続の運用要件定義（非機能要件が入力になる）
• analyzing-test-strategy — 後続のテスト戦略（性能テストの基準になる）