요구 사항의 정의

일단 켄트백이 주장한 요구사항이라는 단어 자체가 잘못 사용되고 있다는 것에 동의 한다.고객(사용자)은 우리에게 자신들이 원하는 것을 만들어 주기를 바라며, 비용을 지불한다.그때 고객(사용자)이 우리에게 원하는 것을 요구사항이라고 한다.
하지만 사전적 의미의 요구사항이란 필수적이거나 강제적인 무엇 이다.
켄트백의 주장처럼 우리가 소프트웨어를 개발 함에 꼭 필수 적이고 강제 적인 사항은 전체의 10%~20% 밖에 되지 않는다. 나머지 대다수의 요구 사항들은 꼭 필수 적이고 강제 적이지 않다.
누군가 나에게 이렇게 반문 할 수 있겠지만 ‘고객은 꼭 그 요구사항을 만족 해달라고 한다’ 하지만 우리가 소프트 웨어를 개발 함에 요구사항이라는 것들이 시간이 지나면 쉽게 변화 해 버리는 것을 볼때 역시 요구사항이란 정적인 사항이 아닌 항상 변화와 동적인 것을 동반하는 것이라고 생각 할 수 있다.

요구사항은 의사소통의 문제이다.
앞서 말한 것과 같이 고객이 원하는 것을 우리에게 알려주는 그리고 우리는 고객이 원한는 것이 어떻게 실체를 갖출것이며, 얼마의 비용이 들어 간다는 것을 알려주는 행위 이다.즉 고객은 자신이 구상하고 필요한 소프트웨어의 기능을 전달 하고, 개발자는 실제 구현될 소프트웨어의 기능과 비용을 전달 한다.
이 과정의 핵심은 존중속에서 양쪽의 균형을 지키는 것이다.
고객이 기술진을 존중 하지 않으면, 지켜 질수 없는 기능과 일정을 모두 요구 할 것이다.
또한 기술진이 고객을 존중 하지 않으면 요구사항을 만족 하지 못한는 미약한 기능과 과도한 비용을 고객에게 지울 것이다.
만약 요구사항 과정에서 존중을 바탕으로한 의사소통의 핵심 기술이 지켜 지지 않는다면, 프로젝트는 실패 할 것이다.

이처럼 요구사항이란 원한 것이 무엇이고 어떤 것을 만들어야 하는가의 단순한 기능 나열이나 수집의 문제가 아니다. 요구사항에서는 고객과 기술진이 모두 만족 하고 지켜질수 있는 결과를 도출해야 하며, 모든 요구사항이 결론적으로 고객이 추구하는 프로젝트의 결과 이익을 최대화 할 수 있도록 논리적으로 타당한 조정의 결과 이다.

Q: 지금 사용자 스토리를 읽고 있습니다. 몇 년 전에 XP를 읽고 느꼈던 감동이 다시 오더군요. 그때도 지금도 고민되는 문제점이 있습니다. 제가 XP를 처음 접할 때 저는 벤처기업에 있었고 개발이 상당히 어렵게 진행되고 있었습니다. 대표적으로 회사가 상하로 나누어져 위에서는 개발자를 재촉하고 개발자는 수동적으로 따라가는 구조였습니다. 저는 그때 개발팀을 이끌고 있었고, 그래서 그런 현실이 안타까웠습니다. XP를 읽고 한번에는 안되겠지만 점차 적용을 해야겠다고 생각하고 개발자들과 회의 시간에 XP를 알렸습니다. 그런데 그때의 개발팀의 멤버는 아주 비관적인 말을 했지만 저도 답변을 할 수가 없었고, 지금도 마찬가지 입니다.

"스토리를 만드는 것이 일을 크게 하는 것이 아닌가?. 주어진 데로 하는 것도 쉽지 않은데 스토리를 작성해서 일이 커질 경우 개발 비용을 고스란히 개발팀이 떠 안아야 한다."

이렇게 요약을 할 수 있는데요. 이 부분에 대해서 어떻게 생각하시는 지요? 예를 들면 지금 제가 개발 업체를 다니고 있고, 이번에 우리 회사가 카드회사의 새로운 프로젝트를 맡았다고 할 경우에, 이미 제안서와 요구사항에 의한 비용산출이 끝난 이후 개발팀이 투입이 될 것입니다. 개발팀의 팀장은 XP를 이용하고자 했습니다. 카드회사의 새로운 프로젝트를 사용하는 사용자를 만나 미팅을 해서 프로젝트를 좀더 효과적으로 성공시킬 수 있는 아이디어를 도출할 수 있었습니다. 새롭게 도출된 결과는 카드 회사입장에서 상당히 장점이 있는 것으로 카드 회사는 제가 다니는 회사와 협의를 하게 될 것입니다.

이때 제가 다니는 회사에서 "왜 긁어 부스럼을 만들 어냐?"라는 말이 나올 수 있습니다. 많은 경우 아이디어는 일을 크게 하는 경우를 많이 봤습니다. 이런 경우에, 반복 주기에 고객의 의견을 반영함으로써 프로젝트의 완성도는 좋아지지만 점차 발생하게 되는 비용의 문제는 어떻게 해결해야 하는지요? 외국의 경우, 반복 주기마다 계약된 금액이 변경될 수 있나요?. 또는 국내 프로젝트에서는 어떤가요? 계약사항이 있는데도 "갑"이라는 이유로 요구사항을 변경하는 경우도 비일비재한데, 개발팀이 스토리 확장 및 변경에 관한 비용 문제를 어떻게 이겨내야 할까요?

A : 제 경험과 생각으로는 어차피 XP 나 기타 다른 Agile Process 가 아닌 전통 적인 개발 방법론을 사용하더라도 사용자의 기대 수준과 기획 시 계획의 차이는 해결해야 할 문제 인 것 같습니다. 프로젝트의 계약 시 보통 아주 세부적인 사항까지 계약하지는 않습니다. 개발 되는 시스템의 목적과 용도 에 입각해서 세부 사항은 숨기고 고객의 필요한 요구사항을 충족 시킬 것이라는 계약만 이루어 질 뿐입니다. 가령 계약이 기존의 이미 존재하는 시스템을 도입하여 프로그램의 세부 적인 구성을 고려하여 계약 되게 되더라도 실제 개발에서의 고객 요구 사항은 계약 내용과 상이한 점이 존재 할 수 밖에 없습니다. 그렇다고 고객의 요구를 무시하고 계약 되로 개발 할 수는 없죠? 그래서 소프트웨어 프로젝트의 개발 동안 PM 들은 계속 고객과 회사 등 프로젝트 전반에 걸쳐 이해관계가 있는 곳과 조율과 이해를 구하게 되는데 전통적인 개발 방식에서는 이 능력은 전적으로 PM의 역량에 의존하는 경향이 입니다(술로 해결하는 사람들도 많죠ㅡㅡ;;).

하지만 XP 프로세스에서는 계약과 현실의 차이를 고객이 조율하게 함으로 그 과정에 발생 할 수 있는 오해와 갈등을 이해와 화해의 수준으로 해결 하고 있습니다.
고객은 프로젝트 자원을 더 널리지 않고 범위를 가지고 변경된 요구사항을 조정하게 되며, 고객의 요구사항이 변화게 되더라도 결국 개발사의 전체적 비용은 초과 되지 않습니다. 즉 다시 계약 할 필요가 없죠(정말 이거 행복 합니다. 고객에게 추가 계약 이야기 하기는 정말 싫습니다.ㅜㅜ)
여기서 가장 중요한 것은 XP의 프로세스에서는 고객에게 가장 가치가 있는 스토리가 먼저 구현되고 프로젝트 전반에 걸쳐 다듬어 지며, 프로젝트가 완료되기 전 빠른 시간에 고객의 손에 넘어 간다는 것 입니다. 범위의 조정으로 계약 예산의 뒤쪽에 있는 즉 지정된 예산안에 처리가 되지 못하는 스토리들은 고객에게 상대적으로 먼저 수행되고 개발된 스토리보다 덜 중요한 스토리 이며, 개발사가 전체 스토리를 모두 구현하지 못하더라도 최소한의 계약 사항에 명시된 고객에게 제공해야 할 가치는 성공할 수 있는 것입니다.
전체를 망치겠습니까? 우리가 할 수 있는 중요한 몇 개라도 잘 하시겠습니까?ㅎㅎ
행복한 하루 되세요!