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 calculationComplex 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