◈요구사항 오류
얼마 전에 대학원생들이 사용할 가구를 하나 주문했습니다. 가구업체 직원께, 제 연구실의 유리 책장(그림 1(a))의 상단 유리 부분을 가리키며, 유리 부분이 없는 장식장(그림 1(b))이 필요하다고 말씀 드렸습니다. 그 분은 금방 이해하셨고, ‘반문장(半文欌)’을 납품하겠다고 했습니다. 당시에 저는 반문장을 유리로 된 윗부분이 없는 아래 반쪽의 장으로 이해하였고, 자세한 문의 없이 계약을 진행하였습니다. 하지만, 납품된 반문장(그림 1(c))은 유리만 없는 온전한 책장이었습니다. 추후에 알게 되었지만, 제가 원했던 장은 ‘올문장’이라 불리는 수납장이었습니다.
이와 같은 상황은 비단 상품을 주문할 때뿐만 아니라 소프트웨어 개발 시에도 빈번하게 발생됩니다. 비용을 지불하는 고객의 의도 즉, 요구사항(Requirements)을 정확하게 파악하지 못한 채 개발이 진행되면, 추후 요구사항의 수정이 필연적으로 수반되며, 이는 결국 소프트웨어 구조의 조정이나 전반적인 재개발까지 야기하게 됩니다. 따라서, 요구사항을 체계적으로 추출하고 정리하는 일은 소프트웨어 개발 자체만큼이나 중요한 작업이라 할 수 있습니다. 아무리 완벽한 기능을 제공하는 소프트웨어를 개발했다고 할지라도, 고객이 이를 원하지 않는다면 이는 무용지물(無用之物)이 되기 때문입니다.
◈요구사항 관리란?
요구공학(Requirements Engineering)은 소프트웨어 개발에 필요한 제반 요구사항들을 체계적으로 수립(establishment)하기 위한 소프트웨어 공학(Software Engineering)의 한 분야입니다. 요구공학은 고객의 요구사항을 추출(Elicitation)하는 작업부터, 이를 분석(Analysis) 및 검증(Validation)한 후, 최종적으로 요구사항을 잘 정리(Specification)해서 저장 및 관리(Management)하는 작업까지 포함하고 있습니다. 또한, 다양한 이유로 인해 발생되는 요구사항 변경에 대한 체계적인 대처 및 관리 방안도 포함됩니다. 요즘 ‘요구사항 관리’의 중요성이 점차 강조되고 있는데, 요구사항 관리는 요구공학에서 추출된 요구사항을 직접적으로 관리하는 작업을 의미합니다. 즉, 요구사항의 ‘추출’, ‘분석’, ‘검증’을 통해 확정된 요구사항을 잘 관리하는 것이 바로 ‘요구사항 관리’입니다. 하지만, 요구사항 관리를 정확하게 파악하기 위해서는 요구공학의 제반 작업들에 대한 이해가 선결되어야 합니다. 그러면 지금부터, 요구공학의 각 작업과 기법들을 정리해 보면서, 각각이 얼마나 어렵고 복잡하고 중요한 작업이며, 얼마나 밀접하게 서로에게 영향을 미치는지 살펴보겠습니다. 여러분들은 요구사항을 잘 관리하는 것이 결코 쉬운 일이 아니라는 사실에 동감하실 수 있을 것입니다. 왜냐하면, 요구사항에 영향을 줄 수 있는 작업과 인자가 서로 복잡하게 얽혀 있기 때문입니다
◈요구공학의 핵심 작업들
요구공학은 고객이 원하는 요구사항을 추출하는 작업에서부터 시작됩니다. 요구사항은 크게 두 종류 – 사용자 요구사항과 시스템 요구사항으로 구분할 수 있습니다. 사용자 요구사항(User Requirements)은 고객이 원하는 요구사항을 정리한 것이며, 이를 만족시키기 위해서 개발될 소프트웨어가 가져야 할 요구사항이 시스템 요구사항(System Requirements)입니다. 먼저 고객이 정말로 원하는 소프트웨어가 어떤 것인가를 고객과의 충분한 의사소통을 통해 추출해야 하며, 이를 만족시키기 위하여 개발해야 할 내용들을 심도 깊은 분석을 통해 추출해냅니다. 시스템 요구사항의 추출 및 분석을 위해 사용되는 방법으로는 구조적 분석(Structural Analysis)과 객체지향 분석(Object-Oriented Analysis)이 널리 사용됩니다. 서두에 언급된 책장은 위의 사용자 요구사항을 추출하는 과정에서 오류가 발생한 것으로 해석할 수 있습니다.
추출 및 분석된 요구사항은 다양한 검증 기법을 이용하여, 정확성(Correctness), 일관성(Consistency), 완전성(Completeness), 명확성(Not Ambiguity) 등, 요구사항이 갖추어야 할 특성들을 갖추고 있는지 확인하는 단계를 거칩니다. 개발할 소프트웨어의 규모와 복잡성이 증가할수록 서로 다양하게 연관된 다수의 요구사항이 추출됩니다. 따라서, 시스템 요구사항이 사용자 요구사항을 정확하게 반영하고 있는지, 이들 간의 모순점이 없는지, 빠진 내용은 없는지, 참여하는 개인이나 기업에 따라 다르게 해석될 여지가 있는지 등을 검사해야 합니다. 이 단계는 상당한 시간과 노력이 요구되며, 불충분할 경우 추후 설계와 구현 단계에서 잦은 변경이 발생됩니다. 또한, 작은 요구사항 변경에도 소프트웨어 전체의 구조를 재조정해야 하는 경우도 다수 발생합니다.
요구사항 검증까지 완료되면, 각 기업의 자체 표준안에 따라 소프트웨어 요구사항 명세서(Software Requirements Specification: SRS)를 작성하게 됩니다. 일반적으로 기업 자체 표준안은 IEEE Std. 830-1998을 각 기업을 특징에 맞게 수정하여 개발됩니다. 작성된 요구사항 명세서는 고객과의 계약 내용의 대부분을 포함하며, 설계와 구현, 시험 등 다음 개발 단계의 기준이 되는 문서이므로, 충실하게 작성되어야 합니다. 요구사항 명세서는 요구사항 분석 단계의 마지막 산출물로서, 요구공학의 최종 결과물이 됩니다.
◈요구사항 관리의 필요성
설계 단계에서는 요구사항 분석 단계에서 확정된 요구사항을 기반으로 소프트웨어의 구조와 각 기능들을 보다 자세히 정의하게 됩니다. 하지만 다음의 두 가지 이유로 인해, 旣 확정된 요구사항이라 하더라도 개발이 완료할 때까지 지속적으로 관리되어야 합니다. 먼저, 요구사항은 고객의 뒤늦은 요청이나 불충분한 요구사항 분석 등으로 인하여 개발 과정 후반부에 변경되는 경우가 많습니다. 이 경우 우리는 어떤 요구사항이 변경되었고, 이 요구사항과 관련되어 영향을 주고 받는 요구사항이 어떤 것들이 있으며, 이미 개발된 시스템 시험 케이스는 어디를 수정해야 할지를 고민해야만 합니다. 또한, 요구사항으로부터 개발된 설계 산출물과 프로그램 코드들 중 수정된 요구사항과 직간접적으로 연관이 있어 수정이나 재개발 또는 보다 정확한 분석이 필요한 부분들을 찾아낼 수 있어야만 합니다. 요구사항 분석과 검증 기법들도 요구사항 별로 잘 정리되어 있어야만 변경된 요구사항을 대상으로 효과적인 재(再)작업을 할 수 있습니다.
요구사항이 추후에 변경되지 않더라도, 요구사항은 관리는 지속적으로 관리되어야 합니다. 왜냐하면, 개발 완료된 소프트웨어 시스템이 고객이 원하는 요구사항을 만족시키고 있다는 사실을 증명하기 위해서는, 고객과의 계약(Contract) 내용을 포함하고 있는 소프트웨어 요구사항 명세서를 기준으로, 각각의 사용자 요구사항이 어떻게 소프트웨어 시스템에 구현되었는가를 확인하는 작업이 필요합니다. 따라서, 계약서에 명시된 각각의 사용자 요구사항이 어떤 시스템 요구사항으로 구현되고, 이 내용이 설계 산출물의 어느 부분으로 설계되었으며, 이 내용은 프로그램 코드의 어느 모듈에 해당되며, 이 모듈은 어느 단위 시험 케이스(Unit Test Cases)와 시스템 시험 케이스(System Test Cases)를 통해 성공적으로 시험되었다는 사실을 명확하게 추적(Traceability)해서 보여줄 수 있어야 합니다.
지금까지 살펴본 바와 같이, 요구사항은 고객과의 계약사항 이행 여부를 확인할 수 있는 중요한 근거 자료이며, 또한 개발 전(全) 과정을 통해 지속적으로 변경되는 자료입니다. 따라서, 이의 체계적인 관리는 프로젝트의 성공을 판가름하는 중요한 요소 중의 하나입니다. 요구사항을 체계적으로 관리하기 위해서는 요구사항을 잘 정리하여 저장 및 보관하는 일뿐만 아니라, 요구공학의 제반 작업(추출, 분석, 검증, 명세 등)과 개발 프로세스 상의 모든 작업(설계, 구현, 시험 등)의 산출물을 효과적으로 연계하여 관리할 수 있어야 합니다. 하지만, 이들은 모두 복잡하게 연관되어 있어, 개발자가 노트에 적어 놓고 항상 염두에 두고 있는 것만으로는 결코 효과적으로 관리될 수 없습니다. 효과적이고 체계적인 요구사항 관리를 위해서는 자동화된 요구사항 관리도구를 사용하는 것이 최선책입니다.
◈해결책 = 요구사항 관리도구?
하지만, 자동화된 요구사항 관리도구가 요구사항의 체계적인 관리를 위한 절대적인 해결책은 아닙니다. 요구사항 관리는 여러 소프트웨어공학 분야 중에서도 상당히 고급(Advanced) 기술에 속하는, 소프트웨어 공학과 요구공학의 제반 기술들에 대한 전반적인 이해를 갖추고 있어야만 적용할 수 있는 기술입니다. 요구공학의 측면에서 보면, 요구사항의 추출, 분석, 검증, 명세 등의 모든 작업들이 개별적으로 효과적으로 수행되고 있을 때에야 비로소 이들간의 연관관계를 분석할 수 있는 관리 기능을 적용할 수 있습니다. 아직 요구사항을 분석하기 위한 방법론과 프로세스가 정립되어 있지 않고, 요구사항 명세서도 회사의 실정에 맞게 수정(Tailoring)되어 있지 않은 상태에서는, 즉 아직 성숙되지 않은 단계에서는 아무리 좋은 관리도구와 이를 사용할 수 있는 관리 프로세스를 제공하고, 이를 운영할 수 있는 인력 교육을 실시한다 하더라도, 모두 사상누각(沙上樓閣) 입니다. 또한, 요구사항 관리의 범위는 최종적으로는 설계, 구현 프로그램, 시험 케이스까지 이르게 되므로, 개발 과정 전반에 대한 체계적인 개발 및 관리 체계가 이미 수립되고 성공적으로 운영되고 있어야만, 요구사항 관리를 적용할 수 있습니다.
세 바퀴의 자전거(그림 2(a))를 타는 어린 아이에게 좋은 경주용 자전거(그림 2(b))와 훌륭한 선생님 및 쾌적한 연습 공간 등 최선의 지원을 제공한다 할지라도, 그 아이는 그 어른 자전거를 잘 탈 수가 없을 것입니다. 왜냐하면, 그 자전거의 패들에 발이 닿지도 않을 뿐만 아니라, 그 아이는 그 어른용 자전거를 타야 할 필요성을 전혀 느끼지 못하기 때문입니다. 지금의 세발 자전거로도 충분히 행복하게 잘 지내고 있습니다. 하지만, 그 세발 자전거를 타던 어린 아이도, 시간이 지나 키가 더 크고, 자신의 옆을 빠르게 지나가는 커다란 자전거가 점차 눈에 들어오며, 자신의 자전거로는 그 자전거를 절대로 따라 잡을 수 없다는 사실을 인지하기 시작하면, 아직 키가 작음에도 불구하고 커다란 어른용 자전거를 사달라고 부모님을 조를 것입니다. 또한, 굳이 자전거 전용 도로에 데려다 주고 좋은 선생님을 소개시켜 주지 않더라도, 시행착오를 거쳐서 스스로 잘 타게 될 것입니다. 왜냐하면, 그 아이는 그 자전거를 정말 잘 타고 싶어하기 때문입니다.
◈맺음말
내용을 정리하겠습니다. 요구사항 관리는 특별한 - 고도의 학문적인 지식이 요구되는 기술은 아닙니다. 복잡한 대규모의 소프트웨어를 개발하다 보니 요구사항을 이렇게 관리해야만 하겠다는 경험으로부터 시작된 관리 기술이며, 그 해결책은 자동화된 관리도구를 사용하자는 것입니다. 요구사항 관리도구를 잘 사용해서 요구사항이 체계적으로 관리된다면, 프로젝트의 개발 비용과 노력이 획기적으로 감소될 것입니다. 하지만, 요구사항 관리도구를 사용해서 요구사항을 관리하기 위해서는, 먼저 이를 적용할 수 있는 수준이 되어야 합니다. 개발팀에서 소프트웨어 공학에 대한 공감대가 형성되고, 개발 프로세스의 성숙도가 일정 단계 이상으로 유지되면, 요구사항 관리는 관리자(Manager)가 개발자를 통제(Control)하기 위해서 사용하는 도구가 아니라, 개발자(Developer)의 필요에 의해서 자발적으로 사용되는 유용한 지원 도구가 될 것입니다.
건국대학교 유준범 교수 jbyoo@konkuk.ac.kr