회의에서 “사이트를 좀 더 편하게 해 주세요”라는 요청을 들었다면 바로 디자인을 고치기 어렵습니다. 어떤 사람이 어느 화면에서 무엇을 못 하고 있는지 분명하지 않기 때문입니다. 요구사항은 요청 배경과 검증할 결과를 분리해 기록해야 합니다.
먼저 요청자의 원문 표현을 남기고, 그 말을 하게 된 상황을 묻습니다. 화면이 느린지, 예약 버튼을 찾지 못하는지, 입력 중 오류가 나는지는 서로 다른 작업입니다. 한 문장에 여러 행동이 섞였으면 항목을 나누고 각각 담당자, 필요한 자료, 완료 조건을 붙입니다. ‘편하게’라는 형용사 대신 ‘휴대전화에서 예약 신청까지 세 단계 이내’처럼 확인 가능한 조건을 협의할 수 있습니다.
조건은 실제 사용자 흐름으로 점검합니다. 예를 들어 버튼 위치만 바꾸어도 사용자가 접수 완료 문자를 받지 못한다면 문제는 끝나지 않았습니다. 기존 기능과 충돌하거나 정보 보안에 영향을 주는 변경은 따로 표시하고 결정권자를 명시합니다.
회의 후에는 항목 목록을 상대에게 다시 보내 우선순위와 미확정 부분을 확인합니다. 구두로 동의한 듯한 표현을 확정 사항으로 옮기지 않습니다. 변경 요청이 생기면 원래 목적과 새 조건을 나란히 놓고 범위·일정의 영향을 다시 정리합니다. 명확한 요구사항은 모든 세부 방법을 처음부터 아는 문서가 아니라 무엇을 확인해야 완료인지 공유하는 문서입니다.
완료 조건이 정해져도 확인할 사람이 없으면 작업은 멈춥니다. 각 항목에 요청자와 승인자를 표시하고, 결과를 확인할 화면이나 문서의 위치를 지정합니다. 일정에 영향을 미치는 외부 자료가 아직 도착하지 않았다면 미확정 상태로 남겨야 합니다. 마감일을 맞추기 위해 가정한 내용을 확정 사실처럼 쓰지 않도록 합니다.