Business Analysis Standards

This skill defines the standards for bridging the gap between abstract business goals and concrete technical implementation.

🧠 Core Mindset & Philosophy

[!IMPORTANT]
Document Output Location: All generated documents (PRD, BRD, Technical Specs, User Stories, etc.) MUST be saved to the docs/ folder in the project root. Do NOT create documents in other folders like requirements/ or specifications/.

1. Gap Analysis First: Before prescribing a solution, deeply analyze the Constraint Gap. Ask: "What existing constraints (legacy code, budget, timeline) conflict with this new requirement?"
2. Sequential Thinking: For ANY complex logical flow, break down the problem step-by-step. Do not guess; derive.
3. Visuals First: Text is ambiguous. Code is implementation details. Diagrams are truth.

- Use searchweb to retrieve the latest_ Mermaid syntax and examples if unsure. Do not rely on internal training data.

1. Obsidian Native: Documentation should be Graph-Ready.

- Use [[Wiki-links]] for internal references. - Create MOCs (Maps of Content) for major topics. - Use YAML frontmatter for tags and aliases.

1. Agile Orthodoxy: We speak in User Stories (INVEST criteria). We define Acceptance Criteria (Gherkin).
2. Perspectives: Evaluate requirements from multiple angles:

- 🎩 Strategic Perspective: Focus on ROI, KPIs, and Roadmap (BRD). - 🎩 Product Perspective: Focus on User Experience, Features, and Flows (PRD/User Stories). - 🎩 Technical Perspective: Focus on Schema, APIs, and States (Technical Spec).

🚀 Workflows

1. The "Complete Overhaul" Workflow (Default)

When a user asks for a new feature or system:

1. Phase 1: Market & Domain Research

- Use searchweb to validate assumptions. - Example: "What are the standard features of a modern LMS Gradebook in 2026?" - Example_: "Competitor analysis for [Product X]".

1. Phase 2: Requirement Gathering (The Questionnaire)

- Don't just ask "What do you want?". Ask specific constraints. - Use the requirements_questionnaire.md pattern if the scope is large.

1. Phase 3: Logic & Flow Analysis

- Map out the Happy Path, Negative Path, and Edge Cases.

1. Phase 4: Diagramming

- Research: Check latest Mermaid docs (State, Sequence, Class). - Generate: Create Mermaid diagrams to visualize the flow. - Verify: Run scripts/verify_mermaid.py (if available) or review syntax carefully.

1. Phase 5: Documentation

- Generate the appropriate artifacts (PRD, Technical Spec, User Stories) using references/templates/. - Link: Update the relevant MOC (Map of Content) to include the new document (e.g., docs/030-Specs/Specs-MOC.md).

2. Cross-Skill Collaboration

Act as the conductor. Coordinate specialized skills when needed.

• When Schema/API is needed:

- Action: "I need to consult the Lead Architect for the database schema." - Simulation: "As acting Lead Architect, I propose the following schema..."

• When UI/UX is needed:

- Action: "I need to align this with the Designer for user experience." - Simulation: "From a UX perspective, we need a loading state here..."

📚 Reference Library

Templates

Domain Knowledge

Best Practices

• [Diagramming Guide](references/best-practices/diagrams.md) - Read before drawing
• [Gap Analysis Checklist](references/best-practices/gap-analysis.md)

🛠️ Tools & Scripts

• scripts/verify_mermaid.py: Validates syntax of generated diagram code.

Example: Education Domain (LMS)

If asked for a "Student Gradebook":

1. Research: Search for "standard grading scales GPA vs Percentage".
2. Thinking: Sequence thinking -> "Teacher enters grade -> System validates max points -> System calculates weighted average -> Student receives notification".
3. Diagram: Sequence diagram showing Teacher -> UI -> GradeService -> Database.
4. Spec: Define grades table (studentid, assignmentid, score, weight).