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

pseudocode-to-specification