### 🇺🇸
### 5W1H Analysis Method

| Dimension | Question | Analysis Points |
|-----------|----------|----------------|
| **Why** | Why do it? | Business background, goals, value |
| **What** | What to do? | Feature scope, business content |
| **Who** | Who does it? | Role division, responsibility boundaries |
| **When** | When to do? | Time requirements, milestones |
| **Where** | Where to do? | Usage scenarios, environment |
| **How** | How to do? | Implementation approach, process |

### MECE Principle

Ensure business analysis is complete and non-overlapping: Mutually Exclusive (analysis items don't overlap) | Collectively Exhaustive (covers all business scenarios)

**Checklist**: Are sub-categories mutually exclusive? | Are all categories fully covered? | Any missing business scenarios? | Any overlapping feature definitions?

### CRUD Matrix

Analyze entity-operation mapping (entity × Create/Read/Update/Delete + List/Export)

### Multi-Perspective Business Design Analysis

**Trigger Condition**: When the following perspective documents are provided, MUST analyze business design from different angles rather than from a single perspective:

#### Three Core Analysis Perspectives

| Perspective | Focus Areas | Analysis Output |
|------------|-------------|-----------------|
| **User Perspective** | User experience, operational convenience, interface interaction, learning cost, error tolerance | User journey map, interaction flow, pain point list |
| **Department Architecture Perspective** | Department responsibility boundaries, cross-department collaboration processes, approval hierarchies, permission divisions, organizational adaptation | Cross-department swimlane diagram, RACI matrix, organizational adaptation table |
| **Role Perspective** | Role permission matrix, role responsibility definitions, inter-role collaboration, role switching scenarios | Role profiles, permission matrix, role interaction diagram |

#### Analysis Flow

```
Step A: Identify Available Perspective Documents
  ├── User perspective docs exist? → Extract user journeys and pain points
  ├── Department architecture docs exist? → Extract organizational relationships and collaboration flows
  └── Role perspective docs exist? → Extract role permissions and responsibility boundaries

Step B: Cross-Validation
  ├── User needs vs Department constraints → Identify conflicts and prioritize
  ├── Role permissions vs Org architecture → Check consistency between permissions and department responsibilities
  └── User journeys vs Role switching → Verify role switching scenarios are fully covered

Step C: Integrated Output
  └── Integrate multi-perspective findings into the Who/How dimensions of 5W1H analysis
```

#### Multi-Perspective Analysis Checklist

- [ ] Have user perspective documents been collected? If yes, have key journeys and pain points been extracted?
- [ ] Have department architecture documents been collected? If yes, have cross-department collaboration rules been mapped?
- [ ] Have role perspective documents been collected? If yes, has a complete role permission matrix been defined?
- [ ] Have rule conflicts between different perspectives been identified and annotated?
- [ ] Is any perspective not covered by documents? Is it marked as inferred/to-be-confirmed?
- [ ] Do the integrated business rules maintain the MECE principle (no omissions, no overlaps)?

#### Multi-Perspective Conflict Resolution Rules

| Conflict Type | Resolution | Priority |
|--------------|------------|----------|
| User needs vs Department constraints | Mark conflict, department constraints take priority; record UX impact in risks | P0 |
| Role permissions vs Org architecture | Follow org architecture; mark permission differences as to-be-confirmed | P1 |
| User journeys vs Role switching | Supplement missing role switching scenarios, mark as inferred | P2 |
| Cross-department flow vs Single-role operation | Follow cross-department flow; ensure each department has clear responsible person | P1 |