Key Issues in Requirements Reuse

사실 요구사항 재사용이란 말은 아주 유용해 보이지만, 실제로 요구사항을 재사용함으로써 얻을 수 있는 장점은 그리 크지 않다고 생각한다. 특히 자체개발 조직에서 요구사항의 재사용은 애자일 프로세스를 도입하는 경우 거의 무용지물이 된다고 볼 수 있으며 또한 개발 성숙도가 낮은 조직에서의 요구사항 재사용은 사실상 요구사항을 신규로 작성하는 것의 생산성과 비교 했을때 큰 차이가 없다고 생각한다. (물론 개인적 생각이다.)

나름의 근거를 대자면, 

1. 자체 개발 조직에서의 요구사항 재사용 문제점
자체 개발 조직은 요구사항과 설계, 그리고 모델로 이어지는 프로세스가 애자일로 돌아가야 하는 상황에 놓이기 쉽다. 이는 자체개발 조직의 목적과도 부합된다고 볼 수 있는데, 예를 들면, 외주 개발로 소프트웨어 개발이 이루어지는 경우, 여러 이해관계자간 의사 소통 및 수정을 수반하는 일련의 프로세스가 증가하게 되고, 이로 인해 차라리 복잡한 이해 관계자 구조를 축소하고, 내부 전문가들을 중심으로 개발 중심의 애자일 프로세스를 도입하는 것이 생산성 측면에서 훨씬 효과적이라고 판단할 수 있다. 따라서 자체 개발 조직의 경우 애자일 프로세스 중심이 되는 것이 자연스런 현상이라 볼 수 있는데, 이 경우 이미 이해관계자 스스로가 개발의 역할도 함께 수행하기 때문에 요구사항 재사용 자체의 필요성이 상당부분 감소할 수 있다고 생각된다. 

2. 개발 성숙도가 낮은 조직에서의 요구사항 재사용 문제점
안타까운 현실이겠지만, 개발 성숙도가 낮은 조직은 요구사항 재사용 자체의 필요성을 인지 하지 못한다. 대부분의 저수준 성숙도를 갖는 조직은 요구사항 자체가 존재하지 않기 때문에, 개발의 역량과 이해관계자의 일부 의사소통에 근거한 요구사항 - 대부분 문서화되지 않은 요구사항들을 중심으로 개발이 이루어지게 되고, 이로 인해 개발 프로세스 후반부에서 상당수의 개발 공수와 품질 비용을 야기하게 되는 전형적인 저수준의 개발 조직의 문제점을 내재하게 된다. 따라서 이런 조직에서는 요구사항 재사용 자체의 주제가 무의미 해 지는 경우 또는 선언적인 형태로만 존재하는 경우가 많다고 생각된다.

그럼에도 불구하고 요구사항의 재사용은 생산성이나 품질 관점에서 중요한 행위 중의 하나이며, 실제로 다수의 요구사항 변경을 수반하는 프로젝트에서는 매우 중요한 고려사항 중 하나임에는 틀림없다. 앞에서 말한 요구사항 재사용에 대한 무용론은 현재 본인이 처한 상황에 한정된 매우 지협적인 요인에 기인한 것임을 밝히고 싶다. 

참고문헌에 언급된 바와 같이 요구사항 재사용에 있어 다음과 같은 주요 이슈들이 존재 한다.

1. 재사용 요구사항에 대한 구성을 어떻게 할 것인가?
요구사항 재사용을 위해 어떻게 요구사항을 구성할 것인가는 매우 중요한 문제이다. 이러한 요구사항 구성이 적절하지 않은 경우, 요구사항 재사용이 지속 될 수록 점점 재사용을 어렵게 하는 요인이 된다. 또한 시간이 지날 수록 늘어나는 요구사항을 제대로 관리 할 수 없게 됨에 따라, 최악의 경우 요구사항 재사용 자체가 불가능 해 지는 상황이 이루어질 수 있다.
이를 위해 재사용을 고려한 요구사항들은 기능적 구분, 각 기능에 대한 상호 연관성을 고려하여 도메인에 따른 분류, 상태에 따른 분류 등을 이용하여 요구사항이 독립적으로 재사용 가능하도록 Orthogonality를 확보하는 것이 필요하다고 생각한다.

2. 재사용 가능한 요구사항은 어떻게 검색할 것인가?
당연한 이야기겠지만, 요구사항 재사용은 기존 요구사항들 중 하나를 선택하는 과정을 수반한다. 따라서 요구사항 재사용을 위해서는 기존 요구사항을 어떻게 검색하고 선택할 것인가에 대한 고민이 필요하다.
각 요구사항별로 태깅을 통한 검색 기법도 있을 것이고, 앞에서 정의된 구성에 따른 요구사항을 검색할 수도 있을 것이고, 다양한 방법이 존재할 것이다. 
하지만, 대부분의 경우 요구사항은 특정 벤더의 요구사항 도구를 사용하고 있을 것이 자명하기 때문에, 이런 경우, 해당 요구사항 도구를 통한 검색이 어느정도의 문제점을 해결하는 방안이 될 수 있다고 생각한다. 따라서 여기서는 재사용 가능한 요구사항 검색 자체보다는 어떤 벤더의 도구를 선택하고, 어떻게 요구사항 구조를 가져가느냐가 선행된다면 어느정도의 문제는 해결될 수 있는 이슈가 아닐까 생각한다.

3. 재사용을 위한 요구사항 선택과 다른 수준의 상세도를 갖는 요구사항들의 재사용에 관한 문제
요구사항 관련 이슈 중 상세도(granularity)의 문제는 요구사항 식별 및 작성과 관련하여 별도의 이슈가 될 수 있다. 그럼에도불구하고 재사용 관점에서도 하나의 이슈가 될 수 있는데, 예를 들어 재사용하고자 하는 요구사항은 하나의 동일 수준의 상세도를 갖는 요구사항일 수도 있겠지만, 그렇지 않고, 다른 요구사항의 부분으로 파편화되어 상세화된 내용일 수도 있으며, 이는 최종적으로 파편화된 요구사항들이 하나의 완전한 요구사항으로 재구성되거나 개선/수정될 수 있어야 하는데, 공교롭게도 요구사항 재사용시, 이렇게 파편들로 구성된(여러 부분집합으로 구성된) 요구사항과 대응되는 경우, 어떤 요구사항들을 재사용해야 할 것인지에 대한 이슈가 대두될 수 있다.
대부분의 경우, 이런 서로 다른 상세화를 갖는 요구사항들은 특별한 경우, 즉 특정 프로젝트에서만 유의미한 경우가 다수일 확률이 높다. 기존 요구사항과 달리 특정 프로젝트에서 여러 제약사항들이 추가됨에 따라 보다 상세한 수준의 상세도로 구분되어 작성될 수 있기 때문이다.
개인적 견해를 밝히면, 이 경우 이러한 요구사항들은 별도의 alternative로 구분하여 관리 할 수 있어야 한다고 생각한다. 그렇게 되면 요구사항 관리의 노력이 추가될 수 있겠지만, 이는 적절한 요구사항 리뷰 활동을 통해 수시로 관리하는 수 외에는 방법이 없다고 생각한다.

4. 요구사항 속성의 재사용은 어떻게 할 것인가?
일반적으로 요구사항은 일종의 메타데이터로 속성(attribute)을 정의하게 되고, 요구사항 재사용시, 이러한 속성들 또한 재사용되는 것이 당연하다. 그러나 재사용의 상황에 따라 요구사항 속성은 다른 형태로 정의/추가/변경되는 상황이 발생할 수 있다. 따라서 요구사항 관리자는 재사용 시점에 이러한 속성들을 수정할 수 있어야 한다.
결과적으로 초기 요구사항 속성에서는 재사용을 염두에 두고 최소한의 속성 집합(Common Set of Attributes)으로 정의되어야 한다. 그리고 재사용 시점에 이들 요구사항 속성이 업데이트 되거나 추가되어 상황에 맞도록 요구사항 속성들이 정의될 필요가 있다.

5. 재사용에 따른 관계들은 어떻게 추적성을 확보 할 것인가?
참고문헌에 따르면 요구사항들은 타 요구사항들과 다양한 관계를 가지고 추적성을 확보하게 되며, 이러한 관계들에 대한 taxonomy를 소개하고 있다. 또한 비교적 간결한 관계들을 추적성 관점에서 정의하고 있다.

(1) Inclusive Relationship (Inclusive Traceability Relationships)
두개의 요구사항 A와 B 사이에 맺어지는 관계로 만족(Satisfy) 관계로 표현될 수 있다. 즉, A를 만족하기 위해서는 B도 만족되어야 한다. 따라서 A를 재사용하게 되면 묵시적으로 B도 함께 재사용되어야 한다는 의미로 해석할 수 있다.

(2) Parent-Children Relationship
요구사항간 관계가 상/하위 요구사항으로 구분될 수 있으며, 상위 요구사항(Parent)은 여러개의 하위 요구사항(Child)으로 구성될 수 있다. 이러한 구조는 요구사항 개발 프로세스의 초기 단계에서는 상위의 추상적 요구사항 즉, Partent 요구사항으로 정의하고, 하위 요구사항 즉, Child는 개발 프로세스간 반복(iteration)을 통해 개선(refine) 또는 상세화될 수 있다는 장점을 갖는다. 
그러나 개발 수준에 따라 상세도의 차이를 갖게되며, 이는 요구사항 관리 상 중요한 관리 항목이 될 수 있기 때문에 많은 신경이 쓰이는 사항이기도 하다.

(3) Exclusive Traceability Relationship
요구사항들이 상호 배타적인 경우에 정의될 수 있다. 이러한 상호 배타적인 요구사항 관계는 일관성에 의한 위험을 낮출 수 있는 중요한 요소가 된다. 

6. 파라미터화 된 요구사항 관리는 어떻게 할 것인가?
파라미터화 된 요구사항이란 여러 의미로 해석될 수 있겠지만 하나의 요구사항 작성에 있어 사전에 정의된 파라미터들을 기반으로 작성하게 함으로써, 요구사항에서 일관성, 상세화 수준 등에 의해 기인되는 여러가지 문제들을 해결할 수 있도록 해 준다. 
개인적으로 아주 훌륭한 개념이라 생각되지만, 이를 위해 사전에 정의된 파라미터, 요구사항 엔지니어들에 대한 교육 등 전제 조건들이 견고하게 정리되어야 그 진가를 발휘할 수 있다고 생각한다. 반면, 이렇게 파라미터화된 요구사항 관리는 요구사항 재사용의 관점에서는 아주 유용할 수 있닫고 생각한다. 즉, 파라미터들을 재사용할 수 있도록 설정하면 되기 때문이다.

7. 요구사항 저장소에 대한 개선은 어떻게 할 것인가?
사실, 요구사항 저장소는 실제 업체에서는 잘 알려진 CARE (Computer Aided Requirements Engineering) 도구를 사용하고 있기 때문에 별도의 문제가 될 수 있다. 따라서 큰 이슈라고 생각하지는 않는다.

8. 요구사항 재사용을 위한 도구는 어떻게 구성할 것인가?
요구사항 재사용을 위한 도구또한 요구사항 저장소와 마찬가지로 실제 업에에서는 잘 알려진 CARE 도구를 사용하고 있기 때문에 별도의 문제가 될 수 있다. 따라서 큰 이슈라고 생각하지 않는다. 

 

주: 본 posting은 참고문헌을 바탕으로 작성자의 개인적 견해를 적은 글로서, 무단 복제를 금지합니다. 

Reference
Ambrosio Toval, Begona Moros Valle, Joaquin Nicolas, Joaquin Lasheras, "Eight Key Issues for an Effiective Reuse-Based Requirements Process", Computer Systems Science and Enbineering, Nov. 2008