Building a Requirements Traceability Matrix and Verifying Coverage

Goal

You extract requirements from an interview summary and number them, build a requirements traceability matrix (RTM), and then verify the coverage and the missing items with a script.

Why it matters

In an SI project, the requirement ID is the only thread that runs through the requirements definition document → screen definition document → program list → test scenarios → acceptance confirmation. "Features that were developed but not tested" and "features that were built but are not in the requirements" come from the places where this thread is broken. And that discovery always happens two weeks before acceptance. Comparing a 500-row matrix by eye is impossible, so in the field someone eventually turns this check into a script. This lab is about becoming that someone.

Steps

Create the /root/req directory and copy /opt/lab/fixtures/si-process/req-src.md to /root/req/req-src.md.
Create /root/req/requirements.csv. The first line is exactly req_id,category,title,priority,source, and there are 8 data rows. req_id runs from REQ-001 to REQ-008, priority is one of 상/중/하 (high/medium/low), and category and source must not be empty.
Create /root/req/rtm.csv. The first line is req_id,screen_id,program_id,test_id. Screen IDs have the form SCR-001, program IDs have the form PGM-001, and test IDs have the form TC-001. Every one of REQ-001 to REQ-008 must appear at least once.
Create /root/req/coverage.sh. It takes two arguments (요구사항목록 추적표, meaning the requirements list and the traceability matrix) and prints only one line, coverage=NN% (rounded down, no decimal point). Make it executable.
/opt/lab/fixtures/si-process/rtm-vendor.csv is a traceability matrix sent by a partner vendor. Write the requirement IDs that do not appear in it to /root/req/orphan.txt, one per line, in ascending order.
Create /root/req/change-log.csv. The first line is chg_id,req_id,before,after,requested_by,approved,date. It has 2 or more rows, and there must be at least one row where approved is Y and at least one where it is N. Use only req_id values that are in the requirements list. date has the form 2026-08-11.
Write /root/req/report.md. It must have four h2 headings, ## 요구사항 현황, ## 커버리지, ## 미추적 항목 and ## 변경 이력, and the body must quote as they are the coverage value computed in step 4 and the requirement IDs found in step 5.
Create /root/req/verify.sh. It takes two arguments (요구사항목록 추적표, meaning the requirements list and the traceability matrix) and runs a consistency check: if nothing is wrong it prints OK on the first line and exits with code 0, and if something is wrong it prints a line starting with NG and exits with code 1. Checks: (1) every req_id in the matrix exists in the requirements list, (2) there are no duplicate test_id values.

Notes

Almost everything for CSV can be done by combining head -1, tail -n +2, cut -d, -f1, sort -u and comm -23.
Common mistake 1: putting a comma inside a CSV field. Use / or a space instead of a comma in titles.
Common mistake 2: having coverage.sh count the header line too. Don't forget tail -n +2.
Common mistake 3: not giving the scripts execute permission (chmod +x).

Set up the working directory and get the source

Create the /root/req directory and copy /opt/lab/fixtures/si-process/req-src.md to /root/req/req-src.md.

The first rule of deliverable work is 'never touch the original'. Treat everything under /opt/lab/fixtures as read-only and make a working copy.

Write the requirements list CSV

Create /root/req/requirements.csv. The first line is exactly req_id,category,title,priority,source, and there are 8 data rows. req_id runs from REQ-001 to REQ-008, priority is one of 상/중/하 (high/medium/low), and category and source must not be empty.

One paragraph of the interview summary has several requirements mixed together. Wherever "and" or "also" appears, that is usually a place to split. Pad IDs with zeros to three digits, like REQ-001, so that sorting doesn't break.

Link design, programs and tests in the matrix

Create /root/req/rtm.csv. The first line is req_id,screen_id,program_id,test_id. Screen IDs have the form SCR-001, program IDs have the form PGM-001, and test IDs have the form TC-001. Every one of REQ-001 to REQ-008 must appear at least once.

One requirement can branch into several screens. In that case, write several rows. If you put several values separated by commas in one cell, the CSV breaks.

Coverage calculation script

Create /root/req/coverage.sh. It takes two arguments (요구사항목록 추적표, meaning the requirements list and the traceability matrix) and prints only one line, coverage=NN% (rounded down, no decimal point). Make it executable.

Coverage = number of requirements that appear at least once in the matrix / total number of requirements. Extract the column with cut, remove duplicates with sort -u, then count with wc -l. Watch out for integer division.

Find the requirements missing from the partner vendor's matrix

/opt/lab/fixtures/si-process/rtm-vendor.csv is a traceability matrix sent by a partner vendor. Write the requirement IDs that do not appear in it to /root/req/orphan.txt, one per line, in ascending order.

Sort both lists and get the set difference with comm or grep -v -F -f. If you compare by eye, you will surely get it wrong.

Write the requirement change log

Create /root/req/change-log.csv. The first line is chg_id,req_id,before,after,requested_by,approved,date. It has 2 or more rows, and there must be at least one row where approved is Y and at least one where it is N. Use only req_id values that are in the requirements list. date has the form 2026-08-11.

The core of a change log is 'before/after' and 'approval status'. Changes that were not approved must be recorded too, so that they serve as evidence later.

Requirements status report

Write /root/req/report.md. It must have four h2 headings, ## 요구사항 현황, ## 커버리지, ## 미추적 항목 and ## 변경 이력, and the body must quote as they are the coverage value computed in step 4 and the requirement IDs found in step 5.

Quote the coverage number you computed and the missing requirement IDs exactly. Nobody reads a report that makes people recalculate.

Matrix consistency check script

Create /root/req/verify.sh. It takes two arguments (요구사항목록 추적표, meaning the requirements list and the traceability matrix) and runs a consistency check: if nothing is wrong it prints OK on the first line and exits with code 0, and if something is wrong it prints a line starting with NG and exits with code 1. Checks: (1) every req_id in the matrix exists in the requirements list, (2) there are no duplicate test_id values.

There are two things to verify. (1) Are all the requirement IDs in the matrix in the requirements list — this prevents phantom requirements. (2) Is the same test ID never used twice. Make the script check the paths it receives as arguments so you can use it in other projects too.