analyze-business-requirements

name: analyze-business-requirements description: Guide the process of reviewing a business requirements document to identify potential issues and generate clarifying questions license: Apache-2.0 metadata: olaf_tags: [business, requirements, analysis, review, documentation] copyright: Copyright (c) 2026 pjmp020564 author: pjmp020564 (on github) repository: https://github.com/haal-ai/haal-ide provider: Haal AI

if you are in need to get the date and time, use time tools, fallback to shell command if needed

Input Parameters

You MUST request these parameters if not provided by the user. Present them as a numbered list to ease user response.

1. requirements_document: string - Path to the business requirements document to analyze (REQUIRED)
2. strict_template_compliance: boolean - Whether to strictly follow the template format (OPTIONAL, default: true)

User Interaction

You MUST follow these interaction guidelines:

• Ask for user approval before creating or modifying files
• Present options as numbered lists for easy selection
• Provide clear progress updates at each major step

Prerequisites (if applicable)

If this prompt is part of a workflow chain:

1. You MUST verify the preceding phase/action was completed
2. You WILL validate expected outcomes from previous step:
   • Business requirements document is available and accessible
   • Required template files exist in the system
   • Staging directory is accessible for output storage

Process

1. Validation Phase

You WILL verify all requirements:

• Confirm all required parameters are provided
• Validate requirements document exists and is accessible
• Check access to required tools and files

2. Execution Phase

You WILL execute these operations as needed:

Terminal Operations (when required):

• Get current timestamp using time tools, fallback to shell command if needed
• Validate command execution success

Tool Operations (when required):

• Use internal tool: file_reader for document analysis
• Use internal tool: file_writer for report generation

File Operations (when required):

• Read/Write file: [requirements_document] - Parse document structure and content
• Read/Write file: .olaf/data/practices/guidances/requirements/expressing-business-needs-to-developers.md - Apply analysis frameworks
• Read/Write file: .olaf/data/practices/guidances/requirements/reviewing-business-requirements-for-dev-and-test.md - Reference quality criteria
• Read/Write file: templates/requirements-analysis-report-template.md - Structure output format
• Write file: .olaf/work/staging/business-requirements-analysis-YYYYMMDD-NNN.md - Save analysis report

Core Logic: Execute following requirements

• Identify key requirements and potential structural issues
• Extract business objectives and functional requirements
• Categorize issues by severity and type (ambiguity, incompleteness, testability, inconsistencies)
• Generate constructive clarifying questions for each identified issue
• Structure analysis according to template format
• Provide actionable recommendations for improvement
• Complete core processing steps
• Provide required user confirmations

3. Validation Phase

You WILL validate results:

• Confirm all outputs meet template requirements
• Verify all issues include specific document section references
• Ensure constructive feedback guides improvement

Output Format

You WILL generate outputs following this structure:

• Primary deliverable: Follow template templates/requirements-analysis-report-template.md
• Supporting files: Analysis report saved to staging directory
• Documentation: Markdown format with proper categorization

User Communication

You WILL provide these updates to the user:

Progress Updates

• Confirmation when each major step completes
• Location/reference of any changes made
• Timestamp identifier used: [YYYYMMDD-HHmm format]

Completion Summary

• Summary of actions taken
• Files created/modified with locations
• Any issues encountered and resolutions

Next Steps (if part of workflow)

You WILL clearly define:

• Immediate next actions required
• Objectives for next phase (concise, specific)
• Files/resources provided to next phase
• Dependencies for next step

Domain-Specific Rules

You MUST follow these constraints:

• Rule 1: Always reference specific sections when identifying issues
• Rule 2: Generate constructive questions that guide toward solutions
• Rule 3: Categorize issues by type (ambiguity, incompleteness, testability, inconsistencies)
• Rule 4: Follow official template structure strictly for consistency

Success Criteria

You WILL consider the task complete when:

• All required parameters validated
• Core logic executed successfully
• Outputs generated in specified format
• User communication completed
• Next steps defined (if applicable)

Required Actions

1. Validate all required input parameters and prerequisites
2. Execute operations with user approval
3. Generate outputs in specified format
4. Provide user communication and confirmations
5. Define next steps if part of workflow

Error Handling

You WILL handle these scenarios:

• Missing Parameters: Request specific missing items from user
• File Access Issues: Provide clear error message and resolution steps
• Tool Failures: Offer alternative approaches or manual steps
• Validation Failures: Stop process and request user guidance

⚠️ Critical Requirements

• MANDATORY: Ask for user approval before creating or modifying files
• ALWAYS validate outputs before considering task complete
• ALWAYS provide rollback instructions for destructive operations
• ALWAYS document assumptions and limitations
• ALWAYS confirm user approval for significant changes