symbiosis

Category: Tools & Productivity | Uploader: h315uk3 | Downloads: 0 | Version: v1.0（Latest）
Analyze collected requirements from interviews, detect ambiguities, generate structured specifications, and suggest implementation approaches
Changelog: Source: GitHub https://github.com/h315uk3/symbiosis
Directory Structure

Current level: tree/main/plugins/with-me/skills/requirement-analysis/
📄 SKILL.md 13.2 KB
SKILL.md

---
description: "Analyze collected requirements from interviews, detect ambiguities, generate structured specifications, and suggest implementation approaches"
context: fork
allowed-tools: [Bash, Read]
---

# Requirement Analysis Skill

This skill transforms raw interview data into structured, actionable requirement specifications.

---

## When to Use This Skill

Use this skill after completing a requirement elicitation interview (e.g., via `/good-question`) when you have:
- Collected answers across multiple requirement dimensions
- Raw notes from developer conversations
- Unstructured information that needs formalization

**Do not use this skill:**
- During active interviews (use it after information gathering is complete)
- For code analysis or implementation tasks
- When requirements are already well-structured

---

## What This Skill Does

### 1. Structure Requirements

Transform raw interview data into a formal specification organized by:
- **Purpose**: Problem statement, stakeholders, value proposition
- **Data**: Input/output specifications, data models, transformations
- **Behavior**: Functional flows, state transitions, business logic
- **Constraints**: Technical requirements, limitations, dependencies
- **Quality**: Success criteria, testing requirements, edge cases

### 2. Detect Issues

Identify and report:
- **Ambiguities**: Vague or underspecified requirements
- **Contradictions**: Conflicting statements or incompatible requirements
- **Gaps**: Missing information critical for implementation
- **Assumptions**: Implicit assumptions that need validation

### 3. Generate Implementation Guidance

Provide:
- **Architecture Recommendations**: Suggested technical approaches
- **Risk Assessment**: Potential challenges and mitigation strategies
- **Testing Strategy**: Test scenarios based on requirements
- **Open Questions**: Remaining uncertainties to resolve

---

## Input Format

**PREFERRED: Dimension Data JSON (from /good-question)**

If invoked after a `/good-question` interview, provide dimension data in JSON format:

```json
{
  "purpose": {
    "answered": true,
    "content": "English summary of purpose answers with examples",
    "examples": 2,
    "contradictions": false
  },
  "data": {
    "answered": true,
    "content": "English summary of data answers with examples",
    "examples": 1,
    "contradictions": false
  },
  "behavior": {
    "answered": true,
    "content": "English summary of behavior answers with examples",
    "examples": 3,
    "contradictions": false
  },
  "constraints": {
    "answered": true,
    "content": "English summary of constraints answers with examples",
    "examples": 1,
    "contradictions": false
  },
  "quality": {
    "answered": true,
    "content": "English summary of quality answers with examples",
    "examples": 0,
    "contradictions": false
  }
}
```

**CRITICAL**: Content fields MUST be in English for uncertainty calculation to work correctly.

---

**ALTERNATIVE: Raw Interview Data**

For ad-hoc analysis without `/good-question`, provide raw interview data:

```markdown
## Interview Transcript

User said: "I want to build a dashboard..."
Question 1: What problem does this solve?
Answer: "Users need to see their metrics..."

Question 2: What data is involved?
Answer: "User activity logs, API call counts..."

[etc.]
```

Or as structured notes:

```markdown
## Collected Information

Purpose: Users need visibility into system metrics
Data: Time-series data from monitoring APIs
Behavior: Real-time updates every 30 seconds
Constraints: Must work in mobile browsers
Quality: No specific test requirements mentioned
```

---

## Output Format

### Structured Requirement Specification

```markdown
# Requirement Specification: [Project Name]

## 1. Purpose & Context

### Problem Statement
[Clear description of the problem being solved]

### Stakeholders
[Who will use this and how they benefit]

### Success Criteria
[What defines a successful implementation]

---

## 2. Functional Requirements

### Data Requirements

#### Inputs
- **Source**: [Where data comes from]
- **Format**: [Data structure and types]
- **Volume**: [Expected scale]
- **Validation**: [Required validations]

#### Outputs
- **Destination**: [Where results go]
- **Format**: [Output structure]
- **Transformations**: [Processing applied]

### Behavioral Requirements

#### Primary Flow
1. [Step-by-step description]
2. [Decision points and conditions]
3. [State changes]

#### Alternative Flows
- **Scenario**: [Alternative path description]
- **Trigger**: [What causes this path]

#### Edge Cases
- [Edge case 1]
- [Edge case 2]

---

## 3. Non-Functional Requirements

### Performance
- [Latency requirements]
- [Throughput requirements]
- [Resource constraints]

### Security
- [Authentication requirements]
- [Authorization rules]
- [Data protection needs]

### Compatibility
- [Platform requirements]
- [Browser/version support]
- [Dependency constraints]

---

## 4. Quality Requirements

### Testing Strategy
- **Unit Tests**: [What to test at unit level]
- **Integration Tests**: [What to test at integration level]
- **User Acceptance**: [How users will validate]

### Acceptance Criteria
- [ ] [Specific measurable criterion 1]
- [ ] [Specific measurable criterion 2]

---

## 5. Implementation Considerations

### Recommended Architecture
[Suggested technical approach with rationale]

### Technology Stack
- **Required**: [Must-use technologies]
- **Recommended**: [Suggested technologies]
- **Avoid**: [Technologies to avoid and why]

### Key Design Decisions
1. **Decision**: [What needs to be decided]
   - **Options**: [Available choices]
   - **Recommendation**: [Suggested choice with reasoning]

---

## 6. Risks & Challenges

### Technical Risks
- **Risk**: [Description]
  - **Impact**: [Severity]
  - **Mitigation**: [How to address]

### Requirement Risks
- **Risk**: [Ambiguity or gap]
  - **Impact**: [Effect on implementation]
  - **Resolution**: [How to clarify]

---

## 7. Open Questions

Questions that require clarification before or during implementation:

1. [Question about unclear aspect]
   - **Why it matters**: [Impact on implementation]
   - **Suggested resolution**: [How to resolve]

2. [Next question]

---

## 8. Next Steps

Recommended actions:

1. **Immediate**: [What to do right away]
2. **Before Implementation**: [Prerequisites]
3. **During Implementation**: [Ongoing considerations]
```

---

## Analysis Process

### Step 1: Organize Information

Group collected data by the five dimensions:
- Purpose answers → Problem statement, stakeholders
- Data answers → Input/output specifications
- Behavior answers → Functional flows
- Constraint answers → Non-functional requirements
- Quality answers → Testing strategy

### Step 2: Identify Issues

Scan for:
- **Ambiguous statements**: "fast enough", "user-friendly", "secure"
- **Contradictions**: Performance vs. feature richness conflicts
- **Gaps**: No mention of error handling, no data validation discussed
- **Implicit assumptions**: "Users will know how to...", "Data will always be..."

### Step 3: Synthesize Recommendations

Based on the requirements:
- Match requirements to appropriate architectural patterns
- Identify suitable technologies and frameworks
- Propose testing approaches aligned with quality needs
- Highlight design decisions that need stakeholder input

### Step 4: Assess Risks

Consider:
- **Complexity risks**: Requirements that suggest high complexity
- **Uncertainty risks**: Underspecified areas prone to rework
- **Dependency risks**: External systems or data sources
- **Performance risks**: Scale or speed requirements that may be challenging

---

## Example Usage

**Input:**
```
User wants to build a file upload feature with progress tracking.
- Files up to 1GB
- Must show upload progress
- Support multiple simultaneous uploads
- Works on mobile
- Mentioned "secure" but didn't specify details
```

**Analysis Output:**

```markdown
# Requirement Specification: File Upload Feature

## 1. Purpose & Context
### Problem Statement
Users need to upload large files (up to 1GB) with visibility into upload progress.

### Stakeholders
- End users uploading files from desktop and mobile browsers
- Backend system receiving and processing uploads

### Success Criteria
- Files up to 1GB upload successfully
- Progress is visible throughout upload
- Multiple uploads can occur concurrently
- Works on mobile browsers

---

## 2. Functional Requirements

### Data Requirements
#### Inputs
- **Source**: User file selection (browser file input)
- **Format**: Binary files, any MIME type, max 1GB
- **Validation**: File size must not exceed 1GB
- **Volume**: Multiple concurrent uploads per user

#### Outputs
- **Destination**: Server storage endpoint
- **Format**: Uploaded file plus metadata (filename, size, MIME type)
- **Confirmation**: Upload completion status

### Behavioral Requirements
#### Primary Flow
1. User selects file(s) to upload
2. System validates file size (reject if >1GB)
3. Upload begins with chunking for progress tracking
4. Progress indicator updates as chunks complete
5. Upload completes, user receives confirmation

#### Alternative Flows
- **Network interruption**: Resume or retry mechanism needed
- **Validation failure**: Clear error message shown

#### Edge Cases
- Upload interrupted mid-transfer
- Multiple uploads competing for bandwidth
- Mobile network transitions (WiFi to cellular)

---

## 3. Non-Functional Requirements

### Performance
- Progress updates at least every 2-3 seconds
- Multiple uploads shouldn't block UI
- Mobile browsers may have memory constraints

### Security
⚠️ **AMBIGUITY DETECTED**: "Secure" was mentioned but not specified.
**Needs clarification:**
- Authentication required before upload?
- File type restrictions (prevent malicious files)?
- HTTPS required?
- Virus scanning?

### Compatibility
- Must work in mobile browsers (iOS Safari, Android Chrome)
- Desktop browser support (Chrome, Firefox, Safari, Edge)

---

## 4. Quality Requirements

### Testing Strategy
- **Unit Tests**: Chunking logic, progress calculation
- **Integration Tests**: Upload flow end-to-end
- **Load Tests**: Multiple concurrent uploads
- **Mobile Tests**: Network interruption handling

### Acceptance Criteria
- [ ] 1GB file uploads successfully
- [ ] Progress bar updates smoothly
- [ ] 3 simultaneous uploads work without issues
- [ ] Feature works on iOS Safari and Android Chrome

---

## 5. Implementation Considerations

### Recommended Architecture
- **Chunked uploads**: Split large files into chunks (5-10MB) for progress tracking and resumability
- **Background workers**: Use Web Workers to avoid blocking main thread
- **Upload queue**: Manage concurrent uploads to prevent resource exhaustion

### Technology Stack
- **Recommended**:
  - XMLHttpRequest or Fetch API with upload progress events
  - File API for client-side chunking
  - Server: Multipart upload or chunked transfer encoding
- **Avoid**:
  - Simple form POST (no progress tracking)

### Key Design Decisions
1. **Chunking Strategy**
   - **Options**: Fixed chunk size vs. adaptive based on network speed
   - **Recommendation**: Fixed 5MB chunks for simplicity

2. **Resume Mechanism**
   - **Options**: Store upload state server-side vs. client-side
   - **Recommendation**: Server-side with upload ID for reliability

---

## 6. Risks & Challenges

### Technical Risks
- **Mobile memory limits**: 1GB file may exceed mobile browser memory
  - **Mitigation**: Stream chunks without loading entire file

- **Network instability**: Mobile uploads prone to interruption
  - **Mitigation**: Implement resumable uploads

### Requirement Risks
- **Security underspecified**: Unknown threat model
  - **Resolution**: Clarify authentication and file validation needs

---

## 7. Open Questions

1. **What security measures are required?**
   - Why it matters: Affects authentication, validation, scanning
   - Suggested resolution: Ask about user authentication and file type restrictions

2. **What happens after upload completes?**
   - Why it matters: May need webhooks, notifications, or processing triggers
   - Suggested resolution: Clarify post-upload workflow

3. **What's the expected concurrent upload limit per user?**
   - Why it matters: Affects queue design and resource allocation
   - Suggested resolution: Define reasonable upper bound (e.g., 5 uploads)

---

## 8. Next Steps

1. **Immediate**: Clarify security requirements (authentication, file validation)
2. **Before Implementation**: Decide on chunking and resume strategy
3. **During Implementation**: Test on actual mobile devices early
```

---

## Best Practices

### Do:
- Organize scattered information into clear structure
- Call out ambiguities explicitly with specific questions
- Provide rationale for recommendations
- Identify risks with concrete mitigation strategies
- Use acceptance criteria as implementation checklist

### Don't:
- Make assumptions about unclear requirements (call them out instead)
- Recommend technologies without justification
- Ignore contradictions or conflicts
- Over-engineer solutions beyond stated needs
- Skip risk assessment even for "simple" requirements

---

## Success Criteria

This skill succeeds when:
- Requirements are structured and unambiguous
- All critical gaps and contradictions are identified
- Implementation guidance is actionable
- Risk assessment is realistic and helpful
- The specification enables confident implementation
Comments 0
Latest | Hot
Please login before commenting.
No comments yet. Be the first one!
symbiosis

Directory Structure

SKILL.md

Report

Notice
