요구사항 정의 및 관리 솔루션 소개

작은 잔에 한 번에 마시는 진한 에스프레소를 즐겨 마시나요? 너무 쓰고 진하다구요?

고온 고압증기로 순식간에 커피를 뽑아 먹는 에스프레스식 커피가 유행한지 10여년 밖에 지나지 않았지만 많은 사람들이 다양한 방식으로 즐기고 있다. 물론 최근에는 된장녀의 필수항목(?)으로 휘말려 고충을 겪기도 한 특이한 경력을 가지고 있기도 하다.

얼마전 우연히 삼성경제연구소에서 제작한 “에스프레소 이야기”를 본적이 있다. 대부분의 사람들이 진하고 맛이 쓴 에스프레소를 좋아하진 않는다. 대신 취향에 따라 아메리카노(에스프레소+뜨거운 물), 카푸치노(에스프레소+우유거품+계피가루), 카페모카(에스프레소+스팀밀크+초코시럽), 카페라테(에스프레소+스팀밀크), 마끼아토(에스프레소+스팀밀크+우유거품)등을 즐기고 있다.

그러나 대부분 모든 커피의 기본이 에스프레소라는 사실을 잊고 지내고 있다. 이 광고를 통해 우리 자신의 삶과, 조직사회에서의 에스프레소가 무엇인가를 생각해 보다 필자가 10여년간 몸담아 왔던 시스템 개발 프로세스에 있어서 에스프레소가 무엇일까 곰곰히 생각해 보았다.

◆시스템 개발 프로젝트에 있어서 에스프레소

필자는 감히 시스템 개발에 있어서의 에스프레소는 요구사항 공학이라고 단언하며 이 지면을 빌어 요구사항 정의 및 관리프로세스를 효과적으로 지원하는 IBM Rational 솔루션를 소개하고자 한다.

자주 국방을 위한 무기개발 프로젝트나 자동차, 휴대폰, 네비게이트 등과 같은 제품개발 프로젝트, SI업체들의 시스템통합 개발 프로젝트 등과 같이 모든 개발프로젝트의 시작은 고객 및 다양한 이해당사자들의 요구사항들의 수집으로부터 시작하게 된다.

고객의 원하는 바를 정확히 이해하고 이를 모든 프로젝트 관련 사람들과 공유하며 각자가 해야하는 업무가 최종적으로 고객의 어떤 요구사항을 만족하기 위한 일인지 명확히 인식하며 개발할 수 있는 환경을 만들 수 있다면 수 많은 프로젝트의 실패를 성공으로 돌릴 수 있을 것이라 확신한다.

여기서 잠깐, 무엇이 프로젝트의 성공인가에 대해 살펴보자. 많은 사람들이 프로젝트의 3대요소로 납기(Schedule), 비용(Cost), 품질(Quality)을 말한다. 고객은 원하는 시점에 저렴한 가격으로 현재의 문제점을 해결할 수 있는 고품질의 제품을 원하며 이를 공급자는 최대한 경쟁사에 비해 빠른 시간내에 저 비용으로 제품개발을 하려고 노력하고 있다. 결국 성공이라는 핵심열쇠는 고객의 요구사항을 얼마나 신속하고 정확하게 만족시키는가에 달려있다. 품질을 예로 생각해 보자. 많은 개발자들은 이를 기술적인 이슈로만 생각하는 경향이 있다. 즉 구현한 기술에 대한 신뢰성과 내구성, 유지보수성등을 고려해서 개발하려고 밤낮없이 노력한다.

그러나 이러한 기술적 부분을 충족시킨다 하더라도 구현된 기술이 고객이 원하는 부분을 해결해 주지 못 하는 경우 과연 고객이 해당제품을 고품질이라고 느낄 수 있을까? Crosby라는 사람은 요구사항에 얼마나 잘 부합되는 정도(Conformance to requirement)를 품질로 정의했다. 고객의 만족도가 높고 품질이 높다는 것은 최소한 고객의 모든 핵심 요구사항이 시스템 내에 구현된 시스템을 일컷는 것이다. 앞선 기술력으로 시장을 창출하고 선도하는 몇몇 제품의 경우를 예외로 제외한다면, 대부분 고객이 원하는 제품을 적시에 공급할 수 있는 업체가 시장에서 살아남는 강한 기업이 될것이다.

◆최상의 도구가 문서편집기?

필자는 2000년 초반 부터 국내의 요구사항 관리 분야의 솔루션인 Rational DOORS를 소개하면서 많은 기업체들과 함께 프로젝트를 수행해 왔다. 전 세계적으로 가장 시장 점유율(37.1%, Gartner Dataquest, 2007) 이 높고 많은 성공적인 국내외 구축사례를 가진 도구였지만, 처음 도구를 국내에 도입했을 때 반응은 한마디로 차가웠었다.

요구사항관리요? 중요하지요. 하지만 우린 개발하는 데 시간이 쫒겨 도저히 요구사항 관리를 할 시간이 없습니다. 또는 우린 관리할 요구사항이 많지 않습니다 등과 같이 그들만의 합리적인 이유를 가지고 있었다. 그 중 아직도 기억나는 재미난 이유중 하나가 개발자는 고객의 요구사항이 불명확할 수록, 그리고 요구사항 명세서를 작성하지 않고 개발하는 경우가 개발하기 훨씬 쉽다는 답변이었다. 고객의 요구사항이 애매모호할 수록 개발자가 편한 방식으로 개발할 수 있으며 납품이 쉽다는 논리였던 것으로 기억한다.

예전과 마찬가지로 현재 요구사항 관리를 위해 가장 많이 사용하고있는 도구는 워드프로세스나 스프레드시트이다. 이 도구는 구매 비용이 저렴하고, 별도의 교육이 필요하지 않는 익숙한 도구이며 회사가 요구하는 양식대로 문서를 생성할 수 있다는 장점을 가지고 있다. 하지만 문서단위의 버전관리를 위해 별도의 도구가 필요하며, 개발 문서내 단위 요구사항 별로 이력관리, 추적 변경관리를 효과적으로 할 수 없으며 개발자들이 협업해서 동시에 작성하고 검토할 수 있는 기능을 가지고 있지 않다. 요구사항 관리를 제대로 하지 않았을 때의 예상결과(프로젝트의 지연, 재작업 및 실패)를 고려한다면 요구사항 관리 도구의 투자는 매우 수익성이 높은 투자로 생각할 수 있다.

◆네비게이터와 요구사항 공학 도구

업무 특성상 출장이 잦은 사람이나 새로운 곳으로 여행을 좋아하는 사람들은 네비게이터의 효용 가치를 잘 알고 있다. 생전 처음 가는 곳이라도 출발지와 최종 목적지를 입력하면 최단 경로 및 원하는 도로를 경유해서 가는 최적 경로를 안내해 주기에 쉽게 목적지에 도착할 수 있다. 하지만 네비게이터가 없는 경우는 어떻게 해야 할까? 한가지 생각할 수 있는 시나리오는 먼저 인터넷에서 지도를 검색해서 찾아가는 방법을 생각할 수 있다. 이 경우 작게는 30분에서 1시간 이상을 출발하기 전 사전 준비를 해야만 한다. 또한 중간에 길을 잘못들어 헤메는 경우를 대비해서 충분한 시간 여유를 가지고 떠나야만 하며, 목적지에 늦게 도착할 수 있는 위험과 운전시 출력한 지도를 확인하는 과정으로 인한 사고의 위험 역시 상대적으로 크다. 사전 준비에 들어가는 시간만을 비용으로 환산해 봐도 일정기간 후에는 네비게이터 구매 비용대비 이익이 발생하게 됨은 분명하다.

요구사항 관리는 프로젝트 개발에 있어서의 네비게이터이다. 고객의 요구사항은 프로젝트에 있어 도달해야하는 최종 목적지로 가는 도로가 표시된 지도에 비유할 수 있다, 요구사항 관리는 진행도중 수시로 프로젝트가 잘못된 길로 접어들었을 때나, 또는 요구사항의 변경으로 인한 프로젝트 진행의 수정이 필요할 때 진로수정 및 방향을 올바로 잡는 네비게이터(나침반)의 역할을 한다.

2003년 Standish 그룹이 조사한 자료에 의하면 IT 프로젝트의 실패로 인해 낭비된 비용이 450조원이 넘는 것으로 조사되었으며 실패요인의 50%이상이 요구사항관련 부분에 기인하는 것으로 조사되었다. 요구사항 관리가 만병통치약은 아니지만 적어도 하지않았을 때 미치는 엄청난 결과는 이미 역사적(?) 사실이 입증하고 있다.

◆요구사항 정의도구 Rational Requirement Composer

최근에 IBM Rational에서는 요구사항을 효과적으로 수집/정의할 수 있으며, 수많은 이해당사자들과 협업할 수 있는 도구인 Rational Requirement Composer(이후 RRC)를 시장에 내 놓았다. 실제로 요구사항을 관리하기 위해서는 먼저 올바른 고객의 요구사항을 수집하는 것이 선행되어야만 한다. 많은 이해 당사자들의 요구사항들을 수집하여 이를 분류, 분석 및 검증한뒤 구조화해서 문서화하는 작업들을 효과적으로 할 수 있는 통홥환경을 제공해 주는 도구이다.

업계에 널리 알려진 모델링 기법인 BPMN을 지원하는 비지니스 프로세스 모델링, 유스케이스 다이어그램, 요구사항에 대한 Wiki스타일의 토론 기능, 용어집, 사용자 인터페이스 설계 및 스토리보드를 지원함으로써 고객의 요구사항을 쉽게 추출하고 고객에 의한 검증/확인을 쉽게 받을 수 있다. 현업과 개발자간의 의사소통의 창구 역할을 하는 시스템 엔지니어, 요구사항 분석가, 또는 비지니스 분석가등이 주요 사용자이다. RRC를 통해 요구사항이 올바르게 정의가 되었다면 이제부터는 요구사항 관리도구인 DOORS로 통합되어 변경 및 추적/이력관리를 프로젝트의 수명주기 동안 수행해야 한다.

◆요구사항 관리 도구 Rational DOORS

요구사항 분석단계에서 고객의 요구사항이 정의되면 이를 고객과 공급자간 서로 합의한 후 이를 바탕으로 개발을 시작하게 된다. 프로젝트 시작단계에서 모든 요구사항을 식별하기도 힘들뿐만 아니라 프로젝트 기간내에 변경되지 않는 경우는 거의 현실에선 볼 수 없다. 요구사항을 정의했다면 이제는 프로젝트 수명주기동안 이를 추적/변경관리해야 하며 각 단계마다 모든 요구사항이 다음 단계의 산출물 또는 설계에 반영되었는지 확인하는 과정이 필수적으로 수행되어야 한다.

현재 국내외 많은 기업들 - 국방 및 우주 항공, IT 제조업, 금융, 자동차 등 - 에서 요구사항 관리도구인 DOORS를 활용하여 제품을 생산하고 있다. 각각 생산하는 제품이 다르며, 개발기간, 복잡도, 개발 방법론, 개발 기간등이 다르지만 한결같이 DOORS를 그들의 개발프로세스 산출물의 추적성 도구로 활용하고 있다는 점이 공통점이라고 볼 수 있다. 도구를 활용하여 정의된 모든 사용자 요구사항이 반영된 제품수준, 즉 시스템 수준의 사양서가 만들어졌는지를 초기 단계에서 검증하고, 시스템에 따라 서브 시스템 또는 설계서들의 단위 항목들이 시스템 사양서의 모든 단위 요구사항을 반영하는 지, 시험계획서와 시험 절차서가 모든 요구사항을 커버하는지를 확인하는 프로세스에 DOORS를 활용하고 있다.

이를 위해서는 파일 단위(산출물 단위)가 아닌 산출물 내에 존재하는 단위 요구사항 문장 단위의 추적관리가 필수적인 요소이다. 요구사항 단위의 추적성 확보를 통해 앞서 언급한 추적성 분석을 할 수 있다. 이와 더불어 항상 발생하는 최상위 요구사항의 변경에 대한 기존의 개발 단계에서 미치는 영향도를 분석하는 영향 분석(Top-down 분석)과 개발자들의 설계 변경이 고객의 요구사항에 영향을 줄 수있는 변경(Bottom-up 분석)인지 아닌지를 실제 변경하기 이전에 먼저 분석하는 작업을 가능하게 해 준다.

이 모든 작업은 추적성 확보없이는 불가능하며, Rational DOORS를 활용하는 경우에는 Drag & Drop 방식으로 아주 손쉽게 추적성을 확보할 수 있으며, IEEE, Mil-Standard 등 시스템 개발 표준에서 제시하는 프로젝트 산출물에 반드시 포함시켜야 하는 상호추적표를 자동으로 생성할 수 있는 기능을 제공하고 있다. 한 번이라도 워드프로세스로 요구사항 명세서를 만들때 단위 요구사항에 유일한 식별번호를 수작업으로 부여하고 요구사항간에 추적표를 작성한 뒤 지속적으로 배포/관리를 해 본 경험이 있는 개발자들은 요구사항관리 자체를 개발시간을 갉아 먹는 행위로 오해를 하게 된다.

◆조직내의 성공적인 도구의 적용 방안

도구라는 것은 어디까지나 도구일 뿐이다. 도구가 프로세스를 대체할 순 없다. 회사마다 서로 다른 개발 환경을 가지고 있으며, 따라야 하는 규칙들이 정해져 있다. IBM Rational은 고객의 문제의 해결을 위한 솔루션을 제공하는 업체이다. 단순한 도구만을 공급하는 단계를 뛰어넘어 고객이 가지고 있는 고유한 이슈를 식별하고 그들의 환경에 적합하게 도구를 효과적으로 적용할 수 있는 서비스를 함께 제공하고 있다.

SI 프로젝트의 성공여부는 고객의 최종 승인으로, 제품개발 프로젝트 역시 제품에 대한 시장의 선택 즉 고객에 의해 결정된다. 고객의 요구사항을 정확히 파악하고 이를 효과적으로 관리하는 것이 프로젝트의 핵심 성공요소이다. 마지막으로 다음과 같은 말로 이 글을 맺고자 한다. 요구사항 분석 단계와 관리시간에 아낀 시간은 프로젝트 재작업에 고스란히 들어감을 모든 프로젝트 관련자들은 명심해야 할 것이다.

IBM 래쇼날 컨설턴트 김대승 부장