Requirements Management

요구사항 관리는 목적 제품과 구성요소들의 요구사항이 프로젝트의 계획과 제품에 맞게 유지되도록 관리하기 위한 CMMI의 프로세스 영역이다. 성숙도Maturity를 기준으로 두번째 단계에 해당하며, 프로젝트에서 만들어지거나 사전에 전달받은 요구사항 전체를 관리하는 영역의 프로세스다.

Pressman은 요구사항 공학Requirements Engineering을 일곱 가지 태스크로 구분하는데, 그 중 마지막 태스크가 바로 요구사항 관리다¹. 요구사항 관리는 프로젝트가 진행되는 동안 요구사항과 그 변경 사항을 식별, 통제, 추적하는 일련의 활동으로, 이 활동 중 상당수는 소프트웨어 형상 관리의 기법과 동일하다 (Pressman & Maxim, 2020, Ch.7). 요구사항 관리 프로세스들이 관리하는 요구사항에는 기술적인 요구사항²과 기술적이지 않은 요구사항까지 모두 포함되며, 심지어 조직에 의해 할당된 요구사항들까지 포함된다. 특히 만약 요구사항 개발 프로세스가 잡혀 있다면, 그 프로세스는 제품과 그 구성요소에 대한 요구사항도 만들 것이고 그 또한 요구사항 관리 프로세스에 의해 관리될 것이다.

주요 목표

CMMI의 모든 프로세스 영역에는 특정한 목표Specific Goal, SG가 있고, 그 목표를 이루기 위한 특정 프랙티스Specific Practice, SP가 있다. 요구사항 관리의 목표는 단 하나, 요구사항을 관리하는 것이다. 이를 위해 SP 1.1부터 SP 1.5까지 총 5개의 프랙티스가 주어지는데, 이들의 관계는 아래 다이아그램과 같다.

Understand Requirements

우선 첫번째 프랙티스는 요구사항을 이해하는 것Understand Requirements이다. 요구사항을 이해하기 위해서는 요구사항을 제공하는 측과의 합의가 이루어져 있어야 한다. 요구사항이 자꾸 추가되는 일Requirements Creep을 피하기 위해 요구사항을 받을 채널을 명확히 설정하도록 평가 기준을 확립해야 하고, 각 요구사항이 무엇을 의미하는지에 대하여 요구사항을 받는 쪽과 주는 쪽이 충분한 대화를 거쳐 공통된 이해에 도달해야 한다. 평가 기준으로는 명료함, 완전함, 고유함, 검증 가능성, 추적 가능성, 비즈니스 가치와의 연결 등을 꼽을 수 있겠다.

만약 이러한 평가와 수용 기준이 마련되어 있지 않다면 요구사항을 충분히 확정짓지 못하거나, 추가 비용을 들여 다시 작업해야 할 수도 있고, 고객이 최종 제품을 거부할 수도 있다.

Obtain Commitment to Requirements

다음 프랙티스는 요구사항을 구현하는 프로젝트 참여자들Project Participants에 대한 것이다. 프로젝트 참여자들이 실질적으로 요구사항을 현실로 옮기는 사람들이기 때문에, 요구사항이 변하거나 새로 만들어질 때 그들에게 끼치는 영향을 고려할 필요가 있다. 프로젝트 참여자들이 새로운 요구사항이나 기존의 요구사항의 변화에 대응하기 전에 그들이 하는 일에 변화를 줄 때 충분한 합의가 필요하고, 프로젝트 참여자들이 이미 지난 요구사항이 아닌 현재의 요구사항을 구현하도록 보장해야 한다.

Manage Requirements Changes

세번째 프랙티스는 프로젝트에 요구사항을 구현해 가는 상황에서 필요한 프랙티스다. 개발 과정에서 고객의 요구가 변하거나 기술이 발전하고 표준이 변하는 등 다양한 이유로 요구사항이 도중에 변하기 때문에 이를 위해서 여러가지 일을 하게 된다. 프로젝트에 대하여 모든 요구사항과 그 변화를 문서로 남기고, 요구사항이 변화해온 기록을 그 근본적 이유와 함께 보존하고, 이해관계자의 입장에서 요구사항의 변화가 어떤 결과를 가져올지 평가해보고³, 요구사항과 데이터를 프로젝트에서 이용할 수 있도록 조정하는 일이 여기에 해당된다.

Maintain Bidirectional Traceability of Requirements

네번째 프랙티스는 요구사항과 작업물이 양방향으로 서로를 추적할 수 있는 상태Bidirectional Traceability를 유지하기 위한 프랙티스다. 추적성Traceability에는 여러가지 방향⁴이 있는데, 요구사항에서 출발해 설계, 구현, 테스트까지 관계를 수립하는 방향이 순방향 추적성Forward Traceability이고, 테스트에서 출발해 구현, 설계, 요구사항의 순서로 관계를 수립해 출처를 밝히는 방향이 역방향 추적성Backward Traceability이다. 이러한 추적성은 요구사항의 변화가 프로젝트 활동과 작업물에 가져오는 영향을 평가할 때 특히 필요하다.

실무에서는 추적성 매트릭스Traceability Matrix를 활용하여 이 관계를 가시화한다. 행에는 요구사항의 이름을, 열에는 소프트웨어 공학 산출물(설계 요소, 테스트 케이스 등)의 이름을 배치하고, 둘 사이에 링크가 존재하면 해당 셀을 표시하는 방식이다⁵. 요구사항과 산출물의 수가 늘어날수록 매트릭스를 최신 상태로 유지하기가 어려워지지만, 요구사항의 영향과 진화를 추적하는 수단을 마련하는 것은 반드시 필요하다 (Pressman & Maxim, 2020, Ch.7).

Ensure Alignment Between Project Work and Requirements

마지막 프랙티스는 프로젝트의 계획과 실제 작업 중인 제품이 요구사항과 나란히 가도록aligned with requirements 설정하는 것이다. 만약 요구사항과 프로젝트의 계획, 그리고 실제 제품의 방향이 나란하지 않고 어긋나 있다면 교정해줄 필요가 있다. 이를 위해 네가지 하위 프랙티스가 권장된다.

1. 프로젝트 계획, 활동, 그리고 작업물을 리뷰할 것. 이는 요구사항과 요구사항의 변화를 실제 구현이 계속 따라가도록 하기 위한 것이다.
2. 만약 요구사항과 프로젝트의 계획, 그리고 실제 제품의 방향이 나란하지 않고 어긋나 있다면 그 원인을 찾을 것.
3. 요구사항이 변화함에 따라 프로젝트의 계획이나 실제 작업물에 어떤 변화가 필요한지 파악할 것.
4. 앞서 설명한 맥락 안에서 고쳐야 할 것이 있다면 고칠 것.

마무리

요구사항 관리는 CMMI 성숙도 레벨 2의 프로세스 영역으로, 소프트웨어 프로젝트의 토대를 형성한다. 다섯 가지 프랙티스는 요구사항의 이해에서 출발하여 참여자 합의, 변경 관리, 양방향 추적성, 그리고 프로젝트 정렬까지 일관된 흐름을 이룬다.

Pressman이 강조하듯이, 요구사항은 변한다. 그리고 변경에 대한 욕구는 시스템의 전 생명주기에 걸쳐 지속된다 (Pressman & Maxim, 2020, Ch.7). 따라서 요구사항 관리는 일회성 활동이 아니라 프로젝트 전체를 관통하는 지속적인 활동이며, 형상 관리와 밀접하게 연결된다. 요구사항 개발이 "무엇을 만들 것인가"를 정의한다면, 요구사항 관리는 "정의된 것이 끝까지 유효하게 유지되는가"를 보장하는 역할을 한다. 이 둘은 서로를 보완하며, 테스팅의 기반이 되는 검증 가능하고 추적 가능한 요구사항을 프로젝트에 제공한다.

---

출처

• CMMI-DEV 1.3. CMMI for Development, Version 1.3. Software Engineering Institute. Requirements Management (REQM) Process Area.
• Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. Ch.7.
• ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering.
• Wiegers, K. E., & Beatty, J. (2013). Software Requirements (3rd ed.). Microsoft Press.

---

Footnotes

1. Pressman이 제시하는 요구사항 공학의 일곱 가지 태스크: 착수Inception, 도출Elicitation, 정교화Elaboration, 협상Negotiation, 명세Specification, 검증Validation, 관리Management. 이 태스크들은 경계가 명확하지 않으며 일부는 병렬로 수행된다 (Pressman & Maxim, 2020, p.104). ↩

2. 기술적인 요구사항Technical requirements이란, 제품이나 서비스가 갖춰야 하는 특성을 의미한다. ↩

3. 특히, 제품의 아키텍처를 바꾸는 요구사항 변화는 수많은 이해관계자에게 영향을 끼칠 수 있다. ↩

4. 사실 추적성은 순방향, 역방향뿐만 아니라 수직 추적성Vertical Traceability과 수평 추적성Horizontal Traceability도 있다. 수직 추적성은 고객 니즈, 시스템 요구사항, 설계, 구현, 테스트 간 관계를 수립하는 것이고, 수평 추적성은 요구사항 간, 모듈 간 등 같은 단위 사이의 관계를 수립하는 것이다. 하지만 이번 글에서는 깊이 다룰 필요가 없어 순방향과 역방향 두 가지만 적었다. ↩

5. 추적성 매트릭스Traceability Matrix는 사용하는 프로세스 모델에 관계없이 프로젝트가 한 단계에서 다음 단계로 이동할 때 연속성을 제공한다. 또한 모든 요구사항이 공학 산출물에 반영되었는지 확인하는 수단으로도 활용된다 (Pressman & Maxim, 2020, p.110). ↩