| name | requirements-analysis |
| description | Adaptive-depth requirements analysis for AIDLC Inception. Simple features produce a 1-paragraph brief; complex features produce structured REQ-001/REQ-002 functional and non-functional requirements with acceptance criteria and traceability to user stories. |
| argument-hint | [feature slug — e.g., semantic-router, gateway-guardrails] |
| user-invocable | true |
| model | claude-sonnet-4-6 |
| allowed-tools | Read,Write,Edit,Grep,Glob |
언제 사용하나요
workspace-detection 산출물을 바탕으로 요구사항을 정리할 때- 비즈니스 목표와 기술 제약을 Functional / Non-Functional 로 분리해야 할 때
- 기존 기능 확장 시, 변경된 범위의 요구사항만 선별적으로 갱신할 때
언제 사용하지 않나요
- 사용자 대면 플로우 묘사가 주 목적일 때 —
user-stories 스킬 사용
- 구현 상세(API 스펙, DB 스키마) 를 작성할 때 — Phase 2 로 이동
- 단일 버그 수정처럼 요구사항이 자명한 작업
전제 조건
workspace-report.md 존재 또는 범위가 명확한 기능 요청 문장 확보- 목표 슬러그(
<feature-slug>) 가 .omao/plans/ 에 생성됨
- 비기능 요구사항(성능/비용/보안) 에 관여하는 이해관계자 확인
절차
Step 1. 깊이 선택 (Adaptive Depth)
| 기준 | Simple | Structured |
|---|
| 영향 범위 | 단일 컴포넌트 | 2개 이상 컴포넌트 |
| 예상 변경 파일 | 10 미만 | 10 이상 |
| 비기능 제약 | 없음 또는 미미 | 성능/비용/보안 조건 존재 |
| 이해관계자 | 단일 팀 | 다팀 협업 필요 |
결정 결과는 depth: simple | structured 로 기록합니다.
Step 2. Simple Mode — 1-문단 Brief
"무엇을 왜 바꾸며, 성공 판단 기준은 무엇인지" 를 58 문장으로 서술합니다.
사용자 시나리오, 핵심 제약 12개, 검증 지표(예: "응답 지연 < 200ms") 를 포함합니다.
Step 3. Structured Mode — REQ-ID 포맷
# Requirements — semantic-router
## Functional Requirements
- **REQ-001**: 라우터는 프롬프트 임베딩 유사도 기반으로 모델을 선택합니다.
- Acceptance: 동일 의미 프롬프트 100건에 대해 95% 이상 동일 모델 라우팅
- **REQ-002**: 라우터는 폴백 경로를 제공합니다.
- Acceptance: 주 모델 오류율 5% 초과 시 30초 내 폴백 모델로 전환
## Non-Functional Requirements
- **REQ-NF-001** (성능): p95 라우팅 지연 < 20ms
- **REQ-NF-002** (비용): 1K 요청당 비용 < $0.003
- **REQ-NF-003** (보안): 프롬프트 원문은 디스크에 저장하지 않음
## Traceability
| REQ-ID | User Story | Workflow Step |
|--------|-----------|---------------|
| REQ-001 | US-01 | workflow-step-2 |
| REQ-002 | US-03 | workflow-step-4 |
Step 4. 비기능 요구사항 체크리스트
- 성능: p50/p95/p99 지연, 처리량(QPS), 동시 사용자 수
- 비용: 월간 상한, 요청당 비용, 리전 최적화 여부
- 보안: 인증/인가, 데이터 분류, 전송/저장 암호화, PII 취급
- 관측성: 메트릭/로그/트레이스 스펙, SLO/SLI 정의
- 규제: ISMS-P, SOC2, HIPAA 등 도메인별 요구
Step 5. 검증 기준(Acceptance Criteria)
- 각 REQ-ID 는 검증 가능한 문장을 최소 1개 포함합니다.
- 주관적 표현("빠르게", "쉽게") 을 금지하고 수치 또는 명시적 조건으로 기술합니다.
Step 6. 산출물 저장
.omao/plans/<slug>/requirements.md 저장- frontmatter:
created, last_update.date, tags: [aidlc, inception, requirements]
- 워크스페이스 리포트 링크 포함
Step 7. 옵트인 확장 평가
agentic-platform.opt-in.md — Agentic AI 도메인이면 필수 검증 활성korean-docs-style.opt-in.md — 산출물 문서 스타일 강제
좋은 예시
- Simple: "Inference Gateway 로그 필드에
tenant_id 를 추가합니다. 목적은 테넌트별 과금 분석이며 100% 의 요청 로그에 필드가 포함되어야 합니다."
- Structured: REQ-001 ~ REQ-005 + 비기능 3개 + Traceability 표
나쁜 예시 (금지)
- "성능을 개선한다" — 수치가 없어 검증 불가
- 기능/비기능 혼재 — 독립 섹션 필수
- Acceptance Criteria 누락 — 다운스트림 테스트 설계 불가
- 이해관계자 언급 없이 보안/규제 요구 생략
참고 자료
공식 문서
관련 문서 (내부)
../workspace-detection/SKILL.md — 선행 스킬../user-stories/SKILL.md — 후행 스킬(조건부)../workflow-planning/SKILL.md — 실행 단위 설계../../aidlc-rule-details/extensions/agentic-platform.opt-in.md — Agentic 도메인 확장/home/ubuntu/workspace/oh-my-aidlcops/CLAUDE.md — OMA 전체 철학
