자동차, 건축, 소프트웨어 개발 등 고객을 대상으로 제품을 만들고 서비스를 제공하는 팀의 대부분은 고객과 시장의 요구사항을 작성하는데 시간을 할애하는 것에 주저하지만, 요구사항을 작성하는 것은 어려운 일이 아니다. 정작 어려운 일은 요구사항을 발견하는 것이다. 특히 소프트웨어 시스템을 구축하는 데 있어서 가장 어려운 부분 중의 하나는 무엇을 구축할 것인지를 고객으로부터 정확하게 도출하는 것이다. 인터뷰 등을 통해 요구사항을 말할 때 고객은 합리적으로 행동하고 있을 것이란 가정에 근거를 두고 있지만 실은 고객은 질문한 사항에 대해서만 대답할 뿐 그 이상은 말하지 않는다. ‘알아서 잘해주세요.’ 라고 방관자적인 소리 없는 미소를 짓는다. 열길 물 속은 알아도 한길 사람 속은 알기가 어려운 법이다.

그러나 비즈니스 현실은 요구사항에 의해 명암이 좌지우지된다. IEEE의 소프트웨어 용어집에는 요구사항은 ‘문제를 해결하거나 목적을 달성하기 위하여 사용자가 필요로 하는 조건 또는 기능’으로 정의되어있다. 즉 요구사항을 정확히 발견해내면 고객이 당면한 문제점을 해결하고 비즈니스 목적을 달성할 수 있는 것이다. 거꾸로 요구사항이 무엇인지를 알지 못한다면, 그 프로젝트가 언제 완료되는지를 알 수 없으며, 바라던 목표를 달성했는지를 판단할 수 없으며, 범위를 축소하거나 확장할 경우의 파장에 대해 제대로 의사결정을 할 수 없게 된다.

전반부의 잘못 파악된 요구사항은 후반부의 잘못된 프로그래밍 작업이나 테스트 작업에 낭비되는 돈보다 훨씬 많은 돈이 낭비된다. 통계적으로 제시되는 수치에 따르면 요구사항 결함 하나의 해결 비용은 프로그래밍 오류 50-100개 해결 비용과 비슷하다고 한다. 정보공학의 창시자 제임스 마틴은 ‘프로그래머가 프로그래밍 언어를 잘못 사용하여 밤을 새면서 프로그램 코딩을 하는 경우는 5~10%도 채 안 된다. 프로그래머가 밤을 새는 이유는 대부분이 구축하고자 하는 시스템의 대상 업무를 잘못 파악해 프로그램을 수정하는 것 때문이다.’ 라고 일찍이 요구사항 파악의 중요성을 간파했다.

프로젝트 팀은 인터뷰 등을 통해 고객이 공식적으로 요구한 사항만 제품 개발에 반영하는 경향이 강하다. 이러한 활동은 고객과 프로젝트 팀과의 마찰 요인이 될 수 있다. 요구사항은 고객이 요구한 사항만을 의미하는 것이 아니다. 요구사항은 고객이 베푸는 시혜가 아니라 정 끝으로 원석을 쪼아서 보석을 캐내는 작업이다. 수동적으로 주어지는 것이 아니라 능동적으로 개발해야 하는 것이다. 프로그램만 개발하는 것이 아니라 고객의 요구사항도 개발해야 한다.

요구사항이 잘 개발되기 위해서는 몇 가지 중요한 활동이 필요하다. 먼저 요구사항 개념의 전환이 필요하다. 요구사항은 고객이 명시하지 않더라도 고객이 기대하는 것, 원하는 것, 필요한 것을 포함해야 한다. 고객이 기업으로부터 구입하는 것은 단순히 제품과 서비스 그 자체는 아니다. 고객이 실제로 구입하는 것은 제품과 서비스가 제공하는 효율(utility)과 가치(value)이다. 여기서 효율과 가치는 각각 고객이 원하는 것과 고객에게 필요한 것으로 구분해 볼 수 있다.

요구사항 개발의 적절한 사례는 돌멩이 수프의 우화에 잘 표현되어 있다.

어느 마을에 기근이 들어서 모두가 굶어 죽을 지경이었습니다. 인심도 사나워졌습니다. 서로 문을 꽁꽁 걸어 잠그고, 이웃끼리 경계하게 되었지요. 그런데 이 마을에 나그네 한 사람이 찾아 듭니다. 손님은 마을의 광장에 솥 단지를 걸고 물을 붓고 뭔가 잔뜩 갖다 넣더니 불을 땝니다. 지나가던 사람이 묻습니다.
"그 솥에 뭘 끓이시나요?"
"죽을 끓이는데....배추가 조금만 더 있으면 세상에서 가장 맛있는 죽이 될 텐데..."
마을사람이 아껴두었던 배추를 가지고 나옵니다. "내가 배추를 줄 테니 우리에게 그 죽을 조금 나눠주세요"
배추가 솥 단지에 들어갑니다. 마을 사람들이 음식냄새를 맡고 하나 둘씩 나옵니다.
"뭔가 집안에 있는 부스러기를 가지고 나와보세요. 죽을 맛있게 끓일 수 있게...."
사람들이 집안에 아껴두었던 식량을 조금씩 가지고 나옵니다. 그것들을 죽 솥에 넣습니다. 커다란 솥에 죽이 하나 가득 끓습니다. 손님은 그 죽을 마을사람들에게 퍼줍니다. 온 마을 사람들이 죽을 배가 부르도록 먹어도 죽은 조금 남았습니다.
"세상에 이렇게 맛있는 죽은 생전 처음 먹어봅니다. 그런데 처음에 솥에 넣은 게 뭐였나요?” 이장님이 고마워하며 묻습니다.
나그네가 빙긋 웃으며 대답합니다.
"먹을게 아무것도 없어서, 그냥 돌멩이를 넣고 끓이고 있었지요. 하지만, 사람들이 모두 조금씩 뭔가 가져왔기 때문에 맛있는 죽을 아주 많이 끓일 수 있게 된 거지요."

위 예화의 결론은 나그네와 마을 사람들 모두가 맛있는 죽을 먹게 되어 서로 유익한 결과를 만들어낸 해피엔딩이다. 꽁꽁 닫혀있던 마을 사람들의 마음을 열 수 있었던 비결은 무엇이었을까? 나그네는 광장 솥 단지에 돌멩이를 넣음으로써 마을 사람들의 호기심을 자극했고 이는 결과적으로 다양한 고객의 참여를 성공적으로 유도해냈던 것이다.

고객들은 때때로 요구사항을 수집하고 그 품질을 확인하기 위해 노력하는 것이 얼마나 중요한지를 이해하지 못한다. 프로젝트 팀도 고객과 협력하는 것이 산출물을 작성하는 것보다 재미가 없고, 또 이미 고객의 요구를 알고 있다고 생각하기 때문에 고객 참여를 강조하지 않는다. 불충분한 고객 참여는 뒤늦은 요구사항 추가를 통해 프로젝트 완료를 지연시키는 폭주하는 프로젝트를 만들 수 있다. 프로젝트 전 단계에 걸쳐 고객과 프로젝트 팀의 직접적인 협력보다 더 좋은 성공요인은 없다.

요구사항 개발에 있어서 가장 큰 문제는 요구사항의 누락이다. 누락이란 업무 범위에서 제외된다는 뜻이며, 평상시에는 수면 속에 조용히 가라앉아 있다가 프로젝트 후반부에 수면위로 떠오른다. 특히 업무 기능적인 요구사항 이외의 품질특성, 인터페이스, 데이터 전환, 제약조건, 비즈니스 룰 등 비기능 요구사항에 대한 누락이 빈번하게 발생한다. 누락은 애매모호한 요구사항정의보다 더 큰 악영향을 끼친다. 요구사항의 애매모호함이란 하나의 요구사항을 여러 가지로 해석할 수 있다는 것이다. 불충분한 요구사항은 영화 세트를 만들듯이 미리 사전에 시연(프로토타입)을 만들거나 요구사항을 테스트하는 케이스를 만들어 보는 방법 등을 통해서 정리해 나갈 수 있다.

또한 요구사항의 명확한 합의 도출을 위해서 요구사항을 제시하고 결정을 하는 사용자 계층을 정확히 파악하여야 한다. 실제로 프로젝트에서는 사용자와 요구사항에 대해 합의해 놓고서도 후반부에 송두리째 변경되는 경우가 발생한다. 이 원인은 고객의 요구사항 변경 요청도 문제가 있지만, 고객을 상대하는 프로젝트 팀의 경우에도 요구사항에 대한 의사결정 계층, 사람(Keyman)을 명확히 파악하지 못한 책임도 있다. 따라서 모든 사용자층을 파악한 후에 각각의 계층이 나름대로의 의견을 가지고 있다는 것을 알고 이를 조율하는 과정이 필요하다.

고객의 비즈니스를 개발하는 프로젝트의 성공이란 어찌 보면 단순하다. 기술적인 것보다 고객이 원하는 것이 무엇인지를 잘 파악해서 그것을 잘 만들어내면 되는 것이다. 여기서 핵심은 잘 만들기 위해서는 잘 파악해야 한다는 점이다. 그 동안 우리는 만든 제품을 어떻게 고객에게 잘 팔 것인가에 초점을 맞추었다. 그러나 이제 비즈니스는 고객이 원하는 것을 넘어서 필요한 것을 미리 예견하여 제품과 서비스를 만들어냄으로써 새로운 시장을 창출하는 과정으로 진화하고 있다. 앞으로 고객의 ‘새로운’ 요구사항을 잘 발굴하는 기업이 성공할 것은 자명하다. 우리들이 일하는 방식을 창의적으로 변경하지 않는다면, 열심히 한다 하더라도 현재의 사업이 예전보다 더 나아질 수 있다는 믿음은 한낱 신기루에 불과할 뿐이다.