요구사항 추적 매트릭스

1. 개요

요구사항 추적 매트릭스(Requirements Traceability Matrix, RTM)는 소프트웨어 개발 프로젝트에서 요구사항과 그것에서 파생된 모든 산출물 간의 관계를 문서화하고 추적하는 도구이다. RTM은 특정 요구사항이 분석, 설계, 구현, 테스트 각 단계에서 어떻게 반영되었는지를明示的に追跡할 수 있게 해주며, 이를 통해 요구사항의누락이나 불일치를 조기에 발견할 수 있다.

RTM은 정보시스템 감리에서 중요한 감리 증거가 된다. 감리자는 RTM을 활용하여 요구사항이 개발 전 과정에서 적절히 반영되었는지, 변경이 발생했을 때 영향 분석이 이루어졌는지를 검증할 수 있다. 또한 RTM은 감리자가 감사 증거를 수집하는 데에도 효율적인 도구이다. 요구사항 하나를 중심으로 그것에 관련된 설계 문서, 코드, 테스트 케이스를 빠르게 찾아낼 수 있기 때문이다.

요구사항 추적성은 소프트웨어 품질 관리의 중요한 요소로, ISO/IEC 25010 품질 모델에서도 제품기반 요구사항 추적성(Product Quality Requirements-Based Traceability)이 품질 특성 중 하나로 제시되어 있다. 또한 공공부문 정보화 사업에서는「정보시스템 구축•운영 지침」에서 요구사항 추적 관리를 의무화하고 있다.

2. ASCII 다이어그램

RTM 구조 및 추적 관계

[요구사항 추적 매트릭스 구조]

┌─────────────────────────────────────────────────────────────────────┐
│                    요구사항 추적 매트릭스 (RTM)                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   ┌───────────────────────────────────────────────────────────┐    │
│   │  요구사항 ID │ 분석 │ 설계 │ 구현 │ 단위 │ 통합 │ 시스템 │ 인수 │
│   ├───────────────────────────────────────────────────────────┤    │
│   │  REQ-001   │  ✓   │  ✓   │  ✓   │  ✓   │  ✓   │  ✓   │  ✓   │  │
│   │  REQ-002   │  ✓   │  ✓   │  ✓   │  ✓   │  ✗   │  ✓   │  ✓   │  │
│   │  REQ-003   │  ✓   │  ✗   │  -   │  -   │  -   │  -   │  -   │  │
│   │  REQ-004   │  ✓   │  ✓   │  ✓   │  ✓   │  ✓   │  ✗   │  -   │  │
│   │  REQ-005   │  ✓   │  ✓   │  ✓   │  ✓   │  ✓   │  ✓   │  ✓   │  │
│   └───────────────────────────────────────────────────────────┘    │
│                                                                     │
│   [기호 설명]                                                       │
│   ✓ : 해당 단계에서 구현/테스트됨                                   │
│   ✗ : 해당 단계에서 실패/미달성                                     │
│   -  : 해당 항목에 해당되지 않음                                     │
│                                                                     │
│   [추적 방향]                                                       │
│   정향 추적 (Forward Trace): 요구사항 → 설계 → 구현 → 테스트       │
│   역방향 추적 (Backward Trace): 테스트 → 구현 → 설계 → 요구사항     │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

추적 관계 다이어그램

[추적 관계 흐름도]

┌───────────┐     ┌───────────┐     ┌───────────┐     ┌───────────┐
│ 요구사항   │────▶│   설계    │────▶│   구현    │────▶│  테스트   │
│(Requirements)│     │ (Design)  │     │(Code/Impl)│     │(Testing)  │
└───────────┘     └───────────┘     └───────────┘     └───────────┘
     │                                      │                  │
     │                                      │                  │
     │◀─────────────────────────────────────┘                  │
     │                                                         │
     │   [역방향 추적: 상위 산출물로의 추적]                      │
     │   Test → Implementation → Design → Requirements        │
     │                                                         │
     │   [정방향 추적: 하위 산출물로의 추적]                      │
     │   Requirements → Design → Implementation → Test        │

3. 해석

3.1 RTM의 목적과 필요성

RTM은 단순한 문서가 아니라 프로젝트 관리와 품질 보증을 위한 중요한 도구이다. RTM이 필요한主な 이유는 다음과 같다.

요구사항 누락 방지: 복잡한 시스템에서 수많은 요구사항이 설계, 구현, 테스트 과정에서 누락되는 것을 방지한다. 각 요구사항이 추적 가능하도록管理되지 않으면, 일부 요구사항이 구현되지 않고 인도될 위험이 있다.

변경 영향 분석 지원: 요구사항 변경이 발생했을 때, 해당 변경이哪些 산출물과 테스트에 영향을 미치는지를迅速하게 파악할 수 있다. 이를 통해 변경管理 프로세스의 효과성을 높인다.

감리 증거 제공: 감리자에게 프로젝트가 요구사항을 체계적으로管理하고 있음을 보여주는证据가 된다. RTM이 없으면 감리자는 요구사항 추적성을 입증하기 어려우며, 결론 도출을 위해 많은 시간과 노력을 기울어야 한다.

품질 향상: 추적성이 보장되면 각 단계의 산출물간 일관성이 높아지며,이로 인해 품질低下로 이어지는 문제의早期発見가 가능해진다.

3.2 RTM 구성 요소

RTM은기본적으로 요구사항 식별자와 그것의 관련 산출물 간의 매핑 관계로 구성된다.

요구사항 ID: 각 요구사항에 부여되는唯一 식별자이다. 체계적인 ID 부여 체계(예: REQ-001, REQ-002)를 사용하여 관리해야 한다.

요구사항 내용: 요구사항의 주요 내용이나 제목이다. 요구사항 문서를 참조하여 具体적으로記載해야 한다.

산출물 매핑: 요구사항과 관련된 산출물(분석 문서, 설계 문서, 코드 모듈, 테스트 케이스 등)을 매핑한다. 일반적으로 정방향(요구사항에서 산출물로)과 역방향(산출물에서 요구사항으로) 추적이 가능하다.

상태 정보: 각 매핑 관계의 상태(예: 구현됨, 미구현, 변경됨, 삭제됨 등)를記録한다.

비고: 추가的な 설명이나链接 등 기타 정보를記載한다.

3.3 정방향 추적과 역방향 추적

RTM을 활용한 추적에는 두 방향이 있다.

정방향 추적(Forward Trace): 요구사항에서 하위 단계 산출물로 추적하는 것이다. 상위 요구사항이 하위 단계에서 어떻게 구현되었는지를 확인한다. 예를 들어, REQ-001이 설계 문서(DWG-001), 코드 모듈(CDM-001), 테스트 케이스(TC-001)로 추적되는지를 확인한다.

정방향 추적이 누락되면 요구사항이 구현되지 않은 채로 남아있을 수 있다. 이를 "요구사항 드리프트(Requirements Drift)"라고 한다.

역방향 추적(Backward Trace): 하위 단계 산출물에서 상위 요구사항으로 추적하는 것이다. 특정 설계나 코드가 어떤 요구사항에서 파생된 것인지를 확인한다. 이를 통해 불필요한 기능이 추가되거나, 요구사항과 무관한 코드가 포함되는 것을 방지한다.

역방향 추적이 누락되면"잠자는 기능(Sleeping Features)"이 발생할 수 있다. 이는 요구사항에는 없는데 구현에만 포함된 기능으로, 불필요한 개발 Effort를 낭비하게 만든다.

3.4 RTM 활용 감리 포인트

감리자는 RTM을 활용하여以下の 사항을 감사해야 한다.

RTM 존재 여부 및 완전성: 프로젝트에 RTM이 수립되어 있는지 확인하고, 요구사항 전체가 RTM에 포함되어 있는지検証해야 한다.

산출물 매핑 적절성: 각 요구사항에 대한 설계, 구현, 테스트 매핑이 올바르게 되어 있는지를 확인한다. 설계 문서나 테스트 케이스가 누락된 요구사항이 없는지重点的に確認해야 한다.

추적성 비율: 요구사항 대비 추적 가능한 산출물의 비율을 산출하여 관리 기준에 미달하는 경우 문제가 없는지를 分析해야 한다.

변경 관리와의 연계: 요구사항 변경 시 RTM이 함께更新되었는지, 영향 분석이 이루어졌는지를 확인해야 한다.

3.5 RTM 관리 프로세스

RTM은 일회적으로 작성하고 끝내는 문서가 아니라, 프로젝트 전 과정에 걸쳐 관리되고 更新되어야 한다.

단계별 업데이트: 각 개발 단계(분석, 설계, 구현, 테스트)가 완료될 때마다 RTM을更新해야 한다.

변경 시 업데이트: 요구사항 변경이 발생하면 즉시 RTM을更新하고, 영향 분석을 수행해야 한다.

정기적 검토: 정기적으로 RTM의 정확성과 완전성을 검토하여 누락이나 오류를修正해야 한다.

인수 시 확인: 프로젝트 인수 시 RTM을 통해 요구사항 전체에 대한 구현 및 테스트 완결성을 확인해야 한다.

4. 핵심 용어 정리

5. analogies 📢

요구사항 추적 매트릭스는 **가족 대的家系도(족보)**와 같다. 가족 대의宗보에서는鼻祖에서 출발하여아들, 손자, 증손자 등代代传承을 기록한다. 이를 통해 특정 후손이哪位 조상에서 비롯되었는지追跡할 수 있다. 만약 족보가 없으면, 가족 구성원의 관계를把握하기 어렵고, 잘못된 정보가流传될 수 있다. Likewise, RTM은 요구사항에서 출발하여 설계, 구현, 테스트 각 단계를 거치면서 어떻게传承되었는지를記録한다. 이를 통해 특정 설계나 코드가 어떤 요구사항에서 비롯된 것인지追踪할 수 있다. 족보가 불완전하면 가족의 系譜가曖昧해지듯, RTM이 불완전하면 요구사항의 구현 여부를추적하기 어렵고,이로 인해 중요한 기능이 누락되거나 불필요한 기능이 추가될 수 있다. 감리자는 족보의 정확성을 확인하듯, RTM을 통해 요구사항 추적성의 적절성을 검증해야 한다.