| name | aidlc-requirements-analysis |
| description | Use when user requirements need to be analyzed, structured into a requirements document, or when open questions from a previous analysis need resolution. |
| metadata | {"version":"0.6.0","author":"Jay","category":"ai-dlc-workflow","invoke_mode":"orchestrator-only","return_behavior":"stop-no-gate","output_path":"devflow-docs/inception/requirements.md","skill_nature":"amplification","lifecycle":"active"} |
aidlc-requirements-analysis
Purpose
Analyze and document requirements at a depth appropriate to the request's complexity.
Execution Modes
Normal Mode (기본)
일반 호출. Step 1부터 순서대로 실행.
QUESTIONS Mode
호출 텍스트에 QUESTIONS 키워드 포함 시 활성화:
"aidlc-requirements-analysis: QUESTIONS — 기존 분석 유지, 미해결 질문만 처리"
QUESTIONS 모드에서는:
devflow-docs/inception/requirements.md 읽기## Open Questions 섹션의 미해결 질문만 one-at-a-time으로 처리- 답변을
## Assumptions 또는 해당 요구사항 섹션에 반영
requirements.md 업데이트 후 STOP
Step 1, 2, 3, 4는 실행하지 않는다.
QUESTIONS 모드 반환값
미해결 질문이 남아있으면 열린 질문: [N]개 패턴을 포함하여 반환. 모두 해결되면 열린 질문: 0개.
UPDATE 모드
호출 텍스트에 UPDATE 키워드 포함 시 활성화:
"aidlc-requirements-analysis: UPDATE — 기존 분석 유지, [변경 내용] 반영"
UPDATE 모드에서는:
devflow-docs/inception/requirements.md 읽기 (기존 분석)- 변경 요청과 기존 요구사항을 대조하여 연관성 판단:
- 연관 요구사항 있음 (동일 기능/영역) → 해당 항목을 기반으로 수정/확장 (우선순위 변경, 기준 보강 등). Edit 도구로 해당 섹션만 교체
- 연관 요구사항 없음 (새로운 기능) → 신규 항목으로 기존 목록에 추가. Edit 도구로 삽입
- 요구사항 삭제 → 해당 항목 삭제 + 연쇄 영향 확인 (Assumptions, Open Questions에서 관련 항목 제거/갱신)
- 변경이 다른 섹션에 영향을 주는지 확인:
- Assumptions: 변경으로 무효화된 가정이 있으면 제거 또는 갱신
- Open Questions: 변경에서 새 질문이 발생하면 추가
- Technology Stack, Non-Functional Requirements: 영향이 있으면 갱신
## Change Log 섹션에 변경 내역 기록: - [ISO 8601] UPDATE: [변경 요약]requirements.md 업데이트 후 STOP
도구 선택: 부분 업데이트에는 반드시 Edit 도구를 사용한다. Write 도구로 전체 덮어쓰기 금지.
Step 1, 2, 3, 4, 5는 실행하지 않는다.
UPDATE 범위 제한: User Intent 자체를 변경하는 요청은 UPDATE 대상이 아니다. "방향을 바꾸고 싶다"는 요청에는 "전체 재분석이 필요합니다"라고 안내하고 일반 모드로 재호출을 유도한다.
Execute
Step 1: Load complexity
호출 텍스트에서 complexity 확인 (Primary):
호출 텍스트에 Complexity: [level] 패턴이 있으면 그 값을 사용:
- "aidlc-requirements-analysis 실행. Complexity: Standard" → Standard 사용
- "[Complexity: Standard] 오케스트레이터에서 확정된 복잡도로 분석합니다." 표시
devflow-state에서 확인 (Fallback):
호출 텍스트에 complexity 정보가 없으면 devflow-docs/devflow-state.md의 ## Complexity 필드를 읽는다.
해당 필드도 없으면 기존 기준으로 자체 판단:
Choose Minimal if ALL of:
- Single, clearly defined feature
- No ambiguity in requirements
- No cross-component dependencies
- Low risk (reversible, isolated)
Choose Comprehensive if ANY of:
- Multiple components or services affected
- High risk or irreversible changes
- Ambiguous requirements
- External integrations involved
- Performance or security critical
Otherwise: Standard
Step 2: Interpretation check (Minimal 제외)
Skip this step entirely if depth is Minimal.
For Standard and Comprehensive, ask: "이 요청에 동등하게 유효한 해석이 2가지 이상 존재하는가?"
판단 기준 — 해석이 분기되는 신호:
- 요청 키워드가 여러 구현 방식을 가리킴 (예: "검색", "알림", "인증")
- 기술 선택이 요구사항 자체를 바꿀 수 있음 (예: 실시간 vs 배치)
- 사용자가 최종 사용자 유형이나 사용 맥락을 명시하지 않음
해석이 분기되지 않으면: Step 3으로 바로 진행.
해석이 분기되면: 2-3가지 해석을 제시하고 사용자의 확인을 받은 후 Step 3으로 진행.
이 요청은 다음 중 어떤 방향인가요?
A) [해석 1] — [한 줄 설명]
B) [해석 2] — [한 줄 설명]
C) [해석 3] — [한 줄 설명, 있는 경우]
직접 설명하셔도 됩니다.
선택된 해석을 requirements.md의 ## User Intent에 반영한다.
session-summary 중간 기록: 해석 확정 후 session-summary.md의 ## Completed Work에 [~] requirements-analysis — 해석 확정([선택]안) 업데이트 + ## For Next Session에 미결 질문 목록 기록.
Ambiguity Resolution Loop (Standard / Comprehensive)
해석 선택 후, 다음 모호성 신호를 탐지한다:
- "~하거나", "둘 다", "상황에 따라", "아직 모르겠어", "적당히"
- 설계 결정을 내리기에 불충분한 답변 (조건부 표현, 수치 없는 모호한 표현)
신호 감지 시: 후속 질문 ONE at a time:
[이전 답변]을 더 구체화해야 합니다.
A와 B 중에서 상충할 때 어느 쪽을 우선하시겠어요?
모호성이 해소될 때까지 반복.
사용자가 "그냥 진행해" 또는 "계속해" 요청 시:
- 해소되지 않은 항목을 가정으로 확정
- requirements.md의
## Assumptions에 기록
- 반환 텍스트에 "가정으로 처리된 항목: [N]개 — [목록]" 포함
- STOP (승인 대기 없음 — 오케스트레이터 gate에서 표시)
Step 2b: Tech Stack Selection (조건부)
Minimal depth에서도 실행한다. 기술 스택은 이후 모든 단계의 전제 조건이므로.
2b-1: 스킵 판단 (카탈로그 Read 없이)
다음 3가지 소스를 순서대로 확인한다:
| 우선순위 | 소스 | 확인 방법 |
|---|
| 1 | CLAUDE.md 사전 지정 | workspace.md의 ## Pre-specified Tech Stack 섹션 존재 여부. 있으면 해당 항목은 확정 |
| 2 | Brownfield 감지 | workspace.md의 ## Technology Stack (Brownfield) 섹션. Language, Framework, DB 등이 감지되었으면 해당 항목은 확정 |
| 3 | 사용자 프리셋 | tech-stack-defaults.md의 ## 사용자 프리셋 섹션 확인 |
스킵 판단 결과:
- 전체 스킵: 소스 1 또는 2에서 Language + Framework + DB + Testing이 모두 확정됨 →
[기술 스택: 사전 지정 — 질문 스킵] 기록, Step 3으로
- 부분 스킵: 일부만 확정 → 미확정 계층만 2b-2로
- 스킵 불가: Greenfield + CLAUDE.md 미지정 → 모든 계층 2b-2로
2b-2: 카탈로그 선택 (필요할 때만 Read)
미커버 계층에 대해 순서대로 처리:
1. 프리셋 확인: tech-stack-defaults.md에 해당 계층의 프리셋이 있으면:
[계층] 기술 스택에 프리셋이 있습니다:
→ [프리셋 기술 조합]
이대로 사용하시겠습니까? (Y/n)
- Y → 프리셋 수용, 다음 계층으로 (카탈로그 Read 불필요)
- n → 카탈로그에서 선택 (아래)
2. 카탈로그 선택: tech-stack-catalog.md의 해당 계층 섹션을 Read
tech-stack-catalog.md가 없으면 카탈로그 선택을 스킵하고, 해당 계층을 자유 입력으로 질문한다.- 선택지 2~5개 구성, 첫 번째 옵션에
(권장) 표시 (question-format-guide.md 원칙)
- "직접 입력" 포함 여부는
tech-stack-defaults.md의 정책 모드에 따름:
- open:
X) 직접 입력 포함
- guided:
X) 직접 입력 (사유 필수) — 선택 시 사유 질문 → requirements.md에 기록
- strict: 직접 입력 미포함
결과 기록: requirements.md의 ## Technology Stack 섹션에:
## Technology Stack
| 계층 | 선택 | 소스 | 비고 |
|------|------|------|------|
| [계층명] | [기술명] | [CLAUDE.md | Brownfield 감지 | 프리셋 | 카탈로그 선택 | 직접 입력] | [비고] |
guided 모드에서 카탈로그 외 기술 선택 시 ## 기술 스택 결정 섹션에 사유 테이블 추가.
Step 3: Execute at chosen depth
Minimal
- Document user's intent in one paragraph
- List 3-5 key acceptance criteria
- Note any assumptions made
Standard
- Analyze user intent (Step 2에서 확정된 해석 기반)
- List functional requirements (what the system must do)
- List non-functional requirements (performance, security, etc.)
- Identify constraints and assumptions
- Note open questions (if any)
- 핵심 질문 (최대 2개, one at a time): 요구사항에서 설계 방향을 바꿀 수 있는 불확실성이 있으면 질문. 없으면 스킵.
- 처리 방식: "실시간 처리가 필요한가요, 배치로 충분한가요?"
- 사용자 유형: "단일 사용자인가요, 다중 사용자인가요?"
- 각 답변 후 Ambiguity Resolution Loop 발동 여부 판단.
- session-summary 중간 기록: 각 핵심 질문 답변 후
[~] requirements-analysis — 질문 N/M 완료 업데이트.
Comprehensive
- Full intent analysis (Step 2에서 확정된 해석 기반)
- Detailed functional requirements with priority (Must/Should/Could)
- Non-functional requirements with measurable criteria
- Risk assessment (High/Medium/Low per requirement)
- Dependencies and constraints
- Open questions — ask user ONE at a time before proceeding
Depth별 질문 정책
| Depth | 해석 분기 | 핵심 질문 | Ambiguity Loop |
|---|
| Minimal | 없음 | 없음 | 없음 |
| Standard | 있음 | 최대 2개 (each → loop) | 있음 |
| Comprehensive | 있음 | 제한 없음 (each → loop) | 있음 |
Step 4: Ask clarifying questions (Comprehensive only)
열린 질문이 있는 경우, 질문을 시작하기 전에 맥락을 먼저 선언한다:
요구사항을 확정하기 전에 몇 가지 질문을 드리겠습니다.
[질문 수]개의 열린 질문이 있습니다.
그 후 ONE question at a time. Wait for answer before asking next.
Step 5: Save artifact
Create devflow-docs/inception/requirements.md:
# Requirements Analysis
**Depth**: [Minimal | Standard | Comprehensive]
**Timestamp**: [ISO 8601]
## User Intent
[What the user wants to achieve — Step 2에서 확정된 해석 포함]
## Functional Requirements
[List of requirements]
## Non-Functional Requirements
[Performance, security, etc.]
## Technology Stack
| 계층 | 선택 | 소스 | 비고 |
|------|------|------|------|
[Step 2b 결과]
## Assumptions
[List of assumptions made]
## Open Questions
[Any unresolved questions]
Review
conventions Review Workflow 적용.
- 산출물: devflow-docs/inception/requirements.md
- 리뷰어: artifact-reviewer-prompt.md
Return to Orchestrator
conventions 표준 형식. 반환 필드:
- 분석 깊이: [Minimal | Standard | Comprehensive]
- 해석 확정: [확정된 해석 한 줄 요약, 또는 "단일 해석 — 확인 불필요"]
- 기능 요구사항: [count]개
- 기술 스택: [사전 지정 (질문 스킵) | 프리셋 N개 + 선택 M개 | 전체 선택 N개]
- 열린 질문: [count]개
- 가정으로 처리된 항목: [0개 | N개 — 항목명 목록]
- 산출물: devflow-docs/inception/requirements.md
- 리뷰: [✅ 승인됨 | ⏭ 스킵 (Minimal)]
Common Issues
User provides no requirements context
요청이 너무 모호하면:
- Comprehensive depth 기본 적용
- Step 2에서 가능한 해석 제시
Step 2에서 해석이 3가지 이상으로 늘어날 때
- 가장 가능성 높은 2-3가지로 압축
- 나머지는 "기타: 다른 방향이라면 직접 설명해주세요"로 열어두기
Step 2b: tech-stack-defaults.md에 정책 모드가 없을 때
- 기본값: open (직접 입력 자유 허용)
- tech-stack-defaults.md 파일 자체가 없으면 Step 2b 전체를 스킵하고, 사용자에게 기술 스택을 자유 입력으로 질문
