pseudocode-to-specification

What this skill does

# 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](references/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](references/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:**

```markdown
# [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](references/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 → Busines