개발 기획서 팀장 검토

세 전문 초안이 모두 도착한 다음 실행한다. 각 초안의 결론을 그대로 이어 붙이지 말고 원문, 요구 ID, 역할과 상태 흐름을 대조한다.

통합 검토

1. 원문 사실, 원문의 목표, 구현 제안, 계약 전 결정사항을 내부 검토에서 구분한다. 납품 본문에는 목표를 문장으로 설명하고 필요한 곳만 설계제안:, 확인사항:으로 표시한다. 참고 문서의 프로젝트 사실은 가져오지 않는다.
2. 모든 REQ ID를 개발 범위, 우선순위, 기능 처리·오류·완료 기준, 검수 증거와 연결한다. 누락·중복·범위 밖 항목을 고친다. P0에 수용 기준이 없으면 원문으로 보완하고, 원문으로 확정할 수 없는 조건은 설계제안 또는 요청자 확인사항으로 남긴다. 우선순위·요구 상태·범위를 구분하고, P2와 이번 계약 범위가 충돌하면 둘 다 보존해 요청자에게 확인한다. 장간 일관성을 맞추려고 확정 기능을 삭제하지 않는다.
3. 화면의 필드와 동작이 데이터 모델·권한·상태 전이·보고 계산에 실제로 연결되는지 확인한다. 자료에 나온 역할 간 인계 지점을 맞춘다.
4. 같은 수치의 분모·단위·측정 시점을 확인한다. PoC·검수·파일럿의 표본과 목표, 가능 판정과 실제 성공률을 구분한다. 성공 지표의 종류·측정 방법·목표값을 대조하고, 근거 없이 채운 목표값은 확정값에서 제거해 확인사항으로 남긴다. 누락된 측정 조건도 분리하고 사업 목표를 납품 합격 기준으로 바꾸지 않는다.
5. 수치·기간·정책이 원문에서 제안인 경우 실적·확정 규격처럼 쓰지 않는다. 불일치는 수정하거나 계약 전 확인에 모은다. 모든 확인사항에 결정할 역할 태그를 붙이고 관련 요구·화면 ID가 있으면 연결해 마지막 목록을 역할별로 묶는다. 담당을 알 수 없으면 요청자에게 담당 역할 지정을 확인한다.

산출물별 필수 스킬

조건에 해당하면 이름만 나열하지 말고 해당 스킬을 읽고 적용한다.