portfolio-hub/base/.github/instructions/srs.instructions.md

description, applyTo

description	applyTo
Use when writing or editing SRS documents, requirement files, acceptance criteria, change logs, or impacted area entries under docs/SRS. Ensures requirement quality, traceability, and testable wording.	docs/SRS/**/*.md

SRS Document Guidelines

Requirement 타입 분류

분류 의사결정 규칙 (우선순위 순)

1. Installation: "시스템 설치, 환경 구성, 초기화 절차를 정의하는가?" → YES면 Installation
   • 예: Docker 이미지 빌드, 데이터베이스 마이그레이션, 사전 조건 설정
2. Interface: "사용자가 직접 조작하거나 실행하는 방식을 정의하는가?" → YES면 Interface
   • 예: CLI 명령어, API 엔드포인트, 웹 UI 기능, 제어 방식
3. Configuration: "시스템 또는 기능의 설정 옵션, 커스터마이징을 정의하는가?" → YES면 Configuration
   • 예: 설정 파라미터, 옵션 항목, 환경 변수, 커스터마이징 포인트
4. Data: "데이터 저장, 로드, 구조, 파일 형식, 스키마를 정의하는가?" → YES면 Data
   • 예: 설정 파일 형식, 데이터베이스 스키마, API 요청/응답 구조
5. Exception & Error Handling: "오류 처리, 예외 복구, 재시도 전략을 중심으로 하는가?" → YES면 Exception & Error Handling
   • 예: 네트워크 오류 재시도, 데이터 검증 실패 처리, 복구 절차
6. Deployment: "배포 방식, 운영 절차, 배포 환경을 정의하는가?" → YES면 Deployment
   • 예: 컨테이너 배포, 스택 관리, 운영 가이드
7. Documentation: "문서 작성, 가이드, 매뉴얼, 안내서를 정의하는가?" → YES면 Documentation
   • 예: 사용자 가이드, API 문서, 운영 매뉴얼, 튜토리얼
8. Integration: "외부 시스템 연동, 플러그인, 확장 기능을 정의하는가?" → YES면 Integration
   • 예: 3rd party 서비스 연동, 플러그인 인터페이스, 확장 메커니즘
9. Migration: "데이터 이전, 버전 업그레이드, 마이그레이션을 정의하는가?" → YES면 Migration
   • 예: 데이터 마이그레이션, 버전 호환성, 업그레이드 절차
10. Testing: "테스트 전략, QA 요구사항, 검증 방식을 정의하는가?" → YES면 Testing
    • 예: 테스트 커버리지, 회귀 테스트, 수락 테스트 기준
11. Non-Functional: 위 모든 경우에 해당하지 않으면 → Non-Functional
    • 예: 성능 목표, 보안 정책, 확장성, 호환성, 신뢰성 요구사항

주의: requirement가 여러 분류에 해당하면 주된 제약 또는 목적에 따라 하나로만 선택한다. 예를 들어:

• "Docker Compose로 배포할 수 있어야 한다" → Deployment

• "배포 시 환경 변수로 설정 가능해야 한다" → Configuration

• "배포 전에 다음 점검 항목을 검증해야 한다" → Testing/Documentation

• docs/SRS/index.md는 SRS 운영 기준과 Requirement Register를 관리하는 문서로 유지한다.

• docs/SRS/REQ-XXX_*.md는 하나의 requirement만 다루고, 다른 requirement 내용을 섞지 않는다. 파일은 Type별 폴더에 저장한다. 예: docs/SRS/Deployment/REQ-001_docker-compose-release.md

• 새 requirement 번호의 source of truth는 docs/SRS/index.md의 Next Requirement ID다.

• requirement 본문에는 최소한 Status, Type, Priority, Owner, Intent, Requirement, Acceptance Criteria, Impacted Area, Change Log가 포함되어야 한다.

• Acceptance Criteria는 관찰 가능하고 test 가능한 문장으로 작성한다.

• 모호한 표현("개선한다", "적절히 처리한다", "최적화한다")은 측정 기준 없이 사용하지 않는다.

• requirement를 수정하면 해당 REQ 파일의 Change Log도 함께 갱신한다.

• Impacted Area는 Docs, Modules, Tests를 모두 검토한 뒤 작성한다. 해당 항목이 없으면 없음으로 명시한다.

• implementation issue/PR를 생성하거나 병합할 때는 docs/SRS/traceability-matrix.md에서 해당 REQ 행의 Issue/PR, Tests, Status를 갱신한다.

• 새로운 Type으로 requirement를 추가할 때는 docs/SRS/<Type>/ 폴더 하위에 저장한다. 아직 없는 Type 폴더면 생성한다.

• 새로운 requirement를 추가하면 docs/SRS/index.md의 Requirement Register에도 같은 ID를 추가한다.

• 새로운 requirement를 추가하거나 Register가 바뀌면 docs/SRS/index.md의 Next Requirement ID도 함께 갱신한다.

• docs/SRS/index.md의 Recent Change Log Summary는 최신 5건만 유지하고 최신 항목을 위에 둔다.

• requirement ID와 파일명 prefix는 일치해야 한다. 예: REQ-002는 docs/SRS/<Type>/REQ-002_<slug>.md.

• requirement 상태를 Approved 또는 Implemented로 바꿀 때는 acceptance criteria와 change history가 누락되지 않았는지 먼저 검토한다.

• requirement 상태를 전환할 때는 docs/SRS/index.md의 Status Transition Evidence 기준을 따른다.