요구사항 킥오프
사용자는 중요한 결정을 초기에 명확하고 저렴하게 확정한 후, 검토된 단계별로 구축합니다. 한 번에 모든 것을 구축하면 나중에 되돌려야 할 추측이 포함됩니다. 아무것도 문서화되지 않은 채 오랫동안 침묵하며 숙고하는 것도 사용자에게는 똑같이 짜증나는 일입니다("한 번에 하지 않아도 되는데, 왜 이렇게 오래 생각해? 단계별 문서를 작성하자"). 따라서 질문과 계획을 신속하게 문서화하고, 사용자가 방향을 정하도록 하세요.
1. 간략히 수집
- 제공된 내용(파일, 폴더, 링크, 이미지, 이전 대화 및 메모 노트, 리포지토리 README)을 읽습니다. 이미 결정된 사항을 기록하여 다시 묻지 않도록 합니다.
- 입력이 아직 누락된 경우(링크가 아직 안 왔거나, 사진이 나중에 도착할 예정 등)에도 질문을 시작하고, 어느 질문이 이에 의존하는지 표시합니다.
- 아직 코드를 작성하거나 파일을 변경하지 마세요. 오래 숙고하지 마세요. 질문 자체가 사고 도구입니다.
2. 번호가 매겨진 질문하기
- 하나의 번호 목록이며, 질문이 많을 경우 주제별로 그룹화합니다. 각 질문은 한 줄로, 사용자가 볼 수 있는 옵션과 권장 기본값을 제시합니다. 예:
3. 설치 위치: C: 또는 D:? 권장: D: (C:가 거의 가득 찼으므로). - 사용자는 번호로 간결하게 답변합니다("1. 둘 다 2. 업데이트 3. ok"). 각 답변을 주의 깊게 매핑하세요. "ok" 또는 "agreed"는 기본값을 수락하는 것입니다. "former" 및 "latter"는 옵션 순서를 나타냅니다. 건너뛴 번호는 "당신이 결정하고 선택한 것을 알려주세요"를 의미합니다.
- 이번 작업에 중요한 사항을 다루십시오: 목표와 대상; 범위와 명시적 비목표; 입력과 출력(형식, 위치); 제약 조건(플랫폼, 허용되거나 금지된 도구, 라이선스, 오프라인 사용, 하드웨어); 품질 수준과 승인 테스트("작동하는지 어떻게 알 수 있나?"); 실패 동작(각 부분이 언제든지 실패할 때 발생하는 상황: 충돌, 연결 끊김, 정전, 여러 노드 중 하나의 다운); 충실도(절대 변경되어서는 안 되는 사항); 항목 위치(리포지토리, 경로, 원격); 전달(누가, 얼마나 자주 무엇을 받는지).
- 답변으로 인해 새로운 질문이 생긴 경우에만 두 번째, 더 짧은 라운드를 진행합니다. 나머지 미지의 사항이 안전한 기본값을 가지면 질문을 중단하고, 해당 기본값을 대신 나열합니다.
3. 계약서 작성: REQUIREMENTS.md
프로젝트 루트에 배치합니다. 프로젝트가 새 프로젝트인 경우 폴더를 만듭니다. 간결하고 날짜를 기입하여 유지합니다:
# <프로젝트> 요구사항
동의일: <YYYY-MM-DD>. 이 파일은 계약서입니다. 변경 사항은 날짜와 함께 여기에 기록됩니다.
## 목표
## 대상 및 사용
## 범위
## 비목표
## 결정 사항
- D-01 <결정> (<날짜>)
## 기능 요구사항
- FR-01 ...
## 제약 조건 및 비기능 요구사항
- NFR-01 ...
## 검증
요구사항별로 한 행: 검증 방법과 증거 위치.
| ID | 방법 (테스트 / 검사 / 분석 / 시연) | 증거 (테스트 케이스, 스크립트, 파일) |
## 미해결 질문
안정적인 ID(D-xx, FR-xx, NFR-xx)는 이후 작업, 커밋 및 보고서에서 이를 인용할 수 있게 합니다. 사용자의 답변을 사용자 자신의 용어로 기록하고, 더 강하거나 약하게 의역하지 마십시오.
모든 요구사항에 검증 방법과 증거 위치를 지정하십시오. 네 가지 방법은 요구사항 공학의 표준(ISO/IEC/IEEE 29148)입니다. 테스트를 선호하십시오. 요구사항을 검사 또는 분석으로만 확인할 수 있는 경우(예: "직접 OS 스레드 호출 금지", "노드당 스케줄링 오버헤드 100마이크로초 미만"), 증거를 저장하는 스크립트로 검사를 작성하여 증명을 재인수하지 않고 재실행할 수 있도록 하십시오.
4. 계획 작성: 단계
요구사항 옆에 PLAN.md 파일로 작성하거나, 프로젝트가 작은 경우 "단계" 섹션에 작성합니다. 0단계는 일반적으로 설정 또는 가장 위험한 가정을 먼저 입증하는 파일럿입니다. 각 단계에 대해 목표, 단계, 결과물, 검증 방법, 그리고 제공하는 요구사항 ID를 제공합니다. 단계를 한 번에 검토할 수 있을 만큼 작게 유지하고, 계획은 진행 중에 조정될 것임을 명시합니다.
그런 다음 중지합니다. 두 파일을 몇 줄로 요약하고 첫 번째 단계를 권장합니다.
5. 요청 시 한 번에 한 단계씩 실행
- 사용자가 지정한 단계만 실행합니다("0단계 실행", "0단계와 1단계 실행", "시작").
- 각 단계가 끝나면 수행된 작업, 작동을 입증하는 증거(실행된 명령, 출력, 테스트 결과), 계획에서 벗어난 부분과 그 이유, 그리고 다음 단계를 보고합니다. 계획에서 해당 단계를 완료로 표시합니다.
- "진행 상황 확인"은 현재 단계, 완료된 작업, 실행 중인 작업, 차단된 작업을 의미합니다.
- 범위를 변경하는 새로운 요청은 구축하기 전에 REQUIREMENTS.md에 날짜와 함께 추가합니다. 결정이 번복된 경우 번복으로 기록하고 이전 행은 그대로 둡니다.
- 진행 중 발견된 버그는 사용자가 요청한 경우에만 수정하고, 그렇지 않으면 목록화합니다.
- 마지막 단계가 완료되거나 사용자가 요청하면, 요구사항과 코드, 테스트, 문서 및 증거 간의 차이 분석을 실행합니다. 각 차이를 요구사항 ID와 함께 보고하고, 요청 시 하나씩 수정한 후 증거 스크립트를 재실행합니다.
- 각 단계 후에 커밋하거나 푸시하지 마십시오. 단계가 완료되면 커밋을 제안하고, 요청 시에만 푸시합니다.
변형
- 코드 없는 결정 (구매, 도구 선택): 동일한 질문 후, 두 파일 대신 합의된 기준에 대한 간단한 비교를 작성합니다.
- 타인의 콘텐츠 (저자의 책, 클라이언트의 데이터, 녹음): 초기에 충실도 요구사항을 추가합니다. 콘텐츠가 묵시적으로 변경되지 않습니다. 모든 변경 사항은 제안, 표시, 보고되어 승인을 받아야 합니다.