Requirements Analysis

언제 사용하나요

• workspace-detection 산출물을 바탕으로 요구사항을 정리할 때
• 비즈니스 목표와 기술 제약을 Functional / Non-Functional 로 분리해야 할 때
• 기존 기능 확장 시, 변경된 범위의 요구사항만 선별적으로 갱신할 때

언제 사용하지 않나요

• 사용자 대면 플로우 묘사가 주 목적일 때 — user-stories 스킬 사용
• 구현 상세(API 스펙, DB 스키마) 를 작성할 때 — Phase 2 로 이동
• 단일 버그 수정처럼 요구사항이 자명한 작업

전제 조건

• workspace-report.md 존재 또는 범위가 명확한 기능 요청 문장 확보
• 목표 슬러그(<feature-slug>) 가 .omao/plans/ 에 생성됨
• 비기능 요구사항(성능/비용/보안) 에 관여하는 이해관계자 확인

절차

Step 1. 깊이 선택 (Adaptive Depth)

결정 결과는 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 누락 — 다운스트림 테스트 설계 불가
• 이해관계자 언급 없이 보안/규제 요구 생략

참고 자료

공식 문서

• awslabs/aidlc-workflows — requirements-analysis — 원본 요구사항 분석 규칙
• Software Requirements Specification (SRS) 개요 — 요구사항 명세 일반 개념 (IEEE 830 / ISO·IEC·IEEE 29148 계보)

관련 문서 (내부)

• ../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 전체 철학