---
title: "28장. 요구사항 추적성"
description: "목표에서 요구·설계·시험으로 내려가고 다시 근거로 올라오는 양방향 추적 관계를 목적별로 구성한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
필요에서 요구·설계·코드·시험까지 관계를 어떻게 추적하고 활용하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “필요에서 요구·설계·코드·시험까지 관계를 어떻게 추적하고 활용하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
추적표에 링크가 많다고 필요한 추적성이 확보되는 것은 아니다. 관계의 종류와 방향을 구분하지 않으면 어떤 목표를 어떤 요구가 지원하는지, 설계와 시험이 무엇을 실현하고 검증하는지 설명할 수 없다. 모든 항목을 무차별적으로 연결하면 유지 비용만 늘고 중요한 빈틈은 가려진다.
이 장에서는 목표·요구·설계·시험·근거 사이의 양방향 추적 관계를 목적별로 구성한다. 누락과 고아 항목을 찾고 변경 영향을 분석할 수 있도록 관계 유형과 버전을 기록하며, 수강신청 사례로 최소한의 유용한 추적망을 만드는 과정을 다룬다.
### 1. 전방 추적
추적성은 요구사항과 다른 생명주기 산출물 사이에 의미 있는 관계를 세우고 유지해 필요성, 충족 여부와 변경 영향을 설명하는 능력이다. 링크 수가 많거나 행렬 파일이 있다는 사실만으로 추적성이 생기지 않는다. 관계의 방향, 유형, 근거, 상태와 버전을 알아야 질문에 답할 수 있다.
전방 추적은 상위 필요나 요구에서 출발해 그것을 구체화·실현·검증하는 하위 항목으로 내려간다. “이 목표가 어떤 요구와 설계, 시험에서 다뤄지는가?”를 묻는다. [NASA의 추적성 자료 지침](https://swehb.nasa.gov/spaces/7150/pages/16449982/SWE-047%2B-%2BTraceability%2BData)은 요구가 설계·구현·검증까지 이어지는지, 빠진 항목과 근거 없는 기능이 없는지 양방향으로 확인하도록 설명한다.
수강신청 사례의 전방 경로 후보는 다음과 같다.
대괄호 항목은 10부에서 구체화할 추적 항목이지 이미 승인된 설계나 시험이 아니다. 지금은 하위 산출물이 생길 때 연결할 키와 책임을 예약한다. 상세를 미리 발명하지 않으면서도 누락될 지점을 보이게 한다.
전방 검사는 다음을 찾는다.
- 상위 목표를 실현하는 하위 요구가 하나도 없는 막다른 목표
- 기능은 있지만 품질·데이터·인터페이스가 빠진 부분 충족
- 요구는 있으나 설계 또는 시험 책임이 할당되지 않은 항목
- 폐기된 요구를 계속 구현·시험하는 낡은 경로
- 한 요구가 여러 설계에 퍼졌는데 일부만 변경된 분기
경로 끝에 항목이 있다는 것보다 상위 의도를 충분히 충족하는지가 중요하다. `FR-003` 하나가 `G-01` 전체를 달성한다고 단정할 수 없다. `ASM-001`이 확인되지 않았으므로 운영 지표와 사용자 행동까지 연결해 인과를 검토한다.
전방·후방 관계를 실제 표로 구성하는 방법은 부록 G. 요구사항 추적표 예제에서 확인할 수 있다. 모든 칸을 채우기보다 필요성·실현·검증·변경 영향 질문에 답하는 관계만 유지한다.
### 2. 후방 추적
후방 추적은 하위 산출물에서 출발해 “이것은 왜 존재하는가?”를 상위 요구와 필요로 거슬러 올라간다. 화면 버튼, API 필드, 데이터 열, 로그, 시험 사례와 운영 절차가 어느 요구를 실현하거나 검증하는지 확인한다. 상위 근거가 없는 항목은 불필요한 추가 구현, 범위 확장, 오래된 구현 또는 숨은 필수 요구일 수 있다.
예를 들어 상태 조회 API에 `rankingScore` 필드가 추가됐다고 가정하자. 후방으로 `API-STATUS-01`` → ``FR-003`만 연결하면 결과 조회에 필요하다고 오해할 수 있다. 실제로는 `RULE-005` 우선순위 계산의 내부 값일 수 있고, 학생에게 공개하면 정책 악용이나 개인정보 위험이 생길 수 있다. 권한 있는 공개 요구와 데이터 최소화 근거가 없다면 단순 편의를 위해 노출하지 않는다.
후방 추적의 판정은 세 갈래다.
1. **정당한 파생 항목**: 상위 요구를 실현하기 위한 설계 결정이며 이유와 대안이 기록됨.
2. **새 요구 발견**: 현장 제약이나 기술 분석에서 필수 필요가 드러나 상위 요구로 승격·검토해야 함.
3. **근거 없는 항목**: 목표·요구와 연결되지 않고 필요성도 확인되지 않아 제거 또는 보류해야 함.
자체 파생 요구도 무조건 잘못은 아니다. 예컨대 동시 신청에서 원자적 좌석 반영이 `QR-003`을 실현하는 설계 제약으로 도출될 수 있다. 이때 파생 주체, 기술 근거, 상위 관계와 검증 방법을 기록하고 요구 승인 절차를 거친다. 설계자가 만들었다는 이유만으로 정책 요구처럼 취급하지 않는다.
시험도 후방으로 본다. `TC-IR-001-01`이 규칙 서비스 시간 초과를 시험한다면 `IR-001`과 `DR-001`, 관련 상태 모델로 올라가야 한다. 연결 요구가 폐기됐는데 시험만 남았다면 제거 또는 회귀 목적을 재확인한다. 요구에 없는 기대값을 시험이 만들고 있다면 숨은 요구를 발견한 것이다.
### 3. 양방향 추적
양방향 추적은 전방·후방 링크를 따로 만들어 놓는 것이 아니라 하나의 관계를 양쪽 질문에서 탐색할 수 있게 하는 것이다. 상위에서 내려가면 범위 충족을, 하위에서 올라가면 필요성과 정당성을 검토한다. 변경이 어느 방향에서 시작돼도 영향을 찾을 수 있다.
[IIBA의 Trace Requirements 공식 항목](https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/5-requirements-life-cycle-management/5-1-trace-requirements/)은 요구와 설계가 서로, 그리고 다른 산출물과 연결돼 영향 분석·범위·수용·할당·보고에 쓰이게 하는 생명주기 활동에 포함된다. 프로젝트는 필요한 질문에 맞게 추적 깊이를 정해야 한다.
`IR-001`의 양방향 예를 보자.
25장의 검증 증거와 26장의 확인 증거도 관계 유형을 구분한다. `TC-IR-001-01`은 구현이 명시된 실패 결과를 지키는지 시험하고, `VAL-SCN-01`은 그 보류가 사용 목적과 운영에 적절한지 확인한다. 둘 다 `IR-001`에 연결되지만 같은 증거가 아니다.
양방향 링크의 완전성은 자동으로 보장되지 않는다. A가 B를 가리키고 B가 A를 가리키는 두 칸을 따로 편집하면 한쪽만 바뀔 수 있다. 가능하면 관계를 한 번 저장하고 양쪽 보기로 표현한다. 파일 기반이라면 정기 검사로 존재하지 않는 대상, 방향 불일치, 버전이 다른 링크를 찾는다.
### 4. 추적 행렬
추적 행렬은 많은 관계를 검토하기 위한 보기다. 추적성 그 자체가 아니며, 한 표에 모든 산출물을 열로 늘어놓을 필요도 없다. 목적별로 작게 나누면 결함을 찾기 쉽다.
| 행렬 목적 | 행 | 열 | 찾을 결함 |
|---|---|---|---|
| 목표 충족 | 목표·상위 요구 | 사용자·시스템 요구 | 막다른 목표, 고아 요구 |
| 요구 구조 | 상위 요구 | 하위·파생 요구 | 누락, 중복, 잘못된 분해 |
| 실현 | 요구 | 설계·화면·API·데이터 | 미할당, 불필요한 추가 구현, 부분 반영 |
| 검증 | 요구 | 시험·분석·검사·시연 | 검증 방법 없음, 경계 미시험 |
| 확인 | 필요·요구 | 시나리오·프로토타입·수용 결과 | 사용 맥락 누락, 미합의 |
| 변경 영향 | 변경 대상 | 연결 요구·산출물·책임자 | 통지·재작업·재검토 누락 |
현재 단계의 축약 행렬 후보는 다음과 같다.
| 상위 | 요구 | 연관 요구·제약 | 설계 항목 후보 | 시험·확인 항목 후보 | 상태·쟁점 |
|---|---|---|---|---|---|
| `G-01`, `UR-001` | `FR-003` | `QR-001`, `DR-001`, `IR-005`, `UI-001` | `SCR-STATUS-01`, `API-STATUS-01` | `TC-FR-003-01`, `VAL-SCN-01` | 후보, `ASM-001` |
| `G-01`, `SR-001` | `IR-001` | `DR-001`, `FR-003`, `QR-010` | `API-RULE-01`, 보류 상태 흐름 | `TC-IR-001-01`, `VAL-SCN-01` | 종료 정책 미결 |
| `SR-001` | `FR-001` | `RULE-001–RULE-005`, `QR-003`, `IR-004` | 판정 흐름·규칙 계약 항목 | 규칙 경계·동시성 시험 항목 | `ISS-001`, `ASM-002` |
| `SR-001` | `FR-004` | `DR-002`, `QR-003` | 멱등 처리 항목 | 중복·늦은 응답 시험 항목 | 동일성 기간 미결 |
빈 셀은 즉시 오류라고 단정하지 않는다. 아직 생명주기 단계가 이르거나 해당 관계가 불필요할 수 있다. “해당 없음”에는 근거를, 나중에 채울 셀에는 책임자·기한·진입 조건을 둔다. 단순 빈칸과 의도적 제외를 구분해야 한다.
행렬에는 관계 대상의 버전과 상태가 필요하다. `FR-003`` v0.4`를 시험한 결과를 수정된 `v0.5`의 증거로 자동 승계하지 않는다. 변경 차이가 시험 결과에 영향을 주는지 평가해 재사용·보완·재시험을 결정한다.
행렬 갱신 책임은 산출물 작성 흐름에 넣는다. 요구를 추가한 사람은 상위 출처와 동료 관계를, 설계 책임자는 할당·실현 관계를, 시험 책임자는 검증 관계와 결과를 등록한다. 요구 관리 책임자는 모든 링크를 대신 입력하기보다 관계 규칙과 품질 검사를 운영한다. 산출물 변경과 링크 갱신이 별도 일정이면 행렬은 빠르게 과거를 설명하는 표가 된다.
관계 하나에 필요한 최소 기록은 `출발 ID·버전`, `관계 유형`, `도착 ID·버전 또는 안정적인 참조 정보`, `등록 근거`, `소유자`, `상태`, `마지막 확인 시점`이다. 임시 링크에는 만료나 해소 조건을 둔다. 설계 항목 후보가 실제 설계 ID로 바뀌면 후보 링크를 그대로 두지 않고 대체 관계를 기록한다.
추적성 지표는 결함을 찾는 신호로 사용한다.
- 상위 출처가 없는 요구와 하위 실현 항목이 없는 승인 요구의 수
- 검증 방법·결과가 연결되지 않은 요구의 수와 위험 등급
- 근거 요구가 없는 설계·코드·시험 항목의 수
- 변경 뒤 갱신되지 않은 링크와 평균 경과시간
- 폐기 대상이나 과거 버전을 가리키는 링크의 수
- 관계 검토에서 잘못된 유형·방향으로 판정된 비율
“연결 범위 100%”를 목표로 빈 셀에 무의미한 연결을 넣지 않는다. 높은 위험 요구가 충분한 증거로 연결되는지, 고아·누락이 의사결정 전에 드러나는지가 더 중요하다. 관계의 질은 표본 검토와 변경 사례를 실제로 따라가 확인한다.
### 5. 요구사항 관계
요구사항 사이의 관계 유형을 구분하면 링크의 의미와 변경 전파 규칙을 알 수 있다. “관련 있음” 하나로는 어느 쪽이 상위이고 어떤 영향을 주는지 판단할 수 없다.
| 관계 유형 | 의미 | 수강신청 예 | 변경 질문 |
|---|---|---|---|
| 도출됨 | 하위 요구가 상위 필요에서 나옴 | `FR-003`은 `UR-001`에서 도출 | 상위 필요 변경 시 여전히 필요한가? |
| 분해함 | 한 요구를 독립 하위 요구로 나눔 | `SR-001`을 `FR·QR·DR·IR`로 구체화 | 하위가 상위 전체를 덮는가? |
| 의존함 | 한 요구 충족이 다른 요구·조건에 의존 | `FR-001`은 `IR-003``·004`의 유효 데이터에 의존 | 공급 실패 때 대안은? |
| 제약함 | 품질·정책·인터페이스가 가능한 해를 제한 | `QR-003`이 좌석 반영을 제약 | 제약 완화가 안전·공정성을 바꾸는가? |
| 충돌함 | 동시에 충족할 수 없거나 해석이 다름 | `RULE-004`와 `RULE-005` 사이 마지막 좌석의 `ISS-001` | 누가 어떤 근거로 해결하는가? |
| 중복함 | 같은 필요를 반복 표현 | 유사 결과 통지 요구 | 어느 ID를 유지하고 어떻게 대체하는가? |
| 대체함 | 새 요구가 이전 요구를 대신함 | 정책 개정 뒤 새 요구 후보 | 이전 기준선과 사용처를 보존했는가? |
| 검증함·확인함 | 증거가 요구 준수·필요 충족을 평가 | 시험과 `VAL-SCN-01` | 어느 버전과 조건의 증거인가? |
관계는 방향과 카디널리티도 본다. 하나의 상위 요구를 여러 하위 요구가 함께 충족할 수 있고, 하나의 품질 요구가 여러 기능을 제약할 수 있다. 행렬의 체크 표시 하나로는 전체 충족인지 부분 기여인지 알 수 없으므로 `충족`, `부분 충족`, `제약`, `정보 제공`처럼 역할을 기록한다.
분해 관계에서는 상위와 하위의 조건 범위를 비교한다. 하위 요구를 모두 합쳐도 상위의 예외·품질·사용자 집단이 빠지면 완전한 분해가 아니다. 반대로 하위에 상위 근거가 없는 기능이 섞이면 범위가 커졌다. 중복 관계는 문장이 닮았다는 이유만으로 정하지 않고 주체·조건·결과·판정 증거가 같은지 확인한다.
충돌 관계에는 해결 상태를 둔다. `ISS-001`처럼 정책 판단이 남은 경우 두 요구 중 하나를 조용히 수정하지 않는다. 충돌을 발견한 버전, 영향, 결정권자, 대안과 기한을 연결하고 해결 뒤 어떤 요구·시험이 바뀌었는지 기록한다. 의존 관계에도 필수·선택, 정상·대체 경로와 시간 제약을 두면 연계 실패의 영향을 정확히 펼칠 수 있다.
모델·문서·코드 사이의 링크도 같은 원칙을 적용한다. 링크 대상 위치가 줄 번호처럼 자주 바뀌면 안정적 식별자를 추가한다. 제목·파일명만으로 연결하면 이름 변경 때 끊어질 수 있다.
### 6. 설계 추적
설계 추적은 요구가 어떤 해결 구조·화면·흐름·API·데이터 설계에 할당됐는지, 반대로 그 설계 결정이 어떤 요구와 근거에서 나왔는지 보여 준다. 요구와 설계를 혼합하지 않는다. 요구는 필요한 결과와 제약을, 설계는 그것을 달성할 방법과 선택 근거를 다룬다.
`FR-003`을 예로 들면 10부에서 다음 후보가 구체화될 수 있다.
- `FEAT-STATUS-01`: 신청 결과 조회 기능 묶음
- `FLOW-ENR-01`: 신청 제출부터 접수·보류·판정·취소 흐름
- `SCR-STATUS-01`: 신청 상태와 사유·다음 행동 화면
- `API-STATUS-01`: 공식 상태 조회 API 계약
- `DATA-DECISION-01`: `DR-001` 판정 이력 구조
지금 이 ID들은 **추적 항목 후보**다. 설계 대안이 선택되고 책임자가 지정되기 전에는 승인 산출물로 표시하지 않는다. 요구 하나가 여러 설계 항목에 나뉘면 각 항목이 어느 부분을 실현하는지 기록한다. 화면만 연결하고 API·데이터를 빼면 사용자가 본 결과가 무엇을 기준으로 하는지와 이력을 설명할 수 없다.
설계에서 요구로 올라가는 링크에는 결정 근거가 필요하다. 상태 조회를 폴링으로 할지 서버 푸시로 할지 같은 선택은 `QR-001`, 부하, 운영 복잡성, 접근성의 영향을 비교해야 한다. 특정 기술을 사용했다는 사실을 요구사항인 것처럼 포장하지 않는다.
설계 변경도 요구 영향을 만들 수 있다. 알림을 비동기로 바꾸면 `IR-005`의 전달·중복·순서 계약과 `FR-003`의 공식 상태 구분을 다시 본다. 요구 문장이 변하지 않아도 검증 방법과 운영 위험은 달라질 수 있다.
### 7. 시험 추적
시험 추적은 각 요구의 충족을 어떤 분석·검사·시연·시험이 증명하는지, 각 시험의 기대 결과가 어느 요구에서 왔는지 연결한다. 테스트 케이스 수를 요구 수로 나눈 값만으로 충분성을 판단하지 않는다. 정상·경계·오류·품질 조건과 위험을 덮는지를 본다.
| 요구 | 시험 항목 후보 | 핵심 조건 | 금지·기대 결과 |
|---|---|---|---|
| `FR-001`, `RULE-001` | `TC-RULE-001-01` | 선수과목 충족·미충족·경계 | 승인 또는 근거 있는 거절 |
| `QR-003`, `RULE-004`, `RULE-005` | `TC-CAP-001-01` | 마지막 좌석 동시 신청 | 수용량 초과 없음; 우선정책은 미결 표시 |
| `IR-001`, `DR-001` | `TC-IR-001-01` | 오류·무효·시간 초과·늦은 응답 | 자동 승인 없음, 보류·이력 연결 |
| `FR-004`, `DR-002` | `TC-DUP-001-01` | 동일 의도 반복·응답 유실 | 복수 최종 판정·복수 좌석 반영 없음 |
| `FR-005` | `TC-CAN-001-01` | 판정 중 취소·취소 뒤 늦은 승인 | 허용 상태·이력에 따른 일관된 결과 |
| `QR-001` | `PT-STATUS-001` | 합의된 부하·데이터·측정 창 | p95 후보값을 같은 산식으로 판정 |
이 표는 시험 설계의 시작점이지 실행 결과가 아니다. 실제 환경, 데이터, 시험 판정 기준, 반복 횟수와 증거 저장 위치를 정해야 한다. `RULE-005`가 미합의인 상태에서는 우선순위 기대값을 만들 수 없으므로 `RULE-004`의 수용량 초과 금지만 시험하고 정책 판정은 차단한다.
시험 결과에는 실행한 요구 버전과 환경을 연결한다. 실패는 요구 불충족뿐 아니라 요구 모호성, 시험 오류, 환경 차이 또는 데이터 품질 문제일 수 있다. 원인을 분류한 뒤 요구·설계·시험 중 수정 대상을 정한다. 수정 뒤에는 영향을 받은 링크를 따라 회귀 범위를 선택한다.
확인 시나리오도 별도 관계로 유지한다. 성능 시험 통과가 학생의 결과 이해를 증명하지 않고, 프로토타입 성공이 동시성 안전을 증명하지 않는다. 요구 하나에 서로 다른 증거가 필요할 수 있다.
### 8. 변경 영향 분석
변경 영향 분석은 바꾸려는 항목에서 양방향 링크를 따라 직접·간접 영향을 찾고, 비용·일정·품질·위험·이해관계자 효과를 평가하는 활동이다. 링크를 기계적으로 펼치는 것과 영향의 크기·재작업 여부를 판단하는 일을 구분한다.
29장에서 사용할 `CR-003`은 “졸업 예정자에게 수강신청 우선권을 주자”는 정책 변경 요청 후보다. 아직 필요 근거, 졸업 예정 판정 기준, 대상 강좌, 적용 시점과 공정성 예외가 합의되지 않았다. 추적 관계를 사용하면 최소 영향 범위가 보인다.
영향 분석은 다음 순서로 수행한다.
1. 변경 요청의 대상 버전, 목적, 범위와 적용 희망 시점을 고정한다.
2. 상향으로 목표·정책·가정과 권한을 확인해 필요성을 평가한다.
3. 하향으로 요구·설계·데이터·인터페이스·시험·운영·문서를 펼친다.
4. 각 항목을 수정, 재검토, 재시험, 통지만 필요, 영향 없음으로 분류하고 근거를 남긴다.
5. 간접 영향과 새 위험, 개인정보·공정성·접근성·운영 부담을 검토한다.
6. 대안별 비용·일정·효과와 미결 정보를 비교해 결정 자료를 만든다.
7. 승인·반려·보류 뒤 링크와 상태, 기준선 이력을 갱신한다.
`CR-003`에서 화면 문구만 고치면 정책 변경이 끝나지 않는다. 졸업 예정 상태의 기준 원천과 기준 시점, 마지막 좌석의 동시 배정, 거절·보류 사유, 이의 제기, 개인정보 노출과 시험 판정 기준이 함께 바뀔 수 있다. 반대로 모든 관련 파일을 무조건 수정 대상으로 잡으면 분석 비용이 폭증한다. 관계 유형과 실제 차이를 읽어 영향 없음도 증거와 함께 기록한다.
영향 범위에는 사람과 운영도 포함한다. 학생지원 담당자는 새 우선권의 설명과 이의 제기 절차가 필요할 수 있고, 학사 담당자는 졸업 예정 상태 오류를 정정하고 재판정하는 권한이 필요할 수 있다. 규칙 서비스와 학사정보 제공자는 데이터 계약·버전·배포 순서를 조율해야 한다. 공지·교육·운영 대시보드·감사 보고서가 코드 밖에 있다고 추적에서 제외하지 않는다.
분석 결과는 링크 그래프의 크기가 아니라 변경 판정으로 요약한다.
| 판정 | 의미 | 필요한 기록 |
|---|---|---|
| 직접 수정 | 내용·조건·인터페이스가 실제로 바뀜 | 새 버전, 검토·시험, 기준선 반영 |
| 간접 재확인 | 내용은 같지만 가정·위험·증거가 달라짐 | 영향 근거와 재검토 결과 |
| 통지·순서 조정 | 산출물 변경 없이 배포·운영 협력이 필요 | 수신자, 시점, 준비 완료 증거 |
| 영향 없음 | 링크는 있으나 이번 변경 차이가 미치지 않음 | 비교 기준과 검토자 |
| 판단 보류 | 자료·정책·대안이 부족함 | 책임자, 기한, 미결 위험 |
이 분류를 해야 영향 없음도 검토 가능한 결론이 되고, “관련 있음”을 모두 재작업으로 계산하지 않는다. 변경이 승인되면 실제 수정 결과가 분석 범위와 일치하는지 후속 대사를 하고, 예상하지 못한 영향은 관계 모델과 체크리스트를 개선하는 학습 자료로 남긴다.
이 장에서 정리한 결과는 **관계 모델**, **양방향 추적 예**, **추적 행렬**, **변경 영향 경로**다. 이 산출물은 29장에서 `CR-003`의 비용·일정·위험과 승인 여부를 판단하는 입력이 된다. 행렬을 만들었다는 사실보다 요구 하나의 출처에서 설계·시험 결과까지 오가며 누락과 근거 없는 항목을 설명할 수 있는지가 완료 기준이다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 28장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
목표에서 요구·설계·시험으로 내려가고 다시 근거로 올라오는 양방향 추적 관계를 목적별로 구성한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.