FRS Creation

FRS 作成スキル

目的

開発チームがビジネスソリューションを実装するための、詳細かつ技術的な要件を記載した包括的な機能要件仕様書（FRS）を作成します。

使用するタイミング

• BRD の承認後
• 開発開始前
• 技術チームが詳細な仕様を必要とするとき
• 詳細なドキュメントが必要な複雑な機能の場合

FRS と BRD の比較

項目	BRD	FRS
対象者	ビジネス関係者、経営幹部	技術チーム、開発者、QA
焦点	WHAT と WHY	HOW
詳細度	概要レベルのビジネス要件	詳細な機能仕様
言語	ビジネス用語	ビジネスの背景を踏まえた技術用語
対象範囲	プロジェクト／取り組み全体	特定のモジュールまたは機能

FRS の構成

1. はじめに

• ドキュメントの目的と対象範囲
• 関連ドキュメント（BRD、ユースケース、ユーザーストーリー）
• 想定読者
• ドキュメントの表記規則と用語

2. システム概要

• アーキテクチャの概要
• システムコンテキスト図
• 統合ポイント
• 技術スタック（判明している場合）

3. 機能要件

各要件の形式：

FR-[MODULE]-[NUMBER]: [Requirement Title]

Description: [Detailed description of what the system shall do]

Business Rule: [Any business logic or rules]

Input: [What data/triggers initiate this function]
Process: [Step-by-step what the system does]
Output: [What the system produces/displays]

Acceptance Criteria:
- [Specific, testable criterion 1]
- [Specific, testable criterion 2]

UI/UX Notes: [Any UI specifications, wireframe references]

Dependencies: [Other requirements this depends on]

Priority: Must Have | Should Have | Could Have

Complexity: Low | Medium | High

例 — E コマースのチェックアウト：

FR-CHK-001: Guest Checkout

Description: System shall allow users to complete purchase without creating an account

Business Rule: 
- Guest users must provide email for order confirmation
- After purchase, system shall offer account creation
- Guest checkout not available for orders > $5000

Input: User clicks "Checkout as Guest" button
Process:
1. System validates cart is not empty
2. System checks order total < $5000
3. System displays shipping address form
4. System validates address using address verification API
5. System displays shipping options with real-time pricing
6. System displays payment form
7. System processes payment via Stripe
8. System creates order record with guest flag
9. System sends confirmation email
10. System displays order confirmation page with option to create account

Output: 
- Order confirmation number
- Email confirmation sent
- Order record created in database

Acceptance Criteria:
- Guest can complete checkout in < 2 minutes
- All form fields have proper validation
- Address verification catches invalid addresses
- Payment processing completes in < 5 seconds
- Confirmation email sent within 1 minute
- Order appears in admin system immediately

UI/UX Notes: See Figma wireframes (link)
- Single-page checkout design
- Progress indicator at top
- Order summary sticky on right side
- Mobile-responsive layout

Dependencies: FR-PAY-001 (Payment Processing), FR-ORD-001 (Order Creation)

Priority: Must Have
Complexity: High

4. データ要件

エンティティ定義：

• データエンティティと属性
• データ型と制約
• エンティティ間の関係
• データ検証ルール

例：

Entity: Order

Attributes:
- order_id (UUID, Primary Key, Required, Auto-generated)
- customer_id (UUID, Foreign Key to Customer, Optional for guest)
- order_number (String, Unique, Format: ORD-YYYYMMDD-XXXX)
- order_date (DateTime, Required, Default: Current timestamp)
- status (Enum, Required, Values: pending|processing|shipped|delivered|cancelled)
- subtotal (Decimal(10,2), Required, Min: 0.01)
- tax (Decimal(10,2), Required, Min: 0)
- shipping_cost (Decimal(10,2), Required, Min: 0)
- total (Decimal(10,2), Required, Calculated: subtotal + tax + shipping_cost)
- shipping_address (JSON, Required)
- billing_address (JSON, Required)
- payment_method (String, Required)
- payment_status (Enum, Required, Values: pending|authorized|captured|failed|refunded)
- created_at (DateTime, Required, Auto-generated)
- updated_at (DateTime, Required, Auto-updated)

Relationships:
- One Order has many OrderItems
- One Order belongs to one Customer (optional)
- One Order has one Payment

Business Rules:
- Order number must be unique
- Total must equal subtotal + tax + shipping_cost
- Status transitions: pending → processing → shipped → delivered
- Cancelled orders cannot be modified

5. 統合要件

統合ごとに記載する項目：

• 外部システムの名称と目的
• 統合タイプ（API、ファイル、リアルタイム、バッチ）
• データフローの方向
• 認証方式
• エラー処理
• 頻度／タイミング

例：

INT-001: Stripe Payment Gateway Integration

Purpose: Process credit card payments securely

Type: REST API, Real-time

Direction: Bidirectional
- Outbound: Payment intent creation, charge capture
- Inbound: Payment confirmation, webhook notifications

Authentication: API Key (Secret key for server, Publishable key for client)

Endpoints Used:
- POST /v1/payment_intents (Create payment intent)
- POST /v1/payment_intents/{id}/confirm (Confirm payment)
- POST /v1/refunds (Process refund)

Data Mapping:
- Order.total → PaymentIntent.amount
- Order.currency → PaymentIntent.currency
- Customer.email → PaymentIntent.receipt_email

Error Handling:
- Network timeout (30 seconds): Retry up to 3 times with exponential backoff
- Payment declined: Display user-friendly error, log details
- API error: Fallback to manual payment processing, alert admin

Webhooks:
- payment_intent.succeeded → Update order status to "processing"
- payment_intent.payment_failed → Update order status to "failed", notify customer
- charge.refunded → Update order status to "refunded"

SLA: 99.9% uptime, < 2 second response time

Testing: Use Stripe test mode with test card numbers

6. ビジネスルール

すべてのビジネスロジックとルールを記載します。

例：

BR-001: Shipping Cost Calculation
- Orders < $50: Standard shipping $5.99, Express $12.99
- Orders $50-$99: Standard shipping $3.99, Express $9.99  
- Orders ≥ $100: Free standard shipping, Express $7.99
- International orders: Calculated by weight and destination
- Alaska/Hawaii: Add $10 to standard rates

BR-002: Discount Application
- Only one promo code per order
- Promo codes cannot be combined with sale items
- Employee discount (20%) can be combined with promo codes
- Discounts applied before tax calculation
- Minimum order value may apply per promo code

BR-003: Inventory Reservation
- Items reserved for 15 minutes when added to cart
- Reservation extended by 15 minutes on each cart update
- Reservation released after 15 minutes of inactivity
- Out-of-stock items cannot be added to cart
- Backorder items can be added if enabled for product

7. UI/UX 仕様

• 画面レイアウトとワイヤーフレーム
• ユーザーワークフローとナビゲーション
• フォームフィールドの仕様
• 検証メッセージ
• レスポンシブデザイン要件
• アクセシビリティ要件

例：

Screen: Checkout Page

Layout: Single-page design with 3 sections
1. Shipping Information (left column)
2. Payment Information (left column, below shipping)
3. Order Summary (right column, sticky)

Shipping Information Fields:
- Email (required, email validation, max 100 chars)
- Full Name (required, min 2 chars, max 100 chars)
- Address Line 1 (required, max 100 chars)
- Address Line 2 (optional, max 100 chars)
- City (required, max 50 chars)
- State/Province (required, dropdown)
- ZIP/Postal Code (required, format validation based on country)
- Country (required, dropdown, default: US)
- Phone (required, phone format validation)

Validation:
- Real-time validation on blur
- Error messages displayed below field in red
- Submit button disabled until all required fields valid

Error Messages:
- Email: "Please enter a valid email address"
- Name: "Name must be at least 2 characters"
- ZIP: "Please enter a valid ZIP code"

Responsive:
- Desktop: 2-column layout
- Tablet: 2-column layout, narrower
- Mobile: Single column, order summary collapsible

Accessibility:
- All form fields have labels
- Error messages associated with fields (aria-describedby)
- Keyboard navigation support
- Screen reader compatible
- Color contrast ratio ≥ 4.5:1

8. 非機能要件

• パフォーマンス要件（応答時間、スループット）
• セキュリティ要件
• スケーラビリティ要件
• 可用性要件
• ブラウザー／デバイスの互換性
• アクセシビリティ標準

9. 前提条件と制約

BRD と同様ですが、技術的な詳細を含めます。

10. 付録

• 用語集
• ワイヤーフレームとモックアップ
• データフロー図
• 状態遷移図
• API 仕様

ドメイン別 FRS ガイドライン

E コマース FRS

焦点：商品カタログ、カート、チェックアウト、決済、注文管理
主な詳細：決済ゲートウェイの仕様、在庫ロジック、価格設定ルール、送料の計算

ERP FRS

焦点：モジュールのワークフロー、承認プロセス、データ移行、統合
主な詳細：複雑なビジネスルール、複数会社のロジック、レポート仕様

CRM FRS

焦点：リード／商談管理、営業パイプライン、マーケティングオートメーション
主な詳細：スコアリングアルゴリズム、ワークフローの自動化、統合仕様

CDP FRS

焦点：データ収集、ID 解決、セグメンテーション、アクティベーション
主な詳細：データマッピング、照合ロジック、API 仕様

モバイル／Web FRS

焦点：UI/UX、オフライン同期、パフォーマンス、プラットフォーム固有の機能
主な詳細：API コントラクト、キャッシュ戦略、プッシュ通知

ベストプラクティス

✅ 推奨事項：

• 具体的かつ詳細に記述する
• 例とエッジケースを含める
• ワイヤーフレームと図を参照する
• すべてのビジネスルールを明確に定義する
• エラー処理を仕様に含める
• 各要件に受け入れ基準を含める
• 一貫した番号付けと書式を使用する

❌ 避けること：

• 要件を曖昧なままにする
• エラーシナリオを省略する
• 開発者がビジネスの背景を理解していると想定する
• 1 つの要件に複数の要件を混在させる
• エッジケースを忘れる
• 非機能要件を無視する

ツール

• Lark Docs：共同での FRS 作成
• Notion：リンク機能を備えた要件データベース
• Figma：ワイヤーフレームと UI 仕様
• Mermaid：Markdown 内の図

次のステップ

FRS 完了後：

1. 開発チームと技術レビューを実施します
2. ユースケースを作成します（use-case-documentation スキルを参照）
3. ユーザーストーリーを作成します（user-story-writing スキルを参照）
4. 受け入れ基準を定義します（acceptance-criteria スキルを参照）
5. UAT を計画します（uat-planning スキルを参照）

参考資料

• IEEE 29148 - 要件エンジニアリング
• BABOK® Guide - 要件仕様
• ISO/IEC 25010 - ソフトウェア品質要件