회의에서 나온 긴 문장은 여러 동작과 이유를 한꺼번에 담습니다. 그대로 옮기면 담당마다 완료 상태를 다르게 읽을 수 있으므로 요청 배경, 해야 할 동작, 결과를 확인할 증거로 분리합니다.
요구표에는 번호, 배경, 단일 동작, 입력 조건, 완료 증거, 담당, 우선순위, 보류 이유를 둡니다. 한 줄에 동작이 둘 이상이면 다시 쪼갭니다. 완료를 확인할 문장을 쓸 수 없는 의견은 요구사항과 분리해 논의 목록에 둡니다.
가상의 요청이 화면을 보기 좋게 바꿔 달라는 말이라면 임의 디자인을 시작하지 않습니다. 어떤 사용자가 어느 화면에서 어떤 행동을 해야 하는지 되묻고 확인 가능한 상태로 바꿉니다. 이는 실제 프로젝트 합의 사례가 아닙니다.
정리본은 회의에서 읽는 것으로 끝내지 않고 문서로 보내 회신 상태를 남깁니다. 우선순위 변경은 이전 값을 지우지 않고 날짜와 승인자를 추가합니다. 답이 없는 항목을 합의된 요구로 처리하지 않습니다.
좋은 요구사항 문서는 말을 짧게 줄인 기록이 아니라 배경이 바뀌면 다른 해법을 검토할 수 있고, 완료 시 같은 증거로 양쪽이 확인할 수 있는 계약입니다. 회신과 변경 이력이 있어야 뒤늦은 기억 차이를 줄일 수 있습니다.
요구사항에 예시가 필요하다면 실제 고객 정보나 미승인 화면을 사용하지 않고 가상 입력과 예상 결과를 분리합니다. 한 항목이 다른 항목을 전제로 하면 의존 번호를 남겨 우선순위가 바뀌어도 선후 관계가 무너지지 않게 합니다. 완료 증거가 확인된 뒤에도 요청자가 범위 밖의 새 동작을 원하면 기존 항목을 수정 완료로 되돌리지 않고 새 요청으로 등록합니다. 회신에서 일부만 승인된 경우 행별 상태를 나눠 전체 목록이 확정된 것처럼 보이지 않게 합니다.