| name | si-planning |
| description | SI 프로젝트 요구사항 공학 스킬. 소크라테스식 요구사항 수집 → 도메인별 체크리스트 검증 → 산출물 자동 생성(요구사항분석서/기능정의서/화면정의서/추적표) → 변경 영향 분석. 대시보드 연동으로 고객 공유 지원. |
| triggers | ["/si-planning","요구사항 분석","기능정의서","화면정의서","SI 기획","요구사항 수집","SI 산출물"] |
| version | 1.0.0 |
| updated | "2026-03-29T00:00:00.000Z" |
SI Planning — 요구사항 공학 엔진
목표: SI 프로젝트의 요구사항을 빠짐없이 수집하고, 도메인별 검증을 거쳐, 표준 산출물을 자동 생성한다.
철학: 요구사항은 "물어서 얻는 것"이 아니라 "함께 발견하는 것". 고객의 암묵지를 구조화된 명세로 변환한다.
커맨드
/si-planning # 전체 워크플로우 (Phase 0-4)
/si-planning --domain=공공 # 도메인 지정 시작
/si-planning --add # 요구사항 추가
/si-planning --change RD-FR-003 # 요구사항 변경 + 영향 분석
/si-planning --gap # Gap Detection만 재실행
/si-planning --dashboard # 대시보드 서버 시작
/si-planning --dashboard --port=3030 # 포트 지정
절대 금지
- 기술 구현 세부사항 질문 (아키텍처, 라이브러리 선택 — Claude 영역)
- 요구사항 임의 생성 (반드시 사용자 확인 필요)
- 도메인 체크리스트 우회 (필수 항목 skip 불가)
- Ambiguity Score 0.3 이상에서 Phase 2 진입
산출물 경로
- 프로젝트 레벨:
docs/si/
- 상태 데이터:
docs/si/si-state.json
Phase 0: 도메인 프로파일 로드
DOMAIN={공공|금융|의료|제조|유통|커스텀}
도메인 선택 시 자동 로드:
- 필수 NFR 체크리스트
- 규정/법규 요건
- 흔히 누락되는 요구사항 목록
- 도메인 전용 질문 세트
상세: references/domain-profiles.md
Phase 1: 요구사항 수집 (소크라테스식 + SI 강화)
Ambiguity Score가 0.3 이하가 될 때까지, Phase 2로 넘어가지 않는다.
Step 1: 프로젝트 개요
AskUserQuestion으로 수집:
- 프로젝트명, 목적, 범위
- 발주처/이해관계자
- 일정, 예산, 인력 제약
Step 2: As-Is 워크스루
"현재 이 업무를 어떻게 처리하고 있나요?"
"아침에 출근하면 이 업무와 관련해서 첫 번째로 하는 일은?"
"그 과정에서 가장 불편한 점 3가지는?"
"지금 쓰고 있는 시스템/도구는?"
Step 3: To-Be 도출
"이 시스템이 완성되면, 아까 말한 불편함이 어떻게 해결되나요?"
"가장 먼저 바뀌어야 할 것 3가지는?"
"이 시스템 없이는 절대 안 되는 기능은?"
Step 4: 기능 요구사항 도출 (FR)
# 정방향: 기능 직접 도출
"핵심 기능을 업무 흐름 순서대로 말해주세요"
# 역방향: Anti-requirements
"절대 일어나면 안 되는 상황은?"
"이전 시스템에서 가장 큰 사고가 뭐였나요?"
# 숨은 요구사항
"이 데이터를 누가 또 보나요?" (숨은 이해관계자)
"이 기능이 장애가 나면 어떤 일이 벌어지나요?" (장애 영향도)
"데이터가 틀리면 누가 책임지나요?" (데이터 거버넌스)
Step 5: 비기능 요구사항 (NFR) — ISO 25010 가이드
# 도메인 프로파일에서 필수 NFR 로드 후 확인
"동시 접속자는 최대 몇 명 정도?" → 성능효율성
"장애 시 허용 가능한 중단 시간은?" → 신뢰성
"법적/규정적으로 꼭 지켜야 하는 것은?" → 보안성/호환성
"기존 시스템과 연동해야 할 것은?" → 상호운용성
Step 6: 유사 시스템 레퍼런스
"비슷한 시스템을 써본 적 있으면, 그것과 비교하면?"
"그 시스템에서 좋았던 점/나빴던 점은?"
Step 7: 숨은 이해관계자 탐색
"이 시스템의 결과물을 보고받는 상위 관리자는?"
"이 시스템에 데이터를 넣는 사람과 쓰는 사람이 다른가요?"
"외부 기관과 데이터를 주고받나요?"
Gray Area → CONTEXT.md 연동 (GSD 패턴)
Phase 1 수집 중 Gray area(명확한 답이 없는 결정 사항) 발견 시:
/discuss 스킬 호출하여 결정 수집- 결정 결과를
.claude/CONTEXT.md에 기록
- Phase 3 서브에이전트가 CONTEXT.md를 참조하여 산출물 생성
Gray Area 발견 시:
"이 부분은 여러 방법이 있는데, 어떻게 할지 결정이 필요합니다"
→ /discuss 호출 → CONTEXT.md 생성
→ Phase 3 서브에이전트에 CONTEXT.md 경로 전달
Gray area 예시:
- 권한 체계: 역할 기반(RBAC) vs 속성 기반(ABAC)
- 데이터 보존: 물리 삭제 vs 논리 삭제
- 알림 방식: 이메일 vs SMS vs 앱 푸시
- 결재선: 고정 vs 동적 결재선
Ambiguity Score 측정
6가지 명확성 차원 평가 (각 0.0~1.0, 낮을수록 명확):
| 차원 | 측정 기준 |
|---|
| 문제 정의 | As-Is/To-Be 명확성 |
| 대상 사용자 | 이해관계자 식별 완료도 |
| 핵심 기능 | 기능 목록의 구체성 |
| 비기능 요건 | NFR 정량화 여부 |
| 범위 경계 | 포함/불포함 명확성 |
| 성공 기준 | 검수 조건 정의 여부 |
Score = 6개 차원 평균. 0.3 이하면 Phase 2 진입.
상세 질문 체계: references/question-framework.md
Phase 2: 분석 + Gap Detection
Step 1: ID 체계화
# 기능 요구사항
RD-FR-001 ~ RD-FR-NNN
# 비기능 요구사항
RD-NFR-001 ~ RD-NFR-NNN
# 기능 정의
FN-001 ~ FN-NNN
# 화면 정의
SC-001 ~ SC-NNN
# 테스트 케이스 (향후)
TC-001 ~ TC-NNN
Step 2: MoSCoW 우선순위 분류
각 요구사항에 AskUserQuestion으로 우선순위 확인:
- Must: 없으면 시스템 무의미
- Should: 중요하지만 우회 가능
- Could: 있으면 좋지만 없어도 됨
- Won't: 이번 범위에서 제외 (명시적 기록)
Step 3: 기능→화면 매핑
각 FR에 대해:
- 이 기능이 표시/실행되는 화면은?
- 화면 간 이동 경로는?
- 하나의 기능이 여러 화면에 걸치는 경우?
Step 4: 도메인 체크리스트 대조
[Gap Detection 실행]
❌ RD-FR-012 (권한관리) → 기능정의 없음
❌ SC-005 (에러화면) → 요구사항 역추적 불가
⚠️ 공공 도메인 필수: '감사로그' 관련 요구사항 0건
⚠️ 비기능 '백업/복구' 요구사항 미정의
⚠️ 숨은 이해관계자 '감사부서'에 대한 요구사항 없음
Gap 발견 시 사용자에게 보고 → 추가 수집 또는 "의도적 제외" 확인
Step 5-6: 충돌 식별 + 종속성 분석
- 이해관계자 간 요구 충돌 탐지
- 기능 간 종속성 그래프 생성
상세: references/gap-detection.md
Phase 3: 산출물 생성
서브에이전트에 위임하여 메인 컨텍스트 보호:
Agent(
subagent_type="builder",
name="si-docs-generator",
prompt="""
수집된 요구사항 정보를 기반으로 docs/si/ 폴더에 4개 산출물 + 1개 상태 파일 생성:
1. docs/si/requirements-analysis.md — 요구사항분석서
2. docs/si/functional-spec.md — 기능정의서
3. docs/si/screen-spec.md — 화면정의서
4. docs/si/traceability-matrix.md — 요구사항추적표
5. docs/si/si-state.json — 대시보드 상태 데이터
[수집된 정보 JSON 전달]
[.claude/CONTEXT.md 경로가 있으면 함께 전달]
각 문서는 templates/ 폴더의 템플릿을 따릅니다.
mkdir -p docs/si 먼저 실행하세요.
"""
)
Deviation Rules 적용 (GSD 패턴)
산출물 생성 중 발견한 누락/오류를 자동 처리하는 규칙.
Rule 1: Auto-fix Gaps
상황: 산출물 생성 중 RTM 매핑 누락 발견
동작:
- 누락된 매핑 자동 추가
- 관련 산출물 업데이트
[Rule 1 - Gap Fix] {설명} 로 추적
Rule 2: Auto-add Missing Critical
상황: 도메인 체크리스트 필수 항목이 요구사항에 없음
동작:
- 해당 NFR을 RD-NFR-NNN으로 자동 추가 (Draft 상태)
- 산출물에 반영
[Rule 2 - Critical Add] {설명} 로 추적- Phase 4에서 사용자 확인 필수
Rule 3: Auto-fix Consistency
상황: 산출물 간 ID 불일치 (예: 기능정의서에 FN-015가 있는데 추적표에 없음)
동작:
- 불일치 자동 수정
[Rule 3 - Consistency Fix] {설명} 로 추적
Deviation 기록
모든 deviation은 si-state.json의 gaps 배열에 기록:
{
"id": "DEV-001",
"rule": "Rule 2",
"type": "Critical Add",
"description": "공공 도메인 필수: 감사로그 NFR 자동 추가",
"target": "RD-NFR-014",
"status": "draft"
}
사용자 확인 필요한 경우
- Rule 2로 추가된 요구사항 (Draft → Confirmed 전환 필요)
- 3개 이상 산출물에 영향을 미치는 deviation
산출물 완료 확인
Glob("docs/si/*.md")
Read("docs/si/si-state.json")
Phase 4: 검증 + 핸드오프
Step 1: Goal-backward 검증 + 추적성 (GSD 패턴)
핵심 원칙: 산출물 완성 ≠ 요구사항 충족. 목표에서 역산하여 검증한다.
Goal-backward 검증 흐름:
프로젝트 목표 (Goal)
↓
Must-have: 이 목표를 달성하려면 반드시 필요한 요구사항은?
↓
Must-exist: 각 요구사항이 기능정의서에 존재하는가?
↓
Must-wired: 각 기능이 화면에 연결되어 있는가?
↓
실제 산출물 교차 검증
실행:
grep -c "RD-FR" docs/si/requirements-analysis.md
grep -c "FN-" docs/si/functional-spec.md
grep -c "SC-" docs/si/screen-spec.md
추적성 검증 결과:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GOAL-BACKWARD VERIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Goal → Must-have (요구사항): 45건 확인
Must-have → Must-exist (기능): 30/32 (93.8%) ⚠️
Must-exist → Must-wired (화면): 28/30 (93.3%) ⚠️
도메인 체크: 12/15 (80.0%) ❌
미매핑 항목:
- RD-FR-031 → FN 없음
- RD-FR-032 → FN 없음
- FN-029 → SC 없음
- FN-030 → SC 없음
Deviation 적용: 2건 (Rule 2: 1건, Rule 3: 1건)
Gap 발견 시 /quality-auditor의 goal-backward 패턴으로 추가 검증:
- PASS → Phase 4 Step 2 진행
- FAIL → Gap 해결 작업 생성 → Phase 2로 회귀
Step 2: 실패 기획 4요건 검사
vibelab 패턴 적용:
- 자기 집착: 유사 시스템 비교 없이 진행? → 경고
- 추측 기반 결정: 증거 없는 요구사항? → 태깅
- 합리적 타협: 핵심 가치 희석? → 검증
- 시도 회피: 과도한 분석 루프? → 다음 단계 유도
Step 3: 사용자 최종 확인
Step 4: 핸드오프
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
/si-planning COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
요구사항: 45건 (FR: 32, NFR: 13)
추적성: 85%
도메인 체크: 12/15 통과
Ambiguity Score: 0.18
생성된 산출물:
- docs/si/requirements-analysis.md
- docs/si/functional-spec.md
- docs/si/screen-spec.md
- docs/si/traceability-matrix.md
대시보드: /si-planning --dashboard
다음 단계:
- /agile auto (소규모)
- /team-orchestrate (대규모)
- /si-planning --dashboard (고객 공유)
변경 관리 모드
--change: 기존 요구사항 변경
/si-planning --change RD-FR-003
→ 영향 분석:
기능: FN-001, FN-012
화면: SC-001, SC-007
테스트: TC-001, TC-002, TC-015
예상 공수 변동: +2일
→ [승인] 산출물 자동 업데이트
→ [보류] CR-NNN으로 기록만
--add: 새 요구사항 추가
/si-planning --add
→ Phase 1 질문 재사용 (신규 요구사항만)
→ 기존 ID 체계에 추가
→ Gap Detection 재실행
→ 산출물 업데이트
상세: references/change-management.md
스킬 연계
| 상황 | 연결 스킬 |
|---|
| 요구사항 수집 전 브레인스토밍 | /neurion |
| Gray area 결정 수집 | /discuss |
| Phase 1 gray area 발견 | /discuss → CONTEXT.md |
| 산출물 완성 후 구현 | /agile auto 또는 /team-orchestrate |
| Phase 3 산출물 생성 중 누락 | Deviation Rules 자동 적용 |
| 산출물 검증 | /quality-auditor |
| Phase 4 목표 검증 | /quality-auditor goal-backward |
| 고객 공유 | /si-planning --dashboard |
| 변경 영향 분석 | /si-planning --change |
Last Updated: 2026-03-29 (v1.0.0 — 초기 버전)
