요구사항 정의서와 기능 명세서에 무엇을 적을까

개발을 의뢰할 때 화면 목록부터 만들면 중요한 업무 규칙을 놓칠 수 있습니다. 누가 무슨 일을 하려는지 먼저 적고 그 일을 시스템이 어떻게 처리할지 이어서 설명해 보세요.

요구사항은 업무와 완료 기준을 설명합니다

가정한 예시로 반품 담당자가 같은 내용을 여러 파일에 다시 입력하고 있다고 해 봅시다. 요구사항에는 '반품 관리 화면 개발'보다 현재 입력 과정, 관련 담당자, 원주문과 연결해야 할 정보, 완료 여부를 확인할 기준이 필요합니다.

개선 효과를 아직 측정하지 않았다면 절감 시간을 약속하지 않습니다. 대신 반품 접수 후 어느 단계까지 재입력 없이 처리할 수 있어야 하는지 확인 가능한 조건을 적습니다.

기능 명세는 조건에 따른 동작을 설명합니다

반품 접수를 예로 들면 필수 입력값, 원주문을 찾는 방법, 수량 제한, 저장 후 상태, 수정 가능한 사람과 시점을 적습니다. 주문을 찾지 못했거나 이미 반품된 상품을 선택했을 때의 처리도 필요합니다.

두 문서의 이름과 구분은 팀마다 다를 수 있습니다. 업무 목적과 구현할 동작이 서로 연결되는지, 담당자가 같은 뜻으로 읽을 수 있는지가 중요합니다.

개발사에 보낼 첫 자료에는 현재 업무 흐름, 실제 양식의 익명 샘플, 자주 생기는 예외, 이번에 제외할 범위를 넣습니다. 확정되지 않은 항목은 빈칸을 감추지 말고 결정할 사람과 시점을 표시합니다.

검수할 때는 요구사항마다 정상 처리와 예외 상황을 직접 확인합니다. 문서가 길어도 통과 조건이 없다면 끝났는지 합의하기 어렵습니다. 개발 상담에는 완성된 명세서가 없어도 현재 업무 자료부터 가져올 수 있습니다.