機能要件の答え: システムは何をしますか?
非機能要件 (NFR) の答え: システムはどのような条件下でどの程度うまく機能しますか?
多くのプロジェクトは機能の欠如ではなく、NFR の欠如が原因で失敗します。
- 機能には十分なボタンがありますが、遅すぎます。
- ログインは機能しますが、監査ログがありません。
- API は正しいデータを返しますが、レート制限を処理しません。
- フォームは送信できますが、スクリーン リーダー ユーザーは使用できません。
BA はアーキテクトになる必要はありませんが、NFR を明確に質問して作成する方法を知っている必要があります。
1. NFR にはどのようなグループが含まれますか?
一般的な BA グループ:
| グループ | BA の質問 |
|---|---|
| パフォーマンス | どのくらい速いですか？ユーザーは何人ですか? |
| 可用性 | システムにはどれくらいの稼働時間が必要ですか? |
| 信頼性 | エラーを回復するにはどうすればよいですか? |
| セキュリティ | 誰が何をする権利があるのでしょうか？ |
| プライバシー | どのデータが機密ですか?どれくらいの期間保存しますか？ |
| 使いやすさ | ユーザーがタスクを完了するのは簡単ですか? |
| アクセシビリティ | 障害者でも利用できますか？ |
| スケーラビリティ | トラフィックが増加すると何が起こるでしょうか? |
| 可観測性 | 調査するのに十分なログ/メトリック/アラートはありますか? |
| 保守性 | 設定、ルール変更、サポートは簡単ですか? |
2. 測定したNFRの書き方
書かないでください:
システムは高速でなければなりません。
書いてください:
注文リスト ページは、同時ユーザー 500 人、注文データ 100,000 件の p95 で 2 秒以内に読み込まれる必要があります。
書かないでください:
システムは安全でなければなりません。
書いてください:
財務マネージャーの役割のみがトランザクション レポートをエクスポートできます。すべてのエクスポートでは、user_id、タイムスタンプ、フィルター、エクスポート行番号、IP を含む監査ログを記録する必要があります。
テンプレート:
[Đối tượng] phải [hành vi/chất lượng] trong [điều kiện] với [ngưỡng đo] và [cách kiểm chứng].
3. 品質属性のシナリオ
非常に明確な書き方:
| 成分 | 例 |
|---|---|
| 刺激 | 1,000 ユーザーが同時にアクセス |
| 環境 | ラッシュアワー、6 か月のデータ |
| 応答 | 検索リターンシステム |
| 対応策 | p95 レイテンシー < 2.5 秒、エラー率 < 1% |
要件として次のように書きます。
Khi có 1.000 user search đơn hàng đồng thời trong giờ cao điểm, hệ thống phải trả kết quả trong p95 < 2.5 giây và error rate < 1%.
4. 3 つの特殊なケースを見逃してはなりません
データのエッジケース
- NULL またはフィールドがありません。
- レコードが重複しています。
- 別のタイムゾーンの日付。
- フィールドの負の値を負にすることはできません。
- 名前が長いですね。
- 特殊文字。
権限のエッジケース
- ユーザーがログインしていません。
- ユーザーがセッションを期限切れにする。
- ユーザーはロール A を持っていますが、ロール B の機能にアクセスします。 ・操作途中で管理者権限が剥奪された。
統合のエッジケース
- タイムアウト API。
- API は 500 を支払います。
- API は、予想とは異なるスキーマを返します。
- ベンダーのレート制限。
- 再試行するとリクエストが重複します。
UX のエッジケース
- 空の状態。 ・読み込みに時間がかかります。
- ユーザーが送信を 2 回クリックします。
- 間違った形式でファイルをアップロードします。
- ユーザーはブラウザバックに戻ります。
5. 完全な例
機能: 請求書のアップロード。
機能要件:
FR-001: User có thể upload hóa đơn dạng PDF hoặc ảnh để hệ thống lưu vào hồ sơ thanh toán.
NFR とエッジケース:
NFR-001 Performance:
File dưới 10MB phải upload xong trong p95 < 5 giây trên mạng 4G ổn định.
NFR-002 Security:
File upload phải được virus scan trước khi user khác có thể tải xuống.
NFR-003 Privacy:
File hóa đơn có thể chứa PII, chỉ role Finance và Owner của hồ sơ được xem.
EC-001:
Nếu user upload file > 10MB, hệ thống hiển thị lỗi "File vượt quá dung lượng 10MB" và không lưu file.
EC-002:
Nếu user bấm Submit hai lần, hệ thống chỉ tạo một record hóa đơn.
EC-003:
Nếu virus scan fail, file bị quarantine, user thấy trạng thái "Đang chờ kiểm tra bảo mật".
6. BA のチェックリスト NFR
ストーリーがスプリントに入る前に:
- パフォーマンスには測定値がありますか?
- セキュリティには明確な役割/権限がありますか?
- プライバシーにはデータ分類がありますか?
- 監査ログには何が必要ですか?
- 重要なエラーケース AC は存在しますか?
- 再試行すると重複が発生しますか?
- すでに空の状態ですか?
- アクセシビリティにはどのような基準が必要ですか?
- モニタリング/アラートにはどのようなメトリクスが必要ですか?
- QA は NFR をテストする方法を知っていますか?
7. エッジケースを見つけるための AI 支援プロンプト
AI を使用して提案することもできますが、以下を確認する必要があります。
Bạn là Senior Software BA và QA Lead.
Đây là user story và acceptance criteria:
[paste]
Hãy liệt kê:
1. Data edge cases
2. Permission edge cases
3. Integration failure cases
4. UX empty/loading/error states
5. NFR còn thiếu
6. Test scenarios đề xuất
Trả về bảng: Case, Why it matters, Suggested AC, Test approach.
8. よくあるエラー
エラー 1: NFR はスローガンのように書かれています
「安全性が高い」「使いやすい」「速い」をテストすることはできません。しきい値、条件、メトリクスを追加しましょう。
エラー 2: すべての NFR をアーキテクトにプッシュしています
アーキテクトはソリューションの設計を支援しますが、BA はビジネス ニーズ、コンプライアンス、ユーザーの期待が明確に述べられていることを確認する必要があります。
エラー 3: ハッピー パスのみを書き込みます
幸せな道は通常は簡単です。本番環境のインシデントを引き起こす部分は、エッジケースにあります。
スケジューリング機能の完全な NFR の例
| ID | 品質特性 | 測定可能な要件 | テスト/検証方法 |
|---|---|---|---|
| NFR-PERF-001 | パフォーマンス | 同時ユーザー数が 300 でスロットが 10,000/日ある場合、スロット リスト ページは p95 で 2 秒未満で読み込まれる必要があります。 | リリース前にテストをロードし、ダッシュボードで p95 レイテンシを監視します。 |
| NFR-AVAIL-001 | 可用性 | スケジュール機能では、営業時間 08:00 ～ 20:00 の 99.5% の可用性が必要です。 | 稼働時間の監視、インシデントレポート。 |
| NFR-SEC-001 | セキュリティ | 予定を所有する顧客のみが、その予定を表示/変更/キャンセルできます。 | 権限テスト、別のユーザーのappointing_idを使用した否定テスト。 |
| NFR-監査-001 | 監査可能性 | スケジュールを作成、変更、またはキャンセルするたびに、アクター、タイムスタンプ、old_status、new_status、reason を記録する必要があります。 | テスト ケースの監査ログを確認します。 |
| NFR-ACC-001 | アクセシビリティ | 予約フォームはキーボードで操作でき、スクリーンリーダーでラベルやエラーを読み取ることができます。 | WCAG チェックリスト、キーボードのみのテスト。 |
| NFR-OBS-001 | 可観測性 | booking_success、slot_unavailable、notification_failed のメトリクスがあります。 | ステージングテスト後のダッシュボードには十分なメトリクスが表示されます。 |
エッジケースカタログ:
| エッジケース | 予想される動作 |
|---|---|
| 2 人の顧客が 1 秒以内に同じスロットを確認 | 確認できる予定は 1 つだけです。残りのリクエストは受信されます SLOT_UNAVAILABLE。 |
| 顧客は残り 4 時間ちょうどでスケジュールを変更します | ポリシーが「少なくとも 4 時間」の場合、システムは 4 時間以上を許可します。 |
| 電子メール サービス エラー | 予約はまだ確認されており、通知を 3 回再試行し、失敗した場合はアラートを作成します。 |
| 顧客がスロットを表示した後、コンサルタントは非アクティブになりました | 送信がブロックされたため、コンサルタントは利用できなくなりました。 |
| ユーザーがリンクを開いて期限切れのカレンダーをキャンセルする | システムはホットラインに電話するよう指示を表示しますが、自動的にはキャンセルされません。 |
参照元
- IEEE/ISO/IEC 29148-2018: https://standards.ieee.org/ieee/29148/6937/
- IIBA BABOK ガイド: https://www.iiba.org/standards-and-resources/babok/
結論
NFR とエッジ ケースでは、ソフトウェア BA が違いを生みます。ストーリーは小さく見えるかもしれませんが、パフォーマンス、セキュリティ、プライバシー、エラー処理、可観測性が欠けている場合、リリース後に大規模な手戻りが発生する可能性があります。優れた BA は、コーディングを開始する前にチームがそのリスクを認識できるようにします。