要件トレーサビリティ表を作りカバレッジを検証する

한국어 원문으로 표시합니다.

목표

인터뷰 정리본에서 요구사항을 뽑아 번호를 붙이고, 요구사항 추적표(RTM)를 만든 뒤, 커버리지와 누락 항목을 스크립트로 검증할 수 있게 됩니다.

왜 중요한가

SI 프로젝트에서 요구사항 ID 는 요구사항정의서 → 화면정의서 → 프로그램목록 → 테스트 시나리오 → 검수확인서를 꿰는 유일한 실입니다. 이 실이 끊긴 자리에서 "개발됐는데 테스트 안 된 기능"과 "요구사항에 없는데 만들어진 기능"이 나옵니다. 그리고 그 발견은 항상 검수 2주 전에 일어납니다. 500 건짜리 추적표를 눈으로 대조하는 건 불가능하므로, 현장에서는 결국 누군가 이 검증을 스크립트로 만듭니다. 그 누군가가 되는 것이 이 실습입니다.

단계

/root/req 디렉터리를 만들고 /opt/lab/fixtures/si-process/req-src.md 를 /root/req/req-src.md 로 복사합니다.
/root/req/requirements.csv 를 만듭니다. 첫 줄은 정확히 req_id,category,title,priority,source 이고, 데이터는 8 행입니다. req_id 는 REQ-001 ~ REQ-008, priority 는 상/중/하 중 하나, category 와 source 는 비어 있으면 안 됩니다.
/root/req/rtm.csv 를 만듭니다. 첫 줄은 req_id,screen_id,program_id,test_id. 화면 ID 는 SCR-001 형식, 프로그램 ID 는 PGM-001 형식, 테스트 ID 는 TC-001 형식입니다. REQ-001 ~ REQ-008 이 모두 최소 한 번 등장해야 합니다.
/root/req/coverage.sh 를 만듭니다. 인자 두 개(요구사항목록 추적표)를 받아 coverage=NN% 한 줄만 출력합니다(소수점 없이 내림). 실행 권한을 주세요.
/opt/lab/fixtures/si-process/rtm-vendor.csv 는 협력사가 보내온 추적표입니다. 여기에 등장하지 않는 요구사항 ID 를 한 줄에 하나씩, 오름차순으로 /root/req/orphan.txt 에 적습니다.
/root/req/change-log.csv 를 만듭니다. 첫 줄은 chg_id,req_id,before,after,requested_by,approved,date. 2 행 이상이고, approved 가 Y 인 행과 N 인 행이 각각 최소 하나씩 있어야 합니다. req_id 는 요구사항 목록에 있는 것만 씁니다. date 는 2026-08-11 형식입니다.
/root/req/report.md 를 작성합니다. ## 요구사항 현황, ## 커버리지, ## 미추적 항목, ## 변경 이력 네 개의 h2 제목이 있어야 하고, 4 단계에서 계산한 커버리지 값과 5 단계에서 찾은 요구사항 ID 가 본문에 그대로 들어가야 합니다.
/root/req/verify.sh 를 만듭니다. 인자 두 개(요구사항목록 추적표)를 받아 정합성 검사를 하고, 이상이 없으면 첫 줄에 OK 를 출력하며 종료코드 0, 이상이 있으면 NG 로 시작하는 줄을 출력하며 종료코드 1 이어야 합니다. 검사 항목: (1) 추적표의 모든 req_id 가 요구사항 목록에 존재, (2) test_id 중복 없음.

참고

CSV 는 head -1, tail -n +2, cut -d, -f1, sort -u, comm -23 조합으로 거의 다 됩니다.
흔한 실수 1: CSV 필드 안에 콤마를 넣는 것. 제목에 콤마 대신 / 나 공백을 쓰세요.
흔한 실수 2: coverage.sh 가 헤더 줄까지 세는 것. tail -n +2 를 잊지 마세요.
흔한 실수 3: 스크립트에 실행 권한(chmod +x)을 안 주는 것.

작업 디렉터리와 원본 확보

/root/req 디렉터리를 만들고 /opt/lab/fixtures/si-process/req-src.md 를 /root/req/req-src.md 로 복사합니다.

산출물 작업의 첫 규칙은 '원본은 건드리지 않는다'입니다. /opt/lab/fixtures 아래는 읽기 전용이라고 생각하고 작업 사본을 만드세요.

요구사항 목록 CSV 작성

/root/req/requirements.csv 를 만듭니다. 첫 줄은 정확히 req_id,category,title,priority,source 이고, 데이터는 8 행입니다. req_id 는 REQ-001 ~ REQ-008, priority 는 상/중/하 중 하나, category 와 source 는 비어 있으면 안 됩니다.

인터뷰 정리본 한 문단에 요구사항이 여러 개 섞여 있습니다. '그리고', '또한'이 나오면 대개 쪼갤 자리입니다. ID 는 REQ-001 처럼 세 자리로 0 을 채워야 정렬이 깨지지 않습니다.

추적표에 설계·프로그램·테스트 연결

/root/req/rtm.csv 를 만듭니다. 첫 줄은 req_id,screen_id,program_id,test_id. 화면 ID 는 SCR-001 형식, 프로그램 ID 는 PGM-001 형식, 테스트 ID 는 TC-001 형식입니다. REQ-001 ~ REQ-008 이 모두 최소 한 번 등장해야 합니다.

한 요구사항이 화면 여러 개로 갈라질 수 있습니다. 그럴 땐 행을 여러 줄 쓰세요. 한 칸에 콤마로 여러 값을 넣으면 CSV 가 깨집니다.

커버리지 계산 스크립트

/root/req/coverage.sh 를 만듭니다. 인자 두 개(요구사항목록 추적표)를 받아 coverage=NN% 한 줄만 출력합니다(소수점 없이 내림). 실행 권한을 주세요.

커버리지 = 추적표에 한 번이라도 등장한 요구사항 수 / 전체 요구사항 수. cut 으로 열을 뽑고 sort -u 로 중복을 없앤 뒤 wc -l 로 세면 됩니다. 정수 나눗셈에 주의하세요.

협력사 추적표의 누락 요구사항 찾기

/opt/lab/fixtures/si-process/rtm-vendor.csv 는 협력사가 보내온 추적표입니다. 여기에 등장하지 않는 요구사항 ID 를 한 줄에 하나씩, 오름차순으로 /root/req/orphan.txt 에 적습니다.

양쪽 목록을 정렬해 두고 comm 이나 grep -v -F -f 로 차집합을 구합니다. 눈으로 대조하면 반드시 틀립니다.

요구사항 변경 대장 작성

/root/req/change-log.csv 를 만듭니다. 첫 줄은 chg_id,req_id,before,after,requested_by,approved,date. 2 행 이상이고, approved 가 Y 인 행과 N 인 행이 각각 최소 하나씩 있어야 합니다. req_id 는 요구사항 목록에 있는 것만 씁니다. date 는 2026-08-11 형식입니다.

변경 대장의 핵심은 '변경 전/후'와 '승인 여부'입니다. 승인되지 않은 변경도 반드시 기록으로 남겨야 나중에 근거가 됩니다.

요구사항 현황 리포트

/root/req/report.md 를 작성합니다. ## 요구사항 현황, ## 커버리지, ## 미추적 항목, ## 변경 이력 네 개의 h2 제목이 있어야 하고, 4 단계에서 계산한 커버리지 값과 5 단계에서 찾은 요구사항 ID 가 본문에 그대로 들어가야 합니다.

리포트에는 계산한 커버리지 숫자와 누락 요구사항 ID 를 그대로 인용하세요. 사람이 다시 계산하게 만드는 리포트는 아무도 안 읽습니다.

추적표 정합성 검증 스크립트

/root/req/verify.sh 를 만듭니다. 인자 두 개(요구사항목록 추적표)를 받아 정합성 검사를 하고, 이상이 없으면 첫 줄에 OK 를 출력하며 종료코드 0, 이상이 있으면 NG 로 시작하는 줄을 출력하며 종료코드 1 이어야 합니다. 검사 항목: (1) 추적표의 모든 req_id 가 요구사항 목록에 존재, (2) test_id 중복 없음.

검증할 것은 두 가지입니다. (1) 추적표의 요구사항 ID 가 전부 요구사항 목록에 있는가 — 유령 요구사항 방지. (2) 같은 테스트 ID 가 두 번 쓰이지 않았는가. 인자로 받은 경로를 검사하도록 만들어야 다른 프로젝트에도 씁니다.