기능 요구사항 제안 스킬
목적
EARS 표기법을 사용하여 기능에 대한 공식 요구사항 명세를 작성합니다. 이는 개념을 테스트 가능하고 구체적인 요구사항으로 변환합니다.
사용 시기
- 기능 개념이 존재하고 승인된 경우
- 시스템이 정확히 무엇을 해야 하는지 명세해야 하는 경우
- 기능적 및 비기능적 요구사항을 정의할 준비가 된 경우
전제 조건
- 기능 개념 문서가
docs/features/NNNN-feature-name/concept.md에 존재 - 개념이 검토 및 승인됨
- 사용자가 기능 범위를 이해하고 있음
절차
1. 개념 문서 확인
# 개념 문서가 존재하는지 확인
ls ./docs/features/NNNN-feature-name/concept.md
존재하지 않는 경우, 먼저 propose-feature-concept 스킬을 사용하세요.
2. 아이디어 다듬기 문서 확인
ls ./planning/NNNN-feature-name/idea-honing.md 2>/dev/null
존재하는 경우, 요구사항에 도움이 되는 인사이트를 위해 검토하세요. Q&A는 엣지 케이스와 제약 조건을 드러낼 수 있습니다.
3. 요구사항 템플릿 복사
cp ./docs/features/0000-templates/requirements.md ./docs/features/NNNN-feature-name/
4. 요구사항 접두사 결정
요구사항 ID에 사용할 짧은 접두사(2-5자)를 선택하세요:
- 기능을 설명할 수 있어야 함
- 예:
SEM(semantic-search),REG(registry-management) SEM-1,SEM-2등으로 사용됨
5. 개요 작성
이 명세가 다루는 내용을 간략히 설명하세요. 개념 문서를 참조하세요.
6. 기능적 요구사항 정의
각 요구사항에 대해 EARS 형식을 사용하세요:
**WHILE** [상태 또는 조건]
**WHEN** [트리거 또는 이벤트]
**THEN** 시스템은 **SHALL** [필요한 동작]
정말 작은 경우(1-3줄)에만 인라인 예제를 추가하세요:
key = "value"
더 큰 예제는 부록에 추가하세요.
7. 비기능적 요구사항 정의
성능, 사용성, 보안 또는 기타 품질 요구사항을 추가하세요:
**WHILE** [운영 조건]
**THEN** 시스템은 **SHALL** [성능 요구사항]
확장성 질문 (각 주요 작업에 대해 질문하세요):
- 항목이 1000배 더 많아지면 어떻게 되나요? 100만 개 파일? 1000만 개 행?
- 메모리 사용량이 데이터 크기에 따라 확장되어야 하나요, 아니면 일정하게 유지되어야 하나요?
- 허용 가능한 지연 시간은 얼마인가요? 규모에 따라 성능이 저하되나요?
이 질문들은 설계 단계에서 중요 제약 조건이 될 제약 사항을 표면화합니다. 작업이 반드시 O(1) 메모리 또는 O(log n) 시간이어야 하는 경우 여기에 명시하세요.
8. 오류 처리 정의
오류가 처리되어야 하는 방식을 명세하세요:
**WHILE** [진행 중인 작업]
**WHERE** [오류 조건 발생]
**THEN** 시스템은 **SHALL** [오류 처리 동작]
9. 부록 추가
요구사항을 복잡하게 만드는 큰 예제를 위해:
- API 응답 스키마
- 설정 파일 형식
- 데이터 구조
- 프로토콜 명세
각 부록은 명확하게 레이블을 지정하세요:
## 부록 A: API 응답 스키마
## 부록 B: 설정 파일 형식
10. 완전성 검토
다음을 확인하세요:
- 모든 요구사항이 EARS 키워드를 사용
- 요구사항이 테스트 가능하고 구체적임
- 인라인 예제가 정말 작음
- 큰 예제는 부록에 있음
- 요구사항에 선택한 접두사가 포함된 고유 ID가 있음
검증
요구사항 문서를 확인하세요:
# 파일 존재 확인
ls ./docs/features/NNNN-feature-name/requirements.md
# 내용 확인
head -50 ./docs/features/NNNN-feature-name/requirements.md
# EARS 키워드 확인
grep -E "WHILE|WHEN|WHERE|THEN|SHALL" ./docs/features/NNNN-feature-name/requirements.md
일반적인 문제
EARS 키워드 누락: 모든 요구사항은 WHILE/WHEN/WHERE/THEN/SHALL을 사용해야 합니다.
너무 모호함: 요구사항은 테스트할 수 있을 만큼 구체적이어야 합니다.
인라인 예제가 너무 큼: 3줄이 넘는 것은 부록으로 이동하세요.
일관되지 않은 접두사: 모든 요구사항 ID는 동일한 접두사를 사용해야 합니다.
다음 단계
요구사항 생성 후:
- 완전성과 테스트 가능성 검토
- 구현자로부터 피드백 받기
- 요구사항이 확정되면
propose-feature-design스킬을 사용하여 설계로 이동