---
title: "29장. 요구사항 변경 관리"
description: "변경 요청의 필요성·영향·비용·위험과 대안을 비교하고 근거 없는 승인이나 가상 수치를 만들지 않는다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
변경 요청의 이유·영향·결정·반영 결과를 어떻게 통제하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “변경 요청의 이유·영향·결정·반영 결과를 어떻게 통제하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
변경 요청은 기존 요구를 덮어쓰는 편집 지시가 아니다. 작은 문장 수정처럼 보여도 정책, 데이터, 인터페이스, 품질과 시험에 연쇄 영향을 줄 수 있으며, 요청의 필요성과 결정 권한이 확인되지 않았을 수도 있다. 변경 속도와 통제는 서로 반대되는 목표가 아니다.
이 장에서는 변경 요청을 접수해 필요성·영향·비용·위험과 대안을 비교하고 권한 있는 결정을 받는 절차를 다룬다. 근거 없는 승인이나 가상 수치를 만들지 않고, 보류·거절·승인 결과를 기준선과 관련 산출물에 일관되게 반영하는 방법을 살펴본다.
### 1. 요구사항은 왜 변하는가
요구사항은 처음부터 완벽하지 않아서만 변하는 것이 아니다. 업무 정책·법규·시장·사용 행태·기술 제약이 달라지고, 검증·확인과 설계 과정에서 새로운 사실이 드러나며, 가정이 틀렸거나 이해관계자 사이 충돌이 늦게 확인될 수 있다. 변경을 모두 실패로 보아 막으면 오래된 요구를 정확하게 구현하게 된다. 반대로 모든 요청을 즉시 반영하면 범위와 기준선이 의미를 잃는다.
변경 관리는 변화를 없애는 절차가 아니라, 제안된 차이를 현재 기준선과 비교하고 가치·비용·일정·위험을 평가해 권한 있는 결정을 내리며 그 결과를 추적하는 통제다. [NASA의 요구사항 변경 관리 지침](https://swehb.nasa.gov/spaces/7150/pages/16449679/SWE-053%2B-%2BManage%2BRequirements%2BChanges)은 요청을 구조화해 제출·평가·결정·기준선 반영하고, 승인 전에 기술·비용·일정과 관련 산출물의 영향을 분석하도록 설명한다.
변경 원인을 분류하면 대응이 달라진다.
| 원인 | 예 | 관리 초점 |
|---|---|---|
| 외부 의무 변화 | 학사 규정·개인정보 정책 개정 | 발효일, 공식 출처, 준수 범위 |
| 이해관계자 필요 변화 | 대상 학생·업무 과업 변화 | 가치, 대표성, 범위와 수용 조건 |
| 가정·근거 변화 | `ASM-001` 기각 또는 기준선 자료 확보 | 파생 요구와 목표값 재평가 |
| 결함 발견 | 모호성·누락·충돌·시험 불가능 | 원인, 수정 범위, 회귀 검토 |
| 해결 학습 | 설계·프로토타입에서 제약 발견 | 요구와 설계 경계, 대안 비교 |
| 운영 피드백 | 보류 적체·반복 제출·문의 증가 | 실제 데이터, 긴급 통제와 장기 변경 |
작은 오탈자 수정과 의미 변경을 구분하되, “작은 화면 문구”가 상태 의미나 법적 고지를 바꾸면 정식 변경이다. 변경 규모보다 업무 결과·외부 계약·시험 판정 기준·기준선에 미치는 영향으로 통제 수준을 정한다.
변경 제안의 접수·영향·대안·결정과 후속 조치를 한 기록으로 남기려면 부록 H. 변경요청서 예제를 사용할 수 있다. 요청 ID가 생겼다는 사실과 변경이 승인됐다는 결정을 구분해야 한다.
### 2. 변경 요청
변경 요청은 해결안을 지시하는 한 줄 메모가 아니라 무엇을 왜 바꾸려는지 평가할 수 있게 만드는 관리 항목이다. 요청자는 문제·기회와 원하는 결과를 설명하고, 분석자는 현재 기준선과 대안을 검토한다. 요청서가 완전한 요구사항일 필요는 없지만 최소 정보 없이는 영향 분석을 시작하지 않는다.
이 장의 관통 사례 `CR-003`은 다음과 같은 **후보 요청**이다.
| 항목 | `CR-003` 기록 후보 |
|---|---|
| 제목 | 졸업 예정자 수강신청 우선 정책 제안 |
| 요청 내용 | 정해진 조건의 졸업 예정자가 졸업 필수 강좌를 신청할 때 우선권을 적용하자는 제안 |
| 요청자·권한 | 실제 요청 조직과 정책 제안 권한 확인 필요 |
| 대상 기준선 | 현재 원고는 후보 상태이므로 실제 기준선 ID 없음; 교육용 분석에서 가상 기준선 사용 |
| 대상 요구 | `RULE-005`, `FR-001`, 관련 `RULE-004``·QR·DR·IR·UI` |
| 희망 적용 | 다음 학기라는 가정; 정책 발효일과 개발 가능 시점 확인 필요 |
| 기대효과 | 졸업 지연 위험 감소 가능성; 근거 자료와 측정법 필요 |
| 미결 | 졸업 예정 정의, 대상 강좌, 동순위, 좌석·이의 제기·오류 정정 정책 |
| 상태 | 제출 후보 / 분석 자료 미완료 / 승인 아님 |
요청에 ID를 부여하면 접수·중복·상태·결정을 추적할 수 있지만 승인되는 것은 아니다. 같은 문제를 다른 사람이 제기하면 무조건 새 요청으로 만들지 않고 중복·관련·대체 관계를 확인한다. 긴급 장애 우회도 사후 요청과 만료 조건을 만들어 영구 정책으로 굳지 않게 한다.
변경요청서의 최소 필드는 요청 ID, 제목, 요청자와 날짜, 문제·기회, 제안 차이, 대상 버전, 근거 자료, 희망 시점, 영향받을 사용자, 긴급성, 결정 책임자다. 분석 중 발견한 범위·대안·비용·위험은 덧붙이되 요청자의 추정을 사실로 바꾸지 않는다.
### 3. 변경 사유
변경 사유는 “사용자 요청”, “정책 변경”, “개선”보다 구체적이어야 한다. 관찰된 문제, 공식 의무 또는 기대효과를 현재 상태와 비교한다. 해결안이 아닌 필요를 먼저 검증해야 다른 대안을 비교할 수 있다.
`CR-003`에는 “졸업 예정자가 필요한 강좌를 얻지 못해 졸업이 지연된다”는 문제가 암묵적으로 들어 있다. 하지만 이 원고에는 해당 건수, 강좌별 수용량, 대체 과목, 수강 실패 원인이나 기존 예외 처리 자료가 없다. 따라서 사유를 확정하지 않고 다음 증거를 요청한다.
- 최근 학기의 졸업 예정 판정 기준과 대상자 규모
- 필수 강좌 미수강으로 졸업이 지연된 사례와 원인 분류
- 강좌별 수요·좌석·대기·취소·증원 자료와 시간대
- 현행 우선배정·예외승인·학과 조정 정책과 실제 처리시간
- 다른 학생 집단에 미치는 분배 영향과 공정성 기준
- 잘못된 졸업 예정 데이터의 정정·이의 제기 사례
증거가 문제를 지지해도 “절대 우선권”이 유일한 답은 아니다. 졸업 필수 강좌의 좌석 확보, 별도 신청 기간, 대기열 우선 조정, 학과 승인, 수요에 따른 분반 확대 같은 대안이 있을 수 있다. 변경 사유는 해결안을 정당화하기 위한 문구가 아니라 대안을 평가할 기준을 제공해야 한다.
사유와 기대효과에는 측정 가능한 결과를 연결한다. 졸업 지연 감소, 필수 강좌 확보율, 수동 예외처리, 이의 제기, 다른 학생의 접근성 변화 등을 후보로 두되 기준선과 목표값은 정책 책임자가 자료로 합의한다.
### 4. 영향 분석
영향 분석은 28장의 양방향 추적 경로를 따라 “무엇이 관련 있는가”를 찾고, 각 항목에 어떤 차이와 재작업이 생기는지 판정한다. 분석 대상은 문서뿐 아니라 사용자, 업무 절차, 데이터 원천, 외부기관, 운영, 교육과 출시 순서다.
먼저 요청 문구를 하나의 해결안으로 고정하지 않고 대안을 같은 기준으로 비교한다.
| 대안 후보 | 개념 | 기대 효과 | 주요 확인점 |
|---|---|---|---|
| A. 일반 신청 내 우선순위 | 같은 신청 흐름에서 졸업 예정자를 먼저 배정 | 별도 절차 없이 필수 강좌 확보 가능 | 동순위·마지막 좌석·다른 학생 영향 |
| B. 대상 강좌 좌석 예약 | 일부 좌석을 정한 기간·집단에 보존 | 필수 강좌에 범위를 좁힐 수 있음 | 미사용 좌석 반환·예약 규모·악용 |
| C. 별도 기간·대기 조정 | 사전 신청 또는 대기열에서 우선 처리 | 피크 경쟁과 정책 설명을 분리 가능 | 운영 복잡성·중복 신청·기간 접근성 |
| D. 현행 유지와 예외 절차 개선 | 자동 우선권 없이 증원·승인·상담을 개선 | 데이터·규칙 변경을 줄일 수 있음 | 수동 부담·일관성·처리시간·감사 |
비교 기준은 졸업 지연 위험 감소, 다른 학생의 기회 변화, 정책 설명 가능성, 데이터 정확성 요구, 동시성 안전, 운영 부담, 비용·일정과 되돌리기 용이성이다. 대안 A가 요청 문구와 가장 가깝다는 이유로 기본안이 되는 것은 아니다. 문제 자료가 확보되면 필요한 강좌·기간·대상에 맞춰 조합하거나 시범 적용할 수도 있다.
`CR-003`의 영향 분석표 후보는 다음과 같다.
| 대상 | 예상 변화 질문 | 판정 후보 | 필요한 증거·결정 |
|---|---|---|---|
| `RULE-005` | 우선 대상·강좌·기간·동순위·예외는? | 직접 수정 | 공식 정책 원문·결정자 |
| `FR-001` | 판정 입력·순서·사유가 바뀌는가? | 직접 수정 가능 | 대안별 판정 모델 |
| `QR-003` | 우선권과 수용량 금지를 동시에 보장하는가? | 재검토·재시험 | 동시성·좌석 할당 방식 |
| `DR-002``·003` | 졸업 예정 상태·기준 시점·판정 이력을 더 기록하는가? | 직접 수정 가능 | 최소 데이터·보존 목적 |
| `IR-003` | 학사정보가 공식 졸업 예정 상태를 제공하는가? | 계약 변경 가능 | 필드·갱신·정정·장애 계약 |
| `IR-004` | 규칙 버전·우선순위 사유를 반환하는가? | 계약 변경 가능 | 공개·내부 사유 구분 |
| `UI-001`, `FR-003` | 우선 적용·미적용과 이의 경로를 어떻게 설명하는가? | 수정 가능 | 사용자 확인·접근성 |
| `SCR-STATUS-01` | 상태·사유·정정 안내가 달라지는가? | 설계 항목 재검토 | 화면 흐름 후보 |
| `API-STATUS-01` | 새 공개 필드가 필요한가? | 미정 | 개인정보·업무 필요성 |
| 시험 항목 | 우선·비우선 동시 신청, 오류·경계가 추가되는가? | 재설계·재시험 | 정책 판정 기준·합성 데이터 |
| 운영·지원 | 데이터 오류·이의·수동 조정 절차가 필요한가? | 직접 변화 가능 | 역할·처리시간·감사 |
“영향 있음”에서 멈추지 않고 수정, 재검토, 재시험, 통지, 영향 없음, 판단 보류로 분류한다. 예를 들어 `IR-005` 알림은 메시지 내용이 바뀔 수 있지만 전달 방식은 그대로일 수 있다. 반면 학사정보의 졸업 예정 상태가 늦게 갱신되면 판정 자체가 틀릴 수 있어 `IR-003`은 핵심 의존성이다.
영향 분석 완료 조건은 모든 링크를 펼쳤다는 것이 아니다. 적용 범위와 대안별 차이가 설명되고, 판단 보류 항목의 책임자·기한·결정 전 위험이 있으며, 비용·일정·위험 추정의 가정이 기록돼야 한다.
### 5. 비용
변경 비용은 개발 공수만이 아니다. 요구 재분석, 정책 합의, 데이터 계약, 설계·코드, 시험, 개인정보·접근성 검토, 이관, 교육·공지, 운영 지원과 향후 유지비를 포함한다. 변경하지 않을 때의 비용과 기회비용도 비교한다.
`CR-003`의 비용 구조 후보:
| 비용 범주 | 포함 항목 |
|---|---|
| 조사·정책 | 근거 자료 수집, 대상·예외·공정성 합의, 법무·개인정보 검토 |
| 데이터·연계 | 졸업 예정 상태 제공, 기준 시점·정정·대사·장애 계약 |
| 요구·설계 | 규칙·상태·사유·화면·API·데이터 모델 수정과 리뷰 |
| 구현·검증 | 규칙 엔진, 동시성, 마이그레이션, 단위·통합·부하·접근성 시험 |
| 운영 전환 | 배포 순서, 모니터링, 지원 절차, 교육·공지·이의 처리 |
| 지속 비용 | 매 학기 정책·대상 갱신, 데이터 품질, 감사·문의·예외 처리 |
| 변경하지 않을 때의 비용 | 졸업 지연·수동 조정이 실제로 존재할 경우의 영향 |
자료가 없으므로 금액이나 인월을 발명하지 않는다. 범위·작업분해·의존성·추정 가정과 불확실성 구간을 먼저 만든다. 대안별 공통 비용과 차등 비용을 분리하면 한 대안에만 조사·운영비를 몰아 비교를 왜곡하지 않는다.
매몰비용은 승인 근거가 아니다. 이미 화면을 만들었더라도 필요와 정책이 틀리면 재평가한다. 반대로 변경 가치가 크더라도 예산·인력·외부 계약이 준비되지 않으면 적용 시점을 조정하거나 단계적 대안을 택할 수 있다.
### 6. 일정
일정 영향은 “개발 2주”처럼 구현 기간만 더하는 것이 아니다. 정책 결정, 데이터 준비, 외부기관 계약, 검토·확인, 구현, 통합·부하 시험, 공지와 운영 준비의 선후관계를 본다. 학사 정책은 학기 개시·수강신청 공지·데이터 확정 같은 되돌리기 어려운 날짜를 가진다.
`CR-003`의 일정상 의사결정 지점 후보는 다음과 같다.
1. 정책 근거와 결정권자 확인
2. 대상·예외·공정성·이의 처리 합의
3. 졸업 예정 데이터 원천·기준 시점·정정 계약 확정
4. 요구 변경 검증·확인과 기준선 승인
5. 설계·구현 및 외부 연계 준비
6. 규칙 경계·동시성·데이터 오류·접근성·운영 시험
7. 공지·교육·배포·복구 계획 준비
8. 적용 전 데이터 대사와 출시 판단
희망 적용일에서 역산해 필수 결정이 늦어지면 범위를 줄이거나 다음 학기로 미룰 조건을 둔다. 품질 활동을 일정 막바지로 몰지 않는다. 정책이 확정되지 않은 채 코드를 먼저 만들면 시험 판정 기준과 공지 내용이 바뀌어 재작업이 커진다.
긴급성과 중요성을 구분한다. 다음 학기 공지 마감이 가깝다는 사실은 문제 근거와 안전성을 대체하지 않는다. 임시 운영 절차를 택한다면 대상·권한·만료일·수동 대사와 장기 해결 전환 조건을 명시한다.
### 7. 위험
변경 위험은 변경을 했을 때와 하지 않았을 때를 함께 본다. 승인 여부를 정당화하려고 한쪽 위험만 부풀리지 않는다.
| 위험 | 원인·사건 | 영향 | 대응 후보 |
|---|---|---|---|
| 공정성 | 우선 대상·강좌 범위가 과도하거나 근거 부족 | 다른 학생 기회 감소·이의 | 정책 기준 공개·영향 시뮬레이션 |
| 데이터 오류 | 졸업 예정 상태가 오래되거나 잘못됨 | 부당한 우선·배제 | 기준 원천·기준 시점·정정·재판정 |
| 개인정보 | 졸업 예정 여부를 불필요하게 노출 | 민감한 학적 추론 | 최소 처리·역할별 공개·감사 |
| 동시성 | 우선순위와 마지막 좌석 처리 충돌 | 초과 배정·순서 불일치 | 원자적 배정·정책 판정 기준·부하 시험 |
| 운영 과부하 | 오류·예외·이의 처리 경로 미비 | 수동 재처리·문의 증가 | 운영 시뮬레이션·처리 권한·SLA |
| 일정 압박 | 정책·데이터 확정 전 구현 | 재작업·결함·잘못된 공지 | 게이트·중단 조건·단계적 적용 |
| 변경하지 않음 | 실제 졸업 지연 문제가 지속 | 학생 피해·수동 예외 지속 | 기준선 조사·임시 통제 비교 |
위험에는 가능성·영향뿐 아니라 근거, 탐지 지표, 소유자, 통제와 잔여 위험을 둔다. “높음”으로 표시하고 책임자가 없으면 결정 자료가 되지 않는다. 안전·개인정보·법적 의무는 다수결이나 일정 압박으로 수용할 수 없는 경계가 있을 수 있으므로 권한을 구분한다.
### 8. 승인
승인은 요청자가 원한다는 확인이나 회의 참석자의 묵시적 동의가 아니다. 분석된 특정 변경 버전과 대안, 비용·일정·위험, 적용 기준선에 대해 권한 있는 사람이 결정을 기록하는 행위다. [IIBA 요구사항 생명주기 관리 공식 항목](https://www.iiba.org/knowledgehub/the-business-analysis-standard/5-applying-business-analysis-tasks/5-3-business-analysis-knowledge-areas/requirements-and-designs-life-cycle-management/)도 변경평가와 요구 승인 활동을 구분해 제시한다.
`CR-003`을 승인하려면 적어도 다음이 필요하다.
- 문제와 기대효과를 지지하는 자료, 적용 범위와 제외 범위
- 졸업 예정자·대상 강좌·우선순위·동순위·예외의 공식 정책
- 데이터 원천·기준 시점·정정·이의 처리 책임
- 수용량·공정성·개인정보·접근성·운영 위험과 통제
- 선택 대안, 배제 대안과 결정 근거
- 비용·일정·외부 의존성, 적용·중단 조건
- 바뀔 요구와 버전, 재검증·재확인·시험 범위
- 승인 권한, 결정일, 유효 기간과 재검토 조건
현재 원고에는 이 자료가 없으므로 `CR-003`은 승인할 수 있는 상태가 아니다. 교육용 사례 분석이라는 이유로 가상 승인을 실제 결정처럼 기록하지 않는다. 이후 절과 30장의 상태 전이는 가능한 결정 흐름을 설명하는 예시다.
조건부 승인을 쓴다면 조건, 충족 증거, 확인자, 기한과 미충족 시 효력을 명시한다. “세부는 추후”는 조건이 아니라 불확실성의 이전이다.
### 9. 반려
반려는 요청을 지우거나 요청자를 설득하지 못한 사람으로 남기는 일이 아니다. 특정 기준선과 시점에서 선택하지 않은 이유, 검토한 대안, 재제출 조건과 관련 위험을 보존하는 결정이다. 같은 요청이 반복될 때 과거 근거를 재사용하고 무엇이 달라졌는지 비교할 수 있어야 한다.
반려 사유는 다음처럼 구체화한다.
- 문제·기대효과의 증거가 부족함
- 제안 해결이 목표에 비해 비용·위험이 과도함
- 다른 승인 대안이 같은 필요를 더 잘 충족함
- 정책·법적 권한 또는 외부 의존성이 충족되지 않음
- 현재 기준선·일정에는 부적합하지만 재검토 시점이 있음
- 이미 다른 요청·요구에서 처리돼 중복임
`CR-003`은 자료 미비라면 최종 반려보다 “추가 정보 요청” 또는 “보류”가 적절할 수 있다. 반려와 보류를 구분해 상태를 남긴다. 반려된 요청도 삭제하지 않고 `RULE-005`, `RULE-004`, `ISS-001`과 연결해 이후 정책 자료가 들어올 때 재검토한다.
### 10. 변경 이력
변경 이력은 최신 문장만 보여 주는 수정 기록이 아니다. 누가 언제 무엇을 왜 바꾸었고, 어떤 근거와 권한으로 어느 기준선에 반영했는지 복원한다. 요구 본문, 속성, 관계, 상태와 변경 요청의 이력을 서로 연결한다.
| 시점 | 항목·버전 | 변화 | 사유·요청 | 결정·상태 |
|---|---|---|---|---|
| 교육용 현재 | `RULE-005`` v0.x` | 우선순위 배정 정책 후보 | 출처·예외 확인 필요 | 후보, `ISS-001` 미해결 |
| 요청 접수 후보 | `CR-003`` v0.1` | 졸업 예정자 우선 제안 등록 | 문제 자료 요청 | 분석 대기 |
| 분석 갱신 후보 | `CR-003`` v0.2` | 범위·대안·영향표 추가 | 추적·정책 검토 | 승인 아님 |
| 향후 결정 | 결정 시점의 버전 | 승인·반려·보류 중 하나 | 권한·근거 필요 | 실제 결정 전 빈칸 |
이 표는 실제로 승인·구현된 이력이 아니라 사례의 관리 구조다. 실제 결정이 생기면 날짜, 결정자, 원문, 변경 전후 차이와 포함 기준선을 기록한다. 이전 값을 덮어쓰지 않고 비교할 수 있게 한다.
변경 이력에는 영향 분석과 실제 변경 결과의 차이도 남긴다. 예상 밖 산출물이 바뀌거나 재시험이 누락됐다면 추적 규칙과 검토 체크리스트를 개선한다. 단순 활동 로그보다 결정과 재현에 필요한 정보가 우선이다.
### 11. 기준선
기준선은 권한 있는 검토를 거쳐 특정 목적에 사용하기로 합의하고 변경 통제 아래 둔 산출물·버전의 집합이다. 문서 파일을 복사한 날짜나 “최신” 폴더와 다르다. 무엇이 포함됐고 어떤 조건으로 승인됐으며 이후 어떻게 바꿀지를 명확히 한다.
| 기준선 요소 | 기록 내용 |
|---|---|
| ID·목적 | 예: 다음 학기 설계 입력 기준선 `BL-ENR-01` 후보 |
| 구성 | 포함 요구·모델·용어·규칙·인터페이스와 각 버전 |
| 제외·미결 항목 | 승인되지 않은 `RULE-005`, 가정, 조건부 예외 |
| 승인 | 권한, 날짜, 검토·확인 증거와 조건 |
| 효력 | 적용 릴리스·학기·계약·조직 |
| 변경 규칙 | 요청 유형, 영향 분석, 승인 권한, 긴급 절차 |
| 무결성 | 해시·태그·읽기 권한·보관 위치와 복원 방법 |
현재 수강신청 원고는 실제 이해관계자 승인을 받지 않았으므로 `BL-ENR-01`은 형식 예시일 뿐 실제 기준선이 아니다. 후보 요구와 미결 정책을 기준선에 포함할 수는 있지만 승인됨과 혼동하지 않게 조건·제외·해결 기한을 명시해야 한다.
`CR-003`이 승인되면 기존 기준선을 수정하는 대신 새 기준선 버전을 만든다. 어느 출시가 어느 기준선을 사용했는지 유지해야 운영 결함과 시험 결과를 당시 규칙으로 재현할 수 있다. 최신 기준선만 남기면 과거 판정의 적법성·정확성을 설명할 수 없다.
### 12. 형상관리
형상관리는 기준선을 이루는 요구·모델·인터페이스·설계·시험·운영 문서의 식별, 버전, 변경 통제, 상태 보고와 감사를 일관되게 운영하는 체계다. 요구사항 관리 도구 하나를 구매하거나 파일 이름에 날짜를 넣는 것과 같지 않다.
최소 흐름은 다음과 같다.
형상 항목마다 고유 ID, 버전, 소유자, 저장 위치, 상태, 기준선 포함 여부와 접근권한을 둔다. 변경 권한과 승인 권한을 분리할 수 있고, 긴급 변경도 사후 검토·기준선 반영·만료를 피하지 않는다. 최신본을 배포하는 것뿐 아니라 잘못 배포된 버전을 식별하고 이전 상태로 복구할 수 있어야 한다.
형상 상태 보고는 미결 요청, 승인·반려·보류, 구현·검증 상태, 기준선 차이와 미적용 변경을 보여 준다. 감사는 기록이 많다는 확인이 아니라 실제 사용 중인 요구·설계·시험이 선언한 기준선과 일치하고 모든 승인 변경이 완결됐는지 확인한다.
이 장에서 정리한 결과는 **`CR-003` 변경요청서**, **영향 분석표**, **대안·비용·일정·위험 비교**, **결정 및 기준선 이력**이다. 도구 화면보다 상태 전이 조건, 책임, 근거와 감사 가능성이 중심이다. 다음 장에서는 요청과 요구가 제안·분석·승인·구현·검증·변경·보류·폐기 사이를 어떻게 이동하는지 하나의 생명주기로 정리한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 29장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
변경 요청의 필요성·영향·비용·위험과 대안을 비교하고 근거 없는 승인이나 가상 수치를 만들지 않는다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.