54 lines
4.9 KiB
Markdown
54 lines
4.9 KiB
Markdown
---
|
|
description: "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."
|
|
applyTo: "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` 기준을 따른다.
|