요구사항 정의서가 부실하면 생기는 일

# 요구사항 정의서가 부실하면 생기는 일

정보화 사업에서 가장 앞에 놓이는 문서가 요구사항 정의서다. 이 문서가 흔들리면, 뒤에 오는 설계와 개발이 아무리 성실해도 엉뚱한 곳에 도착한다. 첫 단추 이야기가 괜히 나오는 게 아니다.

## 모호함은 뒤로 갈수록 커진다

정의서에 "직관적인 화면"이라고만 적혀 있으면, 개발자는 자기 식으로 해석한다. 발주자가 머릿속에 그린 것과 다른 결과가 나오고, 그제야 "이게 아닌데"가 시작된다. 앞에서 한 줄로 끝낸 모호함이, 뒤에서는 화면 전체를 다시 만드는 일이 된다.

## 검증할 수 있게 적는다

좋은 요구사항은 나중에 "됐다/안 됐다"를 판단할 수 있게 쓰여 있다. "빠르게 처리"보다 "조회 결과가 몇 초 안에 나온다"처럼, 확인 가능한 형태로 적으면 시험 단계에서 다툴 일이 줄어든다.

## 누가 무엇을 하는지 분명히 한다

기능만 나열하고 그 기능을 누가 어떤 상황에서 쓰는지가 빠지면, 정작 현장에서 안 쓰는 기능이 만들어진다. 사용자가 어떤 일을 하려고 이 기능을 쓰는지까지 적어 두면, 만드는 쪽이 맥락을 이해하고 만든다.

요구사항 정의는 가장 지루하지만 가장 영향이 큰 단계다. 여기서 들인 시간은 뒤에서 두세 배로 아껴지고, 여기서 아낀 시간은 뒤에서 몇 배의 손질로 돌아온다.