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