FRS Creation

FRS 创建技能

目的

创建全面的功能需求规格说明书（FRS），为开发团队提供详细的技术需求，以便其实现业务解决方案。

使用时机

• BRD 获批后
• 开始开发前
• 技术团队需要详细规格说明时
• 对于需要详细文档说明的复杂功能

FRS 与 BRD 的区别

方面	BRD	FRS
受众	业务相关方、高管	技术团队、开发人员、QA
关注点	做什么以及为什么	如何实现
详细程度	高层级业务需求	详细的功能规格说明
语言	业务语言	结合业务背景的技术语言
范围	整个项目／计划	特定模块或功能

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

示例——电子商务结账：

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 指南

电子商务 FRS

关注点：产品目录、购物车、结账、支付、订单管理 关键细节：支付网关规格、库存逻辑、定价规则、运费计算

ERP FRS

关注点：模块工作流、审批流程、数据迁移、集成 关键细节：复杂业务规则、多公司逻辑、报表规格

CRM FRS

关注点：潜在客户／商机管理、销售管道、营销自动化 关键细节：评分算法、工作流自动化、集成规格

CDP FRS

关注点：数据收集、身份解析、细分、激活 关键细节：数据映射、匹配逻辑、API 规格

移动端／Web FRS

关注点：UI/UX、离线同步、性能、平台特定功能 关键细节：API 契约、缓存策略、推送通知

最佳实践

✅ 应该：

• 具体、详细
• 包含示例和边界情况
• 引用线框图和图表
• 明确规定所有业务规则
• 说明错误处理方式
• 为每项需求添加验收标准
• 使用一致的编号和格式

❌ 不应该：

• 让需求含糊不清
• 遗漏错误场景
• 假设开发人员了解业务背景
• 在一项需求中混合多项需求
• 忘记边界情况
• 忽略非功能需求

工具

• 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 - 软件质量要求