Pseudocode To Specification

Pseudocode to Specification

Extract functional requirements and business specifications from pseudocode, algorithms, or code snippets.

Core Workflow

1. Analyze Pseudocode

Parse structure, control flow, and identify:

• Inputs, outputs, and data transformations
• Variables, constants, and data structures
• Algorithms and logic patterns
• Assumptions and implicit requirements

Ask for clarification on:

• Ambiguous variable names or operations
• Missing context about data sources/destinations
• Unclear business rules or constraints
• Undefined error handling or edge cases

2. Extract Functional Requirements

Document core business functionality as requirements:

FR-001: [Function Name]
Business Purpose: [Why this function exists]
Description: System shall [action] when [condition]
Inputs: [business data, parameters, context]
Processing Logic: [business rules and decision steps]
Outputs: [business results, side effects]
Business Rules: [constraints, validations, calculations]
Preconditions: [required business state]
Postconditions: [resulting business state]

For detailed requirement patterns: requirements-patterns.md

3. Extract Business Data Requirements

Identify business entities and their requirements:

• Business entities and their meaning
• Business attributes and their purpose
• Business constraints and validation rules
• Business relationships between entities
• Data lifecycle and state transitions

Document as:

Business Entity: [EntityName]
Business Meaning: [What this represents]
Attributes:
  - name: [Business meaning, constraints]
  - field: [Business purpose, validation rules]
Relationships:
  - [Business relationship] with [OtherEntity]
  - Cardinality: [min..max]
Business Rules:
  - [Business constraint or invariant]
Lifecycle States:
  - [State] → [State] when [condition]

4. Document Business Workflow and Logic

Analyze business process flow:

• Sequential business operations
• Business decision points and conditions
• Iterative business processes
• Business exception paths
• Business event triggers

Generate business workflow specification:

Business Process: [ProcessName]
Purpose: [Business goal]

Step 1: [Business Action]
  - Business Condition: [when/if from business perspective]
  - Action: [what happens in business terms]
  - Business Rules Applied: [relevant rules]
  - Next: [step or branch]

Step 2: [Business Decision]
  Branches:
    - If [business condition]: Go to Step 3
    - Else: Go to Step 5
  - Decision Criteria: [business factors]

Business Error Conditions:
  - [ErrorCondition]: [Business impact and recovery]

For complex business logic, use decision tables. See mermaid-diagrams.md for business flow notation.

5. Generate Service Function Specifications

Document service functions in business terms:

Function: [functionName]
Business Purpose: [What business problem this solves]
Business Context: [When/why this is needed]
Inputs:
  - param1: [Business meaning, constraints]
  - param2: [Business meaning, required/optional]
Processing Logic:
  1. [Business rule or validation]
  2. [Business calculation or transformation]
  3. [Business decision point]
Outputs: [Business result description]
Business Rules:
  - [Rule 1: condition → action]
  - [Rule 2: validation or constraint]
Error Conditions:
  - [Business error]: [Condition and meaning]
Example Business Scenarios:
  Scenario: [situation]
  Input: [business context]
  Output: [expected business result]

6. Identify Integration Points

Document functional dependencies on external systems:

Integration: [SystemName]
Business Purpose: [Why this dependency exists]
Data Exchanged: [Business data sent/received]
Business Rules:
  - [When interaction occurs]
  - [What triggers communication]
Failure Impact:
  - Business consequence: [Impact on business process]
  - Mitigation: [Business workaround or fallback]

7. Document Assumptions and Constraints

Business Assumptions:

• Expected data volumes and patterns
• User behavior expectations
• Business process frequency
• External system availability

Business Constraints:

• Regulatory requirements
• Business policy limitations
• Data retention requirements
• Compliance requirements

8. Identify Business Acceptance Criteria

Define how to verify functional correctness:

• Normal business scenarios
• Business edge cases and boundary conditions
• Business error conditions
• Business rules validation

Format:

Acceptance Criterion: AC-001
For: [FR-XXX]
Given: [business context]
When: [business action]
Then: [expected business outcome]

Business Scenarios:
  Scenario 1: Normal case
    - Context: [typical business situation]
    - Action: [user/system action]
    - Expected: [business result]
  
  Scenario 2: Edge case
    - Context: [boundary condition]
    - Action: [user/system action]
    - Expected: [business result]

Output Formats

Generate functional specification based on context. Standard format:

Functional Specification Document:

# [System/Component] Functional Specification

## 1. Overview
[Business purpose, scope, and objectives]

## 2. Functional Requirements
[FR-001, FR-002, etc. - business functionality]

## 3. Business Data Requirements
[Business entities, attributes, relationships, constraints]

## 4. Business Workflow and Logic
[Business process flows, decision logic, business rules]

## 5. Service Function Specifications
[Business functions, inputs/outputs, processing logic]

## 6. Integration Points
[External system dependencies at functional level]

## 7. Business Rules and Constraints
[Complete business logic, validation rules, calculations]

## 8. Business Acceptance Criteria
[How to verify functional correctness]

## 9. Assumptions and Dependencies
[Business assumptions and constraints]

## 10. Appendices
[Business flow diagrams, glossary, references]

User Stories (Agile Format):

Epic: [High-level business capability]

Story 1: As a [role], I want [capability] so that [business benefit]

Acceptance Criteria:
  - Given [business context], when [user action], then [business outcome]
  - Given [business context], when [user action], then [business outcome]

Business Rules:
  - [Rule 1: condition → action]
  - [Rule 2: constraint or validation]

Story 2: [Next story following same pattern]

For additional specification formats: specification-templates.md

Key Principles

Focus Strictly on Functional Requirements:

• Extract WHAT the system does, not HOW it's built
• Describe business behavior, not technical implementation
• Specify business rules, not design patterns
• Document business logic, not architecture
• Exclude performance, security, scalability (non-functional)

Maintain Business Traceability:

• Link requirements to business logic in pseudocode
• Use identifiers: FR (functional), BR (business rule), AC (acceptance criteria)
• Reference pseudocode sections showing business logic

Clarify Business Intent:

• Extract WHY (business purpose) and WHAT (business capability)
• Describe business value and outcomes
• Separate business requirements from technical choices
• Mark inferred business rules vs stated logic

Validate Functional Completeness:

• Ensure all business logic paths documented
• Verify all business inputs/outputs specified
• Check all business error conditions covered
• Confirm all business rules extracted

Common Business Patterns

Recognize and document business patterns:

CRUD Operations: Create/read/update/delete → Business entity management spec with business rules State Machines: State transitions → Business lifecycle spec with state meanings and transition conditions Business Process: Sequential steps → Business workflow spec with decision points Data Transformation: Input → process → output → Business function spec with transformation rules Event-Driven: Trigger → react → Business event spec with business triggers and actions

Functional Specification Quality Checklist

Before finalizing, verify:

• ✓ All business logic from pseudocode extracted
• ✓ Requirements describe WHAT (functionality), not HOW (design/implementation)
• ✓ Business rules complete and clear
• ✓ Business entities and relationships defined
• ✓ Business workflows cover all decision paths
• ✓ Business error conditions documented
• ✓ Business assumptions stated
• ✓ Integration dependencies at functional level (data exchanged, not technical protocols)
• ✓ Acceptance criteria defined (functional verification, not test cases)
• ✓ No design decisions (architecture, patterns, technology choices)
• ✓ No implementation details (algorithms, data structures, code)
• ✓ No testing strategies (test plans, test cases, coverage)
• ✓ No deployment considerations (infrastructure, environments, scaling)
• ✓ Focus maintained exclusively on business functionality and requirements

Examples

Simple Algorithm:

Input pseudocode:

function calculateShippingCost(weight, distance, priority):
    if weight <= 0 or distance <= 0:
        throw error "Invalid input"
    baseCost = weight * 0.5 + distance * 0.1
    if priority == "express":
        baseCost = baseCost * 1.5
    return round(baseCost, 2)

Generated functional specification excerpt:

FR-001: Shipping Cost Calculation

Business Purpose:
  Calculate shipping cost based on package characteristics and service level

Business Inputs:
  - weight: Package weight in kg (must be positive)
  - distance: Shipping distance in km (must be positive)
  - priority: Service level (express or standard)

Business Logic:
  1. Validate business constraints:
     - Weight must represent a real package (> 0)
     - Distance must be a valid route (> 0)
  2. Calculate base cost using business formula:
     - Weight component: weight × $0.50 per kg
     - Distance component: distance × $0.10 per km
  3. Apply service level multiplier:
     - Express service: 1.5× base cost
     - Standard service: 1.0× base cost (no change)
  4. Round to currency precision (2 decimal places)

Business Rules:
  - BR-001: Weight and distance must be positive values
  - BR-002: Express service costs 50% more than standard
  - BR-003: Cost calculated in USD currency

Business Output:
  - Shipping cost in USD

Business Error Conditions:
  - Invalid package weight: Cannot calculate for non-physical package
  - Invalid distance: Cannot calculate for invalid route
  - Unknown service level: Must specify express or standard service

Acceptance Criteria:
  - Given valid weight and distance, when calculating standard shipping,
    then cost equals (weight × 0.5 + distance × 0.1) rounded to 2 decimals
  - Given valid inputs with express priority, when calculating,
    then cost is 1.5× the standard calculation

Complex Workflow:

For detailed workflow examples with branching logic and integration points, see specification-templates.md.

Additional Resources

Load as needed:

• specification-templates.md - Industry-standard spec formats
• requirements-patterns.md - Common requirement structures
• mermaid-diagrams.md - Mermaid diagram notation and examples

Business Flow Diagrams for Functional Specification

This document provides guidance on creating diagrams from pseudocode analysis to visualize business processes, workflows, and functional behavior. Focus is on illustrating WHAT the system does from a business perspective, not HOW it's technically implemented.

When to Use Diagrams

Use diagrams to clarify business logic:

• Complex business workflows with multiple decision paths
• Business entity relationships and data requirements
• Business interactions between systems/actors
• Business state transitions and lifecycle
• Business process flows

Don't overuse:

• Simple linear business processes (plain text is clearer)
• When pseudocode already clearly expresses business logic
• For technical implementation details (architecture, deployment, etc.)
• When documenting technical rather than functional aspects

Diagram Types and Use Cases

1. Sequence Diagram

Use for: Business interaction flows, actor communications, business message passing

When to extract from pseudocode:

businessActor performs action
system validates with businessRule
system queries businessData
system notifies externalParty

Mermaid Notation:

sequenceDiagram
    participant Customer
    participant OrderSystem
    participant InventorySystem
    participant PaymentSystem
    
    Customer->>OrderSystem: Place Order
    OrderSystem->>InventorySystem: Check Availability
    InventorySystem-->>OrderSystem: Availability Status
    OrderSystem->>PaymentSystem: Process Payment
    PaymentSystem-->>OrderSystem: Payment Result
    OrderSystem-->>Customer: Order Confirmation

Markdown Format:

````markdown

Sequence Diagram: [Business Process Name]

sequenceDiagram
    participant BusinessActor
    participant System
    participant ExternalSystem
    
    BusinessActor->>System: Business Action
    System->>ExternalSystem: Business Request
    ExternalSystem-->>System: Business Response
    System-->>BusinessActor: Business Result

````

Key Elements:

• Participants: Business actors, systems, external parties
• Messages: Business actions and requests
• Return messages: Business responses and results
• Focus on business meaning, not technical protocols

When to extract from pseudocode:

if condition1:
  action1()
  if condition2:
    action2()
  else:
    action3()
else:
  action4()

Mermaid Flowchart:

flowchart TD
    Start([Start])
    Cond1{Condition 1?}
    Action1[Action 1]
    Action4[Action 4]
    Cond2{Condition 2?}
    Action2[Action 2]
    Action3[Action 3]
    End([End])
    
    Start --> Cond1
    Cond1 -->|Yes| Action1
    Cond1 -->|No| Action4
    Action1 --> Cond2
    Cond2 -->|Yes| Action2
    Cond2 -->|No| Action3
    Action2 --> End
    Action3 --> End
    Action4 --> End

Markdown Format:

````markdown

Activity Diagram: [Process Name]

flowchart TD
    Start([Start])
    Cond1{Condition 1?}
    Action1[Action 1]
    Action2[Action 2]
    End([End])
    
    Start --> Cond1
    Cond1 -->|Yes| Action1
    Cond1 -->|No| Action2
    Action1 --> End
    Action2 --> End

Key Elements:

• Start/End nodes: ([Start]), ([End])
• Activities: [Action]
• Decisions: {Condition?} with labeled edges
• Flow direction: TD (top-down), LR (left-right)
• Parallel flows: Use subgraphs or multiple paths

3. State Machine Diagram

Use for: Entity lifecycle, status transitions, mode changes

When to extract from pseudocode:

if state == "pending":
  if approved:
    state = "active"
  if rejected:
    state = "cancelled"
else if state == "active":
  if suspend:
    state = "suspended"

Mermaid State Diagram:

stateDiagram-v2
    [*] --> Pending
    Pending --> Active: approved
    Pending --> Cancelled: rejected
    Active --> Suspended: suspend
    Suspended --> Active: reactivate
    Cancelled --> [*]
    
    note right of Pending
        awaiting_approval == true
    end note
    
    note right of Active
        valid_until > current_date
    end note

Markdown Format:

````markdown

State Machine: [Entity Name]

stateDiagram-v2
    [*] --> Pending
    Pending --> Active: approved [validation passed]
    Pending --> Cancelled: rejected
    Active --> Suspended: suspend
    Suspended --> Active: reactivate [reason resolved]
    Cancelled --> [*]

States:

• Pending: Initial state after creation
• Active: Normal operational state
• Suspended: Temporarily disabled
• Cancelled: Terminal state (cannot transition out)

Transitions:

• Pending → Active: Event = approved, Guard = validation passed
• Pending → Cancelled: Event = rejected
• Active → Suspended: Event = suspend
• Suspended → Active: Event = reactivate, Guard = reason resolved

State Invariants:

• Pending: awaiting_approval == true
• Active: valid_until > current_date
• Suspended: suspension_reason must be set

````

Key Elements:

• Initial state: [*]
• Final state: [*] at end of transition
• States: Named automatically from transitions
• Transitions: State1 --> State2: event [guard]
• Notes: note right of State for annotations

4. Class Diagram (Business Data Model)

Use for: Business entity relationships, business data structures, business object hierarchies

When to extract from pseudocode:

entity Order:
  id, customer, items, total, status
  
entity OrderItem:
  product, quantity, price

entity Customer:
  id, name, email, status

Mermaid Class Diagram:

classDiagram
    class Customer {
        -identifier
        -name
        -email
        -status
    }
    
    class Order {
        -orderNumber
        -totalAmount
        -orderStatus
    }
    
    class OrderItem {
        -productName
        -quantity
        -unitPrice
    }
    
    Customer "1" --> "*" Order : places
    Order "1" --> "*" OrderItem : contains

Markdown Format:

````markdown

Business Entity Diagram: [Domain Name]

classDiagram
    class Customer {
        -identifier
        -name
        -email
        -status
    }
    
    class Order {
        -orderNumber
        -totalAmount
        -orderStatus
    }
    
    Customer "1" --> "*" Order : places

Business Entities

Customer

• Business Attributes:
• identifier: Unique customer identifier
• name: Customer full name (required)
• email: Contact email (must be unique)
• status: Account status (active, inactive, suspended)

Order

• Business Attributes:
• orderNumber: Unique order identifier
• totalAmount: Total order value in currency
• orderStatus: Current order state (pending, confirmed, shipped, delivered)
• Business Relationships:
• Placed by exactly one Customer
• Contains one or more OrderItems

````

Relationship Types in Mermaid:

• Association: --> General relationship
• Aggregation: o-- Has-a (shared lifetime)
• Composition: *-- Part-of (exclusive lifetime)
• Inheritance: <|-- Is-a (extends)
• Dependency: ..> Uses
• Cardinality: "1" --> "*" (one-to-many)

5. Use Case Diagram (Business Capabilities)

Use for: Business functionality, user interactions, business feature scope

When to extract from pseudocode:

if user.isCustomer():
  can: placeOrder, viewOrders, cancelOrder
if user.isAdmin():
  can: manageProducts, viewAllOrders, generateReports

Mermaid Flowchart (Use Case Alternative):

graph LR
    Customer([Customer])
    Admin([Admin])
    
    subgraph "Order Management System"
        PlaceOrder[Place Order]
        ViewOrders[View Orders]
        CancelOrder[Cancel Order]
        ManageProducts[Manage Products]
        GenerateReports[Generate Reports]
    end
    
    Customer --> PlaceOrder
    Customer --> ViewOrders
    Customer --> CancelOrder
    Admin --> ViewOrders
    Admin --> ManageProducts
    Admin --> GenerateReports

Note: Mermaid doesn't have a dedicated use case diagram type. Use flowcharts or document use cases in structured markdown.

Markdown Format:

## Use Case Diagram: [System Name]

### Business Actors
- **Customer**: End user who purchases products
- **Admin**: System administrator

### Business Use Cases

**Place Order** (Customer)
- Business Purpose: Customer creates new order
- Business Precondition: Customer authenticated, items selected
- Business Postcondition: Order created, inventory reserved

**View Orders** (Customer, Admin)
- Business Purpose: View order history and status
- Business Precondition: Authenticated user
- Business Postcondition: Order list displayed

**Cancel Order** (Customer)
- Business Purpose: Customer cancels pending order
- Business Precondition: Order exists and is cancellable
- Business Postcondition: Order cancelled, inventory released

**Manage Products** (Admin only)
- Business Purpose: Add, edit, or remove products
- Business Precondition: Admin authentication
- Business Postcondition: Product catalog updated

**Generate Reports** (Admin only)
- Business Purpose: Create business and operational reports
- Business Precondition: Admin authentication
- Business Postcondition: Report generated

Diagram Creation Guidelines

Choosing the Right Diagram

Best Practices

Keep it Simple:

• One diagram per business concept
• Maximum 7-10 elements per diagram
• Break complex business flows into multiple views

Be Consistent:

• Use standard Mermaid syntax
• Consistent business terminology
• Same level of business abstraction throughout

Add Business Context:

• Title clearly describes the business process shown
• Use notes for business rules and constraints
• Brief description of diagram's business purpose

Focus on Business Clarity:

• Prioritize business readability over technical completeness
• Use proper direction (TD, LR, etc.)
• Label transitions and relationships with business meaning

Integration with Functional Specifications

Link Diagrams to Functional Requirements:

````markdown

FR-010: Order Processing

See Business Flow Diagram: Order Processing

[Detailed functional requirement text...] ````

Embed in Specification Sections:

• Business Overview: Use Case Diagram or Business Journey
• Business Workflow: Flowchart or Sequence Diagram
• Business Data Requirements: Class Diagram
• Business State Management: State Diagram

Traceability:

• Reference diagram elements in functional requirements
• Link diagram components to FR and BR IDs
• Version diagrams with functional specifications

Why Use Business Flow Diagrams?

Benefits for Functional Specifications:

• Clarify complex business logic visually
• Show business decision points clearly
• Illustrate business entity relationships
• Document business state transitions
• Communicate business processes to stakeholders

When to Use:

• Functional specifications
• Business requirements documents
• README files documenting business capabilities
• Business process documentation
• Stakeholder communication materials

When NOT to Use:

• Technical architecture documentation
• Implementation guides
• Deployment diagrams
• Technical design documents
• Performance analysis

Requirements Patterns

This document describes common business and functional patterns to recognize in pseudocode and how to extract corresponding functional requirements. These patterns focus on WHAT the system does from a business perspective, excluding implementation, design, and performance details.

Pattern Recognition Guide

1. CRUD Operations Pattern

Pseudocode Indicators:

create/insert/add
read/get/fetch/retrieve
update/modify/change
delete/remove

Extract:

• Business Entity: What business concept is being managed
• Business Operations: Create, Read, Update, Delete from business perspective
• Business Validation Rules: Business constraints on input data
• Business Access Rules: Who can perform which business operations
• Business Audit: What business events need tracking

Requirements Template:

FR-[ID]: [Entity] Business Management

Create Operation:
- Business Input: [Entity fields with business meaning and constraints]
- Business Validation: [Required fields, business format rules, business logic]
- Business Output: [Created entity with business identifier]
- Business Side Effects: [Business notifications, audit events]

Read Operation:
- Business Input: [Business identifier or search criteria]
- Business Output: [Entity business data or list]
- Business Filtering: [Available business filter criteria]
- Business Sorting: [Available business sort options]

Update Operation:
- Business Input: [Entity identifier + fields to update]
- Business Validation: [Field constraints, business rules]
- Business Output: [Updated entity]
- Business Rules: [What can/cannot be changed, when]

Delete Operation:
- Business Input: [Entity identifier]
- Business Validation: [Check business dependencies]
- Business Type: [Permanent removal or business archival]
- Business Side Effects: [Impact on related business entities]

2. Validation Pattern

Pseudocode Indicators:

if field is empty/null
if length > max or < min
if not matches pattern
throw error "validation failed"

Extract:

• Field-Level Rules: Type, format, length, range
• Business Rules: Cross-field validation, contextual rules
• Error Messages: User-facing validation messages
• Error Handling: How validation failures are reported

Requirements Template:

BR-[ID]: [Field/Entity] Business Validation

Business Field Rules:
- [field1]: Required for business, Must match business format [pattern]
- [field2]: Optional, Business range: 1-100
- [field3]: Required, Business values: [value1, value2, value3]

Business Logic Rules:
- Rule 1: If [business condition], then [field] must [business constraint]
- Rule 2: [field1] combined with [field2] must satisfy [business rule]

Business Error Messages:
- Missing required field: "[Business-friendly message]"
- Invalid format: "[Business-friendly explanation]"
- Out of range: "[Business constraint explanation]"

3. State Machine Pattern

Pseudocode Indicators:

if state == "initial"
  state = "processing"
else if state == "processing"
  if condition:
    state = "completed"
  else:
    state = "failed"

Extract:

• Business States: All possible business states
• Business Transitions: Valid business state changes
• Business Triggers: Business events causing transitions
• Business Guards: Business conditions for transitions
• Business Actions: Business side effects during transition

Requirements Template:

FR-[ID]: [Entity] Business Lifecycle

Business States:
- [state1]: [Business meaning, business entry/exit actions]
- [state2]: [Business meaning, business entry/exit actions]

Business Transitions:
From [state1] to [state2]:
- Business Trigger: [Business event or user action]
- Business Guard: [Business condition that must be true]
- Business Actions: [Business notifications, updates to related entities]

Initial Business State: [state1]
Final Business States: [state2], [error_state]

Business Invariants:
- [Business property that must hold in all states]

4. Workflow/Pipeline Pattern

Pseudocode Indicators:

step1()
result1 = process(input)
result2 = transform(result1)
output = finalize(result2)

Extract:

• Business Stages: Sequential business processing steps
• Business Data Flow: Business input/output at each stage
• Business Transformations: How business data changes
• Business Dependencies: Business stage dependencies
• Business Error Handling: Business failure recovery

Requirements Template:

FR-[ID]: [Process Name] Business Workflow

Business Purpose: [Business goal and value]

Business Stages:

Stage 1: [Business Stage Name]
- Business Input: [Business data required]
- Business Processing: [Business logic applied]
- Business Output: [Business result]
- Business Rules: [Applicable business constraints]
- Business Error Handling: [Business recovery strategy]

Stage 2: [Business Stage Name]
- Business Input: [Output from Stage 1]
- Business Processing: [Business transformation logic]
- Business Output: [Business result]
- Business Dependencies: [Other business processes]

Stage N: [Business Stage Name]
- Business Input: [Previous stage output]
- Business Processing: [Final business actions]
- Business Output: [Final business result]

Business Error Handling:
- Stage failure: [Business impact and mitigation]
- Business validation failure: [Business decision: reject or proceed]

5. Calculation/Algorithm Pattern

Pseudocode Indicators:

result = 0
for each item:
  result += calculate(item)
return result

Extract:

• Business Inputs: Business parameters and preconditions
• Business Algorithm: Business calculation steps and logic
• Business Outputs: Business results and format
• Business Edge Cases: Business boundary conditions

Requirements Template:

FR-[ID]: [Calculation Name]

Business Purpose: [What business value this calculates and why]

Business Inputs:
- [param1]: [Business meaning, constraints, valid business range]
- [param2]: [Business meaning, description]

Business Calculation Logic:
1. [Business step description with business formula if applicable]
2. For each [business item] in [business collection]:
   - [Business calculation or operation]
3. [Final business step]

Business Formula: [Business calculation expression]

Business Outputs:
- [Result]: [Business meaning, format, precision]

Business Edge Cases:
- Empty input: [Business behavior]
- Zero/negative values: [Business behavior]
- Maximum values: [Business behavior]
- Division by zero: [Business error handling]

Business Examples:
- Business Scenario 1: [Context] → [Expected result]
- Business Scenario 2: [Edge case context] → [Expected result]

6. Authentication/Authorization Pattern

Pseudocode Indicators:

if not authenticated:
  return "Unauthorized"
if not hasPermission(user, resource):
  return "Forbidden"

Extract:

• Business Authentication: How business identity is verified
• Business Authorization: Business permission checking
• Business Roles: User roles and business capabilities
• Business Resources: Protected business resources
• Business Security Rules: Business access control policies

Requirements Template:

FR-[ID]: [Resource] Business Access Control

Business Authentication:
- Required: [Yes/No for this business resource]
- Business Identity: [How user identity is established]

Business Authorization:

Business Roles:
- [role1]: [Business description and capabilities]
- [role2]: [Business description and capabilities]

Business Permissions:
- [resource].[action]: Required business roles: [role1, role2]
- [resource].[action]: Required business roles: [role3]

Business Access Rules:
- Rule 1: [role] can [action] if [business condition]
- Rule 2: Owner can always [action] on own [resource]
- Rule 3: Public [resources] allow [action] without authentication

Business Error Conditions:
- Missing authentication: [Business impact and user message]
- Insufficient permissions: [Business impact and user message]

Business Audit:
- Log: [What business events to track]
- Alert: [Business conditions for alerts]

7. Event-Driven Pattern

Pseudocode Indicators:

on event:
  handle(event)
  trigger otherEvent

Extract:

• Business Events: Business event types and data
• Business Handlers: Business processing logic for each event
• Business Publishers: What business actions generate events
• Business Subscribers: Which business functions react to events
• Business Event Flow: Cascading business events

Requirements Template:

FR-[ID]: [Business Event Name]

Business Event Definition:
- Name: [Business event name]
- Business Trigger: [What business action causes this event]
- Business Data:
  - eventId: Unique event identifier
  - timestamp: When business event occurred
  - businessData: [Business-relevant data fields]

Business Publishers:
- [System/Process]: Publishes when [business condition occurs]

Business Subscribers:
- [BusinessHandler1]: [What business action it performs]
- [BusinessHandler2]: [What business action it performs]

Business Processing Rules:
- Must process event: [Yes/No - business requirement]
- Processing order matters: [Yes/No - business requirement]

Cascading Business Events:
- On business success: Trigger [next business event]
- On business failure: Trigger [error business event]

Business Idempotency:
- Can process same event multiple times: [Yes/No]
- Business deduplication strategy: [How to handle duplicates]

8. Batch Processing Pattern

Pseudocode Indicators:

batch = []
for each item in items:
  batch.add(item)
  if batch.size >= batchSize:
    processBatch(batch)
    batch.clear()
if batch.size > 0:
  processBatch(batch)

Extract:

• Business Batch Size: Items per business batch
• Business Batch Processing: How batches are handled in business terms
• Business Triggers: What causes batch processing
• Business Partial Failures: Handling of partial batch failures

Requirements Template:

FR-[ID]: [Operation] Business Batch Processing

Business Batch Configuration:
- Batch Size: [Number of business items]
- Business Trigger: [Size threshold OR time threshold]

Business Batching Strategy:
- Collect: [How business items are accumulated]
- Process: [How batch is processed from business perspective]

Business Error Handling:
- Partial Success: [Business decision: continue, reject all, or mark failed items]
- Business Impact: [Effect on related business processes]

Business Rules:
- Maintain Order: [Yes/No - business requirement]
- Process Order: [Sequential or can be parallel from business view]

Usage Guide

When analyzing pseudocode:

1. Identify Business Pattern: Match code structure to business patterns above 2. Extract Business Elements: Pull out business-specific components 3. Generate Functional Requirements: Use appropriate template focused on business logic 4. Add Business Context: Include business rules and constraints 5. Validate Completeness: Ensure all business logic paths covered

Focus on Business Functionality:

• Describe WHAT from business perspective, not HOW from technical perspective
• Extract business rules, not implementation strategies
• Document business behavior, not performance characteristics
• Specify business constraints, not technical optimizations

For Multiple Patterns:

• Code often contains multiple business patterns
• Extract functional requirements for each pattern
• Link related business requirements
• Create hierarchy (business process contains business rules contains business validation)

Pattern Combinations:

• Workflow + CRUD + Validation (common for business processes)
• Event + State Machine (common for business event systems)
• Authentication + Authorization + CRUD (common for business APIs)

Specification Templates

This document provides templates for functional specification documents generated from pseudocode analysis. These templates focus exclusively on what the system does (functional requirements) and exclude design, implementation, and testing details.

Software Requirements Specification (SRS) Template

# Software Requirements Specification
# [System Name]

Version: [X.Y]
Date: [YYYY-MM-DD]
Status: [Draft/Review/Approved]

## 1. Introduction

## 1.1 Purpose
[What this SRS describes and who should read it]

### 1.2 Scope
[System name, what it does, benefits, objectives]

### 1.3 Definitions, Acronyms, and Abbreviations
[Glossary of terms]

### 1.4 References
[Related documents]

### 1.5 Overview
[Organization of remainder of SRS]

## 2. Overall Description

### 2.1 Product Perspective
[System context, interfaces, operations, site adaptation]

### 2.2 Product Functions
[Summary of major functions]

### 2.3 User Characteristics
[User roles, business knowledge, domain expertise]

## 3. Specific Requirements

### 3.1 Functional Requirements

#### 3.1.1 [Function/Feature Name]
**Introduction:** [Purpose and scope]
**Inputs:** [Data sources and formats]
**Processing:** [Steps and business rules]
**Outputs:** [Results and side effects]

### 3.2 External Interface Requirements

#### 3.2.1 User Interactions
[Types of user interactions, modes of access]

#### 3.2.2 System Interfaces
[Logical connections to other systems, data exchanged]

#### 3.2.3 Data Formats
[Input/output data structures and constraints]

### 3.3 Business Rules and Constraints
[Complete business logic, validation rules, calculations]

## 4. Appendices

### Appendix A: Data Dictionary
[Business data element definitions and constraints]

### Appendix B: Business Rules Matrix
[Complete listing of conditions, actions, and business logic]

Functional Specification Template

# Functional Specification
# [Feature/Component Name]

## Document Control
- Version: [X.Y]
- Author: [Name]
- Date: [YYYY-MM-DD]
- Status: [Draft/Review/Final]

## 1. Executive Summary
[High-level overview of feature and business value]

## 2. Background and Context
[Problem statement, business drivers, current state]

## 3. Goals and Objectives
- Goal 1: [Measurable objective]
- Goal 2: [Measurable objective]

## 4. Scope
### In Scope
- [Item 1]
- [Item 2]

### Out of Scope
- [Item 1]
- [Item 2]

## 5. Functional Requirements

### 5.1 User Stories

As a [role] I want [capability] So that [benefit]

Acceptance Criteria:

• [ ] Criterion 1
• [ ] Criterion 2

### 5.2 Detailed Functionality

#### 5.2.1 [Feature Name]
**Description:** [What it does]
**User Interaction:** [How users access/use it]
**Business Rules:**
- Rule 1: [Condition and action]
- Rule 2: [Condition and action]

**Data Requirements:**
- Input: [Data needed]
- Output: [Data produced]
- Validation: [Rules]

**Error Handling:**
- Error 1: [Condition and message]
- Error 2: [Condition and message]

## 6. Business Rules and Constraints
[Complete business logic, validation rules, calculation formulas]

## 7. Data Requirements
[Business entities, relationships, attributes, constraints]

## 8. Dependencies and Assumptions
[External system dependencies at functional level, assumptions made]

## 9. Open Issues and Risks
- [Issue 1] - [Impact] - [Mitigation]
- [Issue 2] - [Impact] - [Mitigation]

## 10. Appendices
[Additional business rules, glossary, references]

Functional Service Requirements Template

# Functional Service Requirements
# [Service Name]

## Overview
**Purpose:** [What business problem this service solves]
**Version:** [X.Y.Z]
**Scope:** [Business boundaries and responsibilities]

## Service Functions

### [Function Name]

**Business Purpose:** [Why this function exists, business value]

**Functional Description:** [What this function does in business terms]

**Inputs:**
- Input 1: [Business data required]
  - Required: [Yes/No]
  - Constraints: [Business rules and validation]
  - Format: [Logical format description]

**Processing Logic:**
1. [Business rule or logic step]
2. [Calculation or transformation]
3. [Decision point and branching logic]

**Outputs:**
- Output 1: [Business data produced]
  - Conditions: [When this output is generated]
  - Format: [Logical format description]

**Business Rules:**
- Rule 1: [Condition] → [Action]
- Rule 2: [Validation or constraint]
- Rule 3: [Calculation formula]

**Error Conditions:**
- Error 1: [Business condition that causes error]
  - Message: [User-facing description]
  - Recovery: [What user should do]

**Preconditions:**
[What must be true before function can execute]

**Postconditions:**
[What will be true after successful execution]

## Service Dependencies

### [External Service/System]
**Purpose:** [Why this dependency exists]
**Data Exchanged:** [Business data sent/received]
**Frequency:** [When/how often interaction occurs]
**Failure Handling:** [Business impact and mitigation]

## Data Definitions

### [Data Structure Name]
**Purpose:** [Business meaning and use]

**Fields:**
- field_name: [Business meaning, constraints, validation rules]

**Business Rules:**
- [Rule governing this data structure]

Business Entity Requirements Template

# Business Entity Requirements

## Entity: [EntityName]

### Business Description
[What this entity represents in business terms, its purpose and role]

### Business Attributes

| Attribute | Business Meaning | Required | Constraints | Valid Values |
|-----------|------------------|----------|-------------|-------------|
| identifier | Unique business identifier | Yes | Must be unique | [Format/pattern] |
| name | Business name/label | Yes | Max 255 characters | [Any restrictions] |
| status | Current state in lifecycle | Yes | Single value | active, inactive, pending |
| category | Business classification | No | From approved list | [Category values] |

### Business Relationships

**Relationship to [OtherEntity]:**
- Type: [One-to-one / One-to-many / Many-to-many]
- Business Meaning: [Why this relationship exists]
- Cardinality: [Minimum and maximum occurrences]
- Business Rules: [Rules governing the relationship]

### Business Rules and Constraints

#### Creation Rules
- Rule 1: [What must be true to create this entity]
- Rule 2: [Default values and initialization]

#### Modification Rules
- Rule 1: [What can/cannot be changed]
- Rule 2: [Conditions for updates]
- Rule 3: [State transition rules]

#### Deletion Rules
- Rule 1: [When entity can be removed]
- Rule 2: [Dependencies that prevent deletion]
- Rule 3: [Cascade behavior in business terms]

#### Validation Rules
- Rule 1: [Format or pattern validation]
- Rule 2: [Business logic validation]
- Rule 3: [Cross-field validation]

### Lifecycle States

**State: [StateName]**
- Business Meaning: [What this state means]
- Entry Conditions: [How entity enters this state]
- Exit Conditions: [How entity leaves this state]
- Allowed Transitions: [StateName] → [NextState]

### Business Invariants
[Conditions that must always be true for this entity]

### Example Business Scenarios

**Scenario 1: [Scenario Name]**
- Context: [Business situation]
- Entity State: [Attribute values]
- Business Rules Applied: [Which rules are relevant]

Usage Guidelines

Strict Functional Focus:

These templates focus exclusively on functional requirements - what the system does, the business logic it implements, and the rules it enforces. They intentionally exclude:

• Design details - UI layouts, visual design, architecture patterns
• Implementation details - Technologies, frameworks, database schemas, API protocols
• Testing details - Test cases, test strategies, quality metrics
• Non-functional requirements - Performance, scalability, security implementations

Choose Template Based on Context:

• SRS - Complete system functional specification, formal documentation of business behavior
• Functional Spec - Feature-level functional detail, user stories, business rules
• Functional Service Requirements - Service-level business logic and data flows
• Business Entity Requirements - Business data definitions, rules, and constraints

Adapt Templates:

• Remove sections not relevant to business logic from pseudocode
• Add sections for domain-specific business rules and constraints
• Focus on "what" the system does, not "how" it's built or "how well" it performs
• Describe behavior, not implementation
• Specify business rules, not technical solutions

What to Include:

• Business logic and rules
• Data validation constraints
• User interactions and workflows
• Business calculations and formulas
• State transitions and conditions
• Error conditions and business exceptions

Traceability:

• Link specifications back to pseudocode sections
• Use consistent identifiers (FR-001, BR-001, etc.)
• Reference line numbers or code blocks from pseudocode
• Maintain requirements traceability matrix