완벽하지 않은 요구사항

개발자들은 사용자가 원하는 바를 모른다고 불평한다.
그러나 입장을 바꿔놓고 생각 해보자.
자동차 기술자에게 원하는 차를 자세하게 설명한다고 상상해보라.
엔진,몸체,창문,운전대,가속기 페달,브레이크 페달,비상 브레이크,좌석 등을 원한다고 기술자에게 전한다.
그렇지만 자동차 기술자가 차를 만드는데 필요한 모든 항목을 빠뜨리지 않고 말해줄 수 있을까?

차가 후진할 때 켜지는 후진등을 잊었다고 치자. 6개월 후, 기술자는 후진등이 없는 차를 완성해 보여준다.
"이런, 기어를 후진으로 바꾸면 후진등이 자동으로 켜져야 한다는 사항을 잊었습니다"

기술자는 버럭 화를 낸다.
"변속기에서 차 뒷부분까지 전선을 연결하는 데 얼마나 일이 많은지 아십니까? 차 뒷부분 패널을 다시 설계해야 하고 브레이크 등에 전선을 연결해야 하고, 변속기에 감지기를 더 달아야 합니다. 몇 달까지는 아니라도 몇 주는 더 걸립니다. 왜 처음부터 말하지 않았죠?"

간단한 요구 같은데, 할 말이 없다.

이해할 수 있는 실수다. 그렇지 않은가? 자동차는 비전문가가 명시하기에는 너무 복잡한 물건이다.
소프트웨어 제품 역시 복잡하다. 소프트웨ㅔ어를 명시하는 책임을 맡은 사람들이 전문가가 아닌 경우도 흔하다.
실제로 돌아가는 제품을 보고 나서야 자신들이 느끼기에는 간단한 사항을 생각해낸다.

- RAPID Development (스티브 맥코넬) 책 생명주기 계획 글 중에서...-