문제의 역사:
요구 사항 추적(tracability)은 비즈니스 기대와 시스템 실제 구현 간의 괴리를 방지하기 위한 도구로 등장했습니다. 처음에 분석가들은 수동 점검과 목록에 의존했지만 이는 매우 비효율적이었습니다.
문제:
추적이 없으면 서로 다른 수준의 요구 사항 간의 연결이 상실됩니다: 비즈니스 목표 → 기능 요구 사항 → 기술 요구 사항 → 테스트 시나리오. 이는 오류, ‘잃어버린’ 요구 사항 및 품질 저하로 이어집니다.
해결책:
요구 사항 추적은 매트릭스, 특수 도구(Jama, DOORS, Jira/Zephyr) 및 템플릿을 사용해 일치하는 체인으로 구성됩니다:
추적 매트릭스(traceability matrix)가 생성됩니다. 가장 간단한 구조는 다음과 같습니다:
| 비즈니스 목표 | 기능 요구 사항 | 테스트 시나리오 |
|---|---|---|
| BC-1 | FR-1 | TC-1 |
도구에서 아티팩트 태깅이 적용됩니다.
각 수준의 변경이 있을 때마다 체인이 재검토됩니다 — 연결이 있어야 합니다.
목표에 연결되지 않은 ‘매달린’ 요구 사항이나 테스트를 식별하기 위해 정기적으로 검토하는 것이 중요합니다.
주요 특징:
작은 프로젝트에서는 추적 매트릭스 없이도 괜찮은가요?
아니요, 작은 프로젝트에서도 추적이 없으면 종종 요구 사항이 사라집니다.
프로젝트 초기에 한 번 추적을 구축하는 것으로 충분한가요?
아니요, 매트릭스는 요구 사항과 테스트가 변경됨에 따라 정기적으로 업데이트해야 합니다.
추적 가능성은 테스트 완료에만 영향을 미치나요?
아니요, 설계부터 유지보수까지 모든 단계에 중요하며, 변경 사항의 영향을 평가하고 작업을 계획하는 데 도움을 줍니다.
부정적 사례:
프로젝트에서 추적 매트릭스를 구축하지 않았고, 테스터들은 사양만을 바탕으로 작업했습니다. 몇 가지 요구 사항이 구현되었지만 확인되지 않아 프로덕션에서 기능이 제대로 작동하지 않았습니다.
장점:
단점:
긍정적 사례:
다른 프로젝트에서는 생생한 추적 매트릭스가 유지되었습니다. 모든 요구 사항이 테스트 및 비즈니스 목표와 연결되었고, 모든 변경 사항이 추적되었습니다. 고려되지 않은 기능 및 ‘정의되지 않은’ 테스트가 없었습니다.
장점:
단점: