Record that the first strategy (orb-v1) queries view=buyable without a strategy_key, so missing PortfolioItem strategy fields are harmless for the single-strategy stage. Documentation-only; REQ-029 stays Implemented. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
13 KiB
13 KiB
Software Requirement Specification Index
목적
- 이 문서는 프로젝트의 SRS 운영 기준과 requirement 목록을 관리하는 entry point이다.
- 개별 requirement의 상세 내용은 타입별 폴더 하위
req-XXX_*.md파일에서 관리한다.
사용 방법
- 새로운 requirement가 필요하면
Next Requirement ID를 확인하고docs/srs/req-template.md를 복사해docs/srs/<Type>/req-XXX_<slug>.md파일을 생성한다. - 초안 작성은
draft-req, 승인 전환은confirm-req, 변경 대응은change-req, 구현 완료 전환은confirm-req-implementedskill을 기준으로 수행한다. - 작성 또는 수정 후 누락과 모호성을 점검한다.
- requirement 추가 또는 변경 후
Next Requirement ID,Requirement Register,Recent Change Log Summary를 함께 갱신한다. Proposedrequirement를 승인하려면 승인 준비 상태와 blocker를 점검한다.Approvedrequirement는 구현 이슈나 작업 항목으로 연결한다.- 구현과 검증이 끝난 requirement는
confirm-req-implementedskill로 완료 전환 가능 여부를 점검한다. - requirement 변경 시
change-reqskill을 기준으로 해당 REQ 파일의Change Log를 먼저 갱신한 뒤 본문을 수정한다. - 구현 전에는 관련 REQ 파일과 최근
Change Log를 기준으로 변경 범위를 판단한다.
상태 정의
- Proposed: 초안 상태이며 구현 기준으로 확정되지 않음
- Approved: 구현 기준으로 승인됨
- Implemented: 구현과 검증이 완료됨
- Deprecated: 더 이상 유지하지 않음
Status Transition Evidence
Proposed -> Approved
Status,Type,Priority,Owner,Intent,Requirement,Acceptance Criteria,Impacted Area,Change Log가 모두 존재해야 한다.Type은 아래 분류 도표에서 정확하게 하나로 지정되어야 한다.Acceptance Criteria는 구현 판단에 사용할 수 있을 정도로 구체적이어야 한다.- 미해결 assumption 또는 open question이 있으면
Notes에 명시하고, 승인 blocker 여부를 판단해야 한다. - 승인 전환 시 해당 REQ 파일의
Change Log에 status 변경 사유를 기록해야 한다.
Approved -> Implemented
- 각
Acceptance Criteria에 대해 test, manual verification, 또는 구현 결과 중 최소 1개의 evidence가 있어야 한다. - evidence는 requirement 문서 자체 또는 연결된 구현/검증 결과에서 추적 가능해야 한다.
- 미충족
Acceptance Criteria가 있으면Implemented로 전환하지 않는다. - 구현 완료 전환 시 잔여 리스크와 미검증 영역이 있으면
Change Log에 기록해야 한다. - 상태 전환은
confirm-req-implementedskill을 기준으로 수행한다.
Requirement Change Handling
- 기존 REQ 본문(
Requirement,Acceptance Criteria,Impacted Area)을 수정하기 전에는 새Change Log항목을 만든다. Change Log에는 최소한Acceptance Criteria Delta,Impacted Area Delta,Delivery Trace Delta,Revalidation Impact,Validation Plan이 포함되어야 한다.- 변경이 기존 구현 또는 verification evidence를 무효화하면
Implementedrequirement는Approved로 되돌린다. - 변경이 승인 전제 자체를 다시 검토하게 만들면
Approved또는Implementedrequirement를Proposed로 되돌릴 수 있다. - 상태 되돌림이 발생하면
Requirement Register와Recent Change Log Summary도 함께 갱신한다.
Requirement 타입 분류 도표
| 타입 | 정의 | 예시 |
|---|---|---|
| Configuration | 설정 옵션, 커스터마이징 포인트 | 설정 파라미터, 환경 변수, 옵션 항목 |
| Data | 데이터 구조, 저장/로드, 파일 형식, 스키마 | 설정 파일 형식, DB 스키마, API 구조 |
| Deployment | 배포 방식, 운영 절차, 배포 환경 | 컨테이너 배포, 스택 관리, 운영 가이드 |
| Documentation | 문서 작성, 가이드, 매뉴얼, 안내서 | 사용자 가이드, API 문서, 튜토리얼 |
| Exception | 오류 처리, 예외 복구, 재시도 전략 | 오류 복구, 검증 실패 처리, 폴백 전략 |
| Installation | 시스템 설치, 환경 구성, 초기화 절차 | Docker 이미지 빌드, DB 마이그레이션, 사전 조건 설정 |
| Integration | 외부 시스템 연동, 플러그인, 확장 | 3rd party 연동, 플러그인 인터페이스 |
| Interface | 사용자 상호작용 방식 (UI, API, CLI, 제어방식) | CLI 명령어, API 엔드포인트, 웹 UI 기능 |
| Migration | 데이터 이전, 버전 업그레이드 | 데이터 마이그레이션, 버전 호환성 |
| Non-Functional | 성능, 보안, 확장성, 호환성, 신뢰성 | 성능 목표, 보안 정책, 확장성 |
| Testing | 테스트 전략, QA 요구사항, 검증 방식 | 테스트 커버리지, 회귀 테스트, 수락 기준 |
Requirement 작성 규칙
- 각 requirement는 고유 ID를 가진다. 예:
REQ-001 - 다음 신규 requirement 번호의 source of truth는 이 문서의
Next Requirement ID섹션이다. - 새 requirement를 추가하거나 ID 충돌이 발생할 수 있는 변경을 했으면
Next Requirement ID를 함께 갱신한다. - 각 requirement는
Type을 명시해야 한다. 위 분류 도표 중 정확하게 하나로 선택하며,docs/srs/<Type>/폴더명도 같은 문자열을 사용한다. - 각 requirement는
Intent,Requirement,Acceptance Criteria,Impacted Area를 반드시 포함한다. - 모호한 표현("개선한다", "적절히 처리한다") 대신 관찰 가능하고 test 가능한 문장을 사용한다.
- requirement 변경 사항은 해당 REQ 파일의
Change Log에 기록한다. - requirement 변경 시 영향 받는 batch/release와 재검증 필요 여부를
Change Log에 남긴다. Recent Change Log Summary는 최신 5건만 유지한다.- status 전환은
Status Transition Evidence기준을 따른다.
Next Requirement ID
- Current:
REQ-034 - Rule:
Requirement Register에 있는 가장 큰 REQ 번호보다 정확히 1 커야 한다.
Requirement Register
| ID | Title | Type | Status | Priority | Owner | Link |
|---|---|---|---|---|---|---|
| REQ-001 | trex-core Python 프로젝트 부트스트랩 | Installation | Implemented | High | project maintainers | req-001 |
| REQ-002 | slot 순수 도메인 이식 및 공개 API 확정 | Interface | Implemented | High | project maintainers | req-002 |
| REQ-003 | slot 도메인 단위테스트 이식 및 컬럼 계약 가드 | Testing | Implemented | High | project maintainers | req-003 |
| REQ-004 | baseline 문서 planned→실제 정합 | Documentation | Implemented | Medium | project maintainers | req-004 |
| REQ-005 | 슬롯 코어 데몬 런타임 부트스트랩 | Installation | Implemented | High | project maintainers | req-005 |
| REQ-006 | PostgreSQL SlotRepository 영속화 + 스키마 | Data | Implemented | High | project maintainers | req-006 |
| REQ-007 | intent 제출 HTTP API + 멱등 | Interface | Implemented | High | project maintainers | req-007 |
| REQ-008 | 슬롯 read-only 조회 HTTP API | Interface | Implemented | High | project maintainers | req-008 |
| REQ-009 | 데몬/API/영속화 baseline 문서 정합 | Documentation | Implemented | Medium | project maintainers | req-009 |
| REQ-010 | 데몬 설정 .env 파일 로딩 | Configuration | Implemented | Medium | project maintainers | req-010 |
| REQ-011 | BrokerPort 추상화 + paper/stub async 더블 | Integration | Implemented | High | project maintainers | req-011 |
| REQ-012 | KIS Open API 브로커 어댑터 | Integration | Implemented | High | project maintainers | req-012 |
| REQ-013 | 주문 집행 루프 (claim·송신·체결·롤백) | Integration | Implemented | High | project maintainers | req-013 |
| REQ-014 | 주문 핸드오프 durability + reconciliation | Exception | Implemented | High | project maintainers | req-014 |
| REQ-015 | 브로커/집행 baseline 문서 정합 | Documentation | Implemented | Medium | project maintainers | req-015 |
| REQ-016 | KIS 인증 토큰 Redis 캐시 | Integration | Implemented | Medium | project maintainers | req-016 |
| REQ-017 | LedgerPort 추상화 + portfolio-hub 어댑터 + stub | Integration | Implemented | High | project maintainers | req-017 |
| REQ-018 | 체결→원장 기록 (집행 루프 fill hook) | Integration | Implemented | High | project maintainers | req-018 |
| REQ-019 | ledger outbox durability + correlation_id 멱등 | Exception | Implemented | High | project maintainers | req-019 |
| REQ-020 | ledger 레이어 baseline 문서 정합 | Documentation | Implemented | Medium | project maintainers | req-020 |
| REQ-021 | messaging 토폴로지 + 메시지 계약 매핑 | Integration | Implemented | High | project maintainers | req-021 |
| REQ-022 | messaging transport 포트 + RabbitMQ 어댑터 + stub + sync+thread daemon | Integration | Implemented | High | project maintainers | req-022 |
| REQ-023 | messaging delivery 신뢰성 (effectively-once + durable + DLQ + publisher confirms) | Exception | Implemented | High | project maintainers | req-023 |
| REQ-024 | RabbitMQ 가용성 degrade 정책 (버퍼링 금지 + 보수적 중단 + core 안전 매도 독립) | Non-Functional | Implemented | High | project maintainers | req-024 |
| REQ-025 | HTTP /v1 API 완전 제거 (healthz 포함, HTTP 표면 0) |
Interface | Implemented | High | project maintainers | req-025 |
| REQ-026 | messaging 레이어 baseline 문서 정합 | Documentation | Implemented | Medium | project maintainers | req-026 |
| REQ-027 | portfolio-hub read 포트 + 어댑터 + stub | Integration | Implemented | High | project maintainers | req-027 |
| REQ-028 | 종목 스냅샷 read 메시지 계약 + envelope + degraded 신호 | Interface | Implemented | High | project maintainers | req-028 |
| REQ-029 | 자산 선별(slot overlay) + view 모드 + strategy_key 필터 | Interface | Implemented | High | project maintainers | req-029 |
| REQ-030 | 일일 스냅샷 스케줄러 + 옵션 D 현금/포지션 갱신 | Integration | Approved | High | project maintainers | req-030 |
| REQ-031 | 포지션 정합 검증 + warning 마스킹 | Exception | Implemented | High | project maintainers | req-031 |
| REQ-032 | 런타임 pause/resume 제어 | Interface | Implemented | Medium | project maintainers | req-032 |
| REQ-033 | 스냅샷 read 레이어 baseline 문서 정합 | Documentation | Implemented | Medium | project maintainers | req-033 |
Recent Change Log Summary
- 2026-06-06 :: REQ-029 CHG-04 — orb-v1 소비 참고 사항 추가(strategy_key 없이 view=buyable, 전략 필드 부재 무해). 문서 전용·Implemented 유지. (change-req)
- 2026-06-06 :: REQ-027
029, REQ-031033 Approved → Implemented — BAT-008 release-candidate verification evidence 기반. REQ-030 은 AC-1 evidence 확보·AC-2/AC-3 portfolio-hub#8 배포 대기로 Approved 유지. (confirm-req-implemented) - 2026-06-06 :: REQ-027~033 Proposed → Approved — dcy-005 confirmed, 전체 승인 게이트 통과. REQ-030 옵션 D 구현은 portfolio-hub#8 배포 후 착수. (confirm-req)
- 2026-06-06 :: REQ-027
033 최초 생성(Proposed) — dcy-005 FR-1FR-9 분해(NFR-1 → REQ-027 흡수, NFR-2 → REQ-030 흡수, NFR-3 → REQ-028 흡수). (draft-req) - 2026-06-05 :: REQ-021~026 Approved → Implemented — BAT-007 release-candidate verification evidence 기반. (confirm-req-implemented)