### 🇺🇸
### Step 0: Multi-Perspective Document Scan (Pre-step)
Before standard analysis, scan whether the following perspective documents exist:
- **User perspective documents**: User requirement specifications, user personas, user research reports, UX design drafts
- **Department architecture perspective documents**: Org charts, department function descriptions, cross-department collaboration norms, management hierarchy files
- **Role perspective documents**: Role permission tables, job responsibility descriptions, approval authority matrices, role definition documents

If any perspective documents exist, execute the "Multi-Perspective Business Design Analysis" process (see Methodology Toolbox).

### Step 1: Requirement Gathering
PRD document text | Business process descriptions | Business rule documents | Existing system screenshots/docs | Competitive analysis materials | User perspective docs | Department architecture docs | Role perspective docs → Output: Raw requirement list

### Step 2: 5W1H Analysis

Six-dimensional analysis for each requirement:
- **Why**: Business background / Core value / Success criteria
- **What**: Feature description / Scope boundaries / Out of scope items
- **Who**: Initiating role / Participating roles / Approval roles / Beneficiary roles (**If role perspective docs exist, use them for role mapping**)
- **When**: Start time / End time / Periodicity (real-time/cyclical/event)
- **Where**: Usage scenarios / Usage environment / Access method (**If user perspective docs exist, use them to define usage scenarios**)
- **How**: Implementation approach / Key processes / Technical constraints (**If department architecture docs exist, consider cross-department collaboration and approval hierarchies**)

### Step 3: Business Modeling

**a. Use Case Diagram**: Actors + Use cases + Relationships
  - **Multi-perspective supplement**: If user perspective docs exist, include end users as actors; if role perspective docs exist, divide actors by role; if department architecture docs exist, note cross-department actors

**Use Case Template**:
```markdown
### UC-[ID]: [Use Case Name]
**Actors**: [Primary actor]
**Preconditions**: [State before entering system]
**Basic Flow**: 1.[Step 1] → 2.[Step 2] → 3.[Step 3]
**Alternative Flows**: [Condition A]:[Alt 1] | [Condition B]:[Alt 2]
**Exception Flows**: [Exception 1]:[Handling]
**Involved Roles**: [Role 1], [Role 2]  (if role perspective docs exist)
**Involved Departments**: [Dept 1], [Dept 2]  (if dept architecture docs exist)
**User Impact**: [UX impact description]  (if user perspective docs exist)
```

**b. Process Flow**: Start → Decision → Branch processing → Loop → End
  - **Multi-perspective supplement**: If dept architecture docs exist, use swimlane diagrams to mark department responsibilities; if role perspective docs exist, mark execution roles for each step

**c. State Diagram**:

**State Definition Template**:
```markdown
### Entity State Machine
**Entity**: [Entity Name]
| State | Code | Meaning | Transitions To | Operating Role | Visible Depts |
|-------|------|---------|---------------|----------------|--------------|
| Draft | DRAFT | Initial state | SUBMITTED | Creator | Own dept |
| Submitted | SUBMITTED | Pending review | APPROVED, REJECTED | Reviewer | Related depts |
| Approved | APPROVED | Review passed | ARCHIVED | Approver | All depts |
| Rejected | REJECTED | Review rejected | DRAFT | Reviewer | Own dept |
```

### Step 4: CRUD Matrix Generation
Complete operation matrix: Entity × Create/Read/Update/Delete/List/Export
  - **Multi-perspective supplement**: Mark allowed roles and visible department scope for each operation

### Step 5: Business Rule Extraction

| Rule ID | Rule Description | Constraint Type | Priority | Source Perspective | Source Document |
|---------|-----------------|-----------------|----------|-------------------|-----------------|
| BR-001 | [Rule description] | Hard/Soft rule | P0/P1/P2 | User/Dept/Role | [Doc reference] |

**Permission Rule Sub-Template** (when business involves multi-role, multi-level data visibility): Describe row-level permissions (who sees which rows), column-level permissions (who sees which fields), aggregation-level permissions (to what granularity each role can drill down). Annotate each level with equivalent data scope conditions (SQL WHERE clause or natural language).

### Step 6: Iterative Deepening (Optional Enhancement)

**Trigger**: When user requests "further detailed breakdown," "deeper analysis," or "drill down to specific business points."

**Standard Deepening Path**: Progress from coarse to fine, each level building on the previous:

| Level | Direction | Deliverable Increment |
|-------|----------|----------------------|
| L1 System | Define system boundaries, 5W1H | System definition doc |
| L2 Module | Decompose into functional modules | Feature requirements list |
| L3 Role | Define landing-page metrics per role | Per-role metric table |
| L4 Person | Define metrics per specific position (using org charts) | Per-person, per-business-line metric table |
| L5 Scenario | Inject special business scenarios, analyze per scenario | Special scenario analysis doc |
| L6 Chain | Define drill-down path→terminal business data per metric | Metric-drilldown chain mapping table |
| L7 Integration | Merge fragmented docs into authoritative final version | Final requirements specification |

**Triggers EXEC-BA-006**: Jumping to next level when current level is incomplete → 🟡 WARN → Suggest "Current level is not fully covered. Continue deepening current level?"