우리가 소프트웨어를 개발하는 동안 요구사항이 변경되지 않는 경우는 거의 없다. 요구사항은 수시로 바뀐다. 출시가 당장 내일인 경우에도 변경되는 경우도 있다. 그리고 우리는 요구사항의 변경이 얼마나 큰 위험을 가져오는지 알면서도 요구사항을 수시로 변경한다. 때로는 변경하지 않기 위해 처절한 몸부림으로 저항하기도 한다. 요구사항은 왜 변경되는것일까? 그보다 요구사항은 변경 가능한 것일까? 여기서 가장 중요한 것은 소프트웨어가 눈에 보이지 않는 것이다. 만약 우리가 집을 짓는다면 우리는 매순간 우리가 내린 결정이 집을 건축하는 과정에 어떤 영향을 미치는지 즉시 알아낼 수 있다. 부지 선정, 집의 위치, 토지 다지기, 기초 공사, 콘크리트 붓기 등등 매순간 매순간의 작업에 대해 그 작업이 완료된 후 어떤 결과를 가져올 것인지 예측해낼수 있다. 때문에 각각의 시공이 진행될수록 우리가 마음을 바꾸거나 실수를 고치기가 점점 더 어려워진다는 것을 쉽게 깨달을 수 있다. 하지만 이런 건축과 달리 소프트웨어는 눈에 보이는 형체가 없다. 이것이 우리가 소프트웨어 개발 도중 요구사항을 쉽게 바꾸는 계기를 제공하게 된다. 우리는 중간 과정에서 '일의 실체'를 볼 수 없기 때문에 언제나 요구사항을 변경한다. 그리고 그러한 요구사항의 변경은 우리에게 반드시 어려운 시련의 시간을 가져다 준다. 하나 예를 들어보자. 여러분이 정사각형 모양의 방을 만든다고 가정해 보자. 그런데 콘크리트로 벽을 세울 때 실수로 한 대각선의 길이가 다른 대각선 길이보다 길어졌다고 가정해보자. 이것은 인접한 두 변이 모두 길어졌다는 것을 의미한다. 안타깝게도 콘크리트가 완전히 굳은 후에 이 실수를 발견하고 말았다. 이 실수를 고치지 않으면 예정되어 있던 가구나, 벽지, 외장재 등 모든 남아있는 시공 과정에 영향을 미치게 된다. 때문에 이제 실수를 만회하기 우해서는 잘못된 두 변에 모두 콘크리트를 다시 부어야 한다. 그러기 위해서는 잘못 만들어진 벽을