FRS Creation Skill

Purpose

Create comprehensive Functional Requirements Specifications (FRS) that provide detailed, technical requirements for development teams to implement business solutions.

When to Use

• After BRD approval

• Before development begins

• When technical teams need detailed specifications

• For complex features requiring detailed documentation

FRS vs BRD

Aspect BRD FRS

Audience Business stakeholders, executives Technical team, developers, QA

Focus WHAT and WHY HOW

Detail Level High-level business requirements Detailed functional specifications

Language Business language Technical language with business context

Scope Entire project/initiative Specific module or feature

FRS Structure

1. Introduction

• Document purpose and scope

• Related documents (BRD, use cases, user stories)

• Intended audience

• Document conventions and terminology

2. System Overview

• High-level architecture

• System context diagram

• Integration points

• Technology stack (if known)

3. Functional Requirements

Format for Each Requirement:

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

Example - E-commerce Checkout:

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. Data Requirements

Entity Definitions:

• Data entities and attributes

• Data types and constraints

• Relationships between entities

• Data validation rules

Example:

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. Integration Requirements

For Each Integration:

• External system name and purpose

• Integration type (API, File, Real-time, Batch)

• Data flow direction

• Authentication method

• Error handling

• Frequency/timing

Example:

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. Business Rules

Document all business logic and rules:

Example:

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 Specifications

• Screen layouts and wireframes

• User workflows and navigation

• Form field specifications

• Validation messages

• Responsive design requirements

• Accessibility requirements

Example:

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. Non-Functional Requirements

• Performance requirements (response time, throughput)

• Security requirements

• Scalability requirements

• Availability requirements

• Browser/device compatibility

• Accessibility standards

9. Assumptions & Constraints

Same as BRD but with technical details

10. Appendices

• Glossary of terms

• Wireframes and mockups

• Data flow diagrams

• State diagrams

• API specifications

Domain-Specific FRS Guidelines

E-commerce FRS

Focus: Product catalog, cart, checkout, payment, order management Key Details: Payment gateway specs, inventory logic, pricing rules, shipping calculations

ERP FRS

Focus: Module workflows, approval processes, data migration, integrations Key Details: Complex business rules, multi-company logic, reporting specs

CRM FRS

Focus: Lead/opportunity management, sales pipeline, marketing automation Key Details: Scoring algorithms, workflow automation, integration specs

CDP FRS

Focus: Data collection, identity resolution, segmentation, activation Key Details: Data mapping, matching logic, API specifications

Mobile/Web FRS

Focus: UI/UX, offline sync, performance, platform-specific features Key Details: API contracts, caching strategy, push notifications

Best Practices

✅ Do:

• Be specific and detailed

• Include examples and edge cases

• Reference wireframes and diagrams

• Define all business rules explicitly

• Specify error handling

• Include acceptance criteria for each requirement

• Use consistent numbering and formatting

❌ Don't:

• Leave requirements ambiguous

• Skip error scenarios

• Assume developers know business context

• Mix multiple requirements in one

• Forget about edge cases

• Ignore non-functional requirements

Tools

• Lark Docs: Collaborative FRS writing

• Notion: Requirements database with linking

• Figma: Wireframes and UI specifications

• Mermaid: Diagrams in markdown

Next Steps

After FRS completion:

• Technical review with development team

• Create use cases (see use-case-documentation skill)

• Write user stories (see user-story-writing skill)

• Define acceptance criteria (see acceptance-criteria skill)

• Plan UAT (see uat-planning skill)

References

• IEEE 29148 - Requirements Engineering

• BABOK® Guide - Requirements specification

• ISO/IEC 25010 - Software quality requirements