| 項目 | 内容 |
|---|---|
| 作成日 | 2026-07-04 |
| バージョン | v2.0（オフライン対応改修） |
| 作成者 | 株式会社VTL |
| 対象成果物 | 3-ad.html（AD）／ プロトタイプ 一式 |
| 親要求 | 2-strs-syrs.html |
🔒 本サンプルは抜粋版です。 冒頭の「1. Verification」まで完全開示し、それ以降（Validation・判定）はフォーマット非開示としています。完全版はミーティングにてご提供します。
設計（AD・プロト）を SoI境界＝V&V境界 で確認する：内（決済運用・リスク管理）＝検証／外（要求源＝消費者）＝妥当性確認。
設計（AD・プロト）が運用上正しく成立するかを、SoI 内の運用者（Role）が確認する。照合先は SyRS（機能仕様）と運用制約。懸念・制約条件・抜けを洗い出す（＝「正しく作れているか」）。
| 対象（機能・画面） | 確認観点 | 確認者 | 結果 | 懸念・制約 |
|---|---|---|---|---|
| F-2 事前承認枠（PreApprovalEngine） | 与信・利用履歴に対し安全な上限枠を算出できるか | 佐藤（リスク管理） | 懸念 | 与信情報が古いと過大枠のリスク。定期的な枠の再評価と、リスク層別の上限設定が要る |
| F-3 オフライン暫定承認 | 通信断時に端末ローカルで確実に承認できるか | 高橋（決済運用） | 懸念 | 端末時計のズレ・改ざんに注意。署名付きトークン＋TEE（セキュア領域）を前提として明文化したい |
| F-4 OfflineBuffer 保持 | 取引が改ざん・消失なく保持されるか | 高橋（決済運用） | OK | 暗号化＋改ざん検知は妥当。端末故障・機種変更時の取引復旧手順を追加したい |
| F-6 ReconciliationService 整合 | 二重決済・残高不整合を確実に解消できるか | 佐藤（リスク管理） | 懸念 | 復帰が長期化した場合の確定タイムアウトと自動取消、残高不足時の回収フローを定義する必要 |
| F-7 不正・限度制御 | 上限5万円・異常検知がオフラインでも機能するか | 伊藤（不正対策） | 懸念 | 複数取引の合算上限を端末側で管理する必要。オンライン復帰前提の検知はオフライン中は効かない |
| F-1 本人認証（生体/PIN） | オフラインでも本人確認が成立するか | 高橋（決済運用） | OK | 端末内生体＋PINは妥当。認証失敗時のロック方針を明文化したい |
| F-8 消費者通知 | 暫定/確定/整合の状態が誤解なく伝わるか | 渡辺（加盟店サポート） | 懸念 | 「暫定承認」と「確定」の表示差が曖昧だと問い合わせが増える。状態遷移の明確なUI表記が要る |
本文書はこの後も複数の節が続きますが、節構成・記法・内容ともに非開示としています。完全版はミーティングにてご提供します。
▓▓▓▓▓▓▓▓▓▓ 非開示 ／ フォーマット詳細はミーティングにて提供 ▓▓▓▓▓▓▓▓▓▓
End of V&V（抜粋版）