---
title: "16장. 좋은 요구사항의 품질"
description: "개별 문장과 요구 집합의 정확성·완전성·일관성·명확성·검증 가능성을 근거와 반례로 점검한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
정확성·명확성·완전성·일관성·검증 가능성을 어떤 증거로 판단하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “정확성·명확성·완전성·일관성·검증 가능성을 어떤 증거로 판단하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
문법이 매끄러운 요구사항도 틀리거나 불완전할 수 있다. 개별 문장은 명확해 보여도 요구 집합 전체에서 서로 충돌하거나 필요한 예외와 품질 조건이 빠질 수 있으며, 출처가 없는 수치가 정답처럼 자리 잡기도 한다. 품질 검토는 맞춤법 검사가 아니라 의도와 증거의 점검이다.
이 장에서는 정확성·완전성·일관성·명확성·실현 가능성·검증 가능성을 기준으로 요구사항을 평가한다. 체크리스트에만 의존하지 않고 반례, 경계 사례, 모델과 시험 관점을 사용해 결함을 찾고, 수정·확인·보류 상태로 관리하는 방법을 살펴본다.
### 1. 필요성
15장의 템플릿에 맞는 문장도 필요 없는 요구일 수 있다. “인증된 학생이 조회하면 시스템은 2초 안에 파란색 진행 막대를 표시해야 한다”는 조건·주체·동작·수치가 있지만, 진행 막대가 어떤 목표를 지원하는지 근거가 없고 특정 디자인을 강제한다. 좋은 요구인지는 문장 모양이 아니라 필요·근거·관계와 함께 판정한다.
품질은 **개별 요구**와 **요구 집합**의 두 수준으로 나눈다. 개별 요구는 한 문장의 필요성·정확성·명확성·실현·검증 가능성 등을 보고, 집합은 전체 목표를 빠짐없이 지원하는지, 서로 모순되지 않는지, 경계와 관계가 이어지는지를 본다. 모든 속성을 한 문장에 우겨 넣지 않고 문장, 속성 필드, 용어집, 모델, 출처와 검토 기록을 함께 사용한다.
필요성은 그 요구가 권한 있는 필요·목표·상위 요구·정책 또는 위험 통제에 기여하며, 없애면 설명 가능한 손실이 생기는 성질이다. 요청자가 원한다는 사실만으로 충분하지 않다. `UR-001`은 학생의 결과 불확실성을 줄여 `G-01`을 지원하지만, 반복 제출과 수동 재처리 감소에 실제로 얼마나 기여하는지는 `ASM-001` 확인이 필요하다. `DR-001`은 사용자 화면에 보이지 않아도 결과 설명·복구·감사를 가능하게 하므로 필요 근거가 있다.
개별 요구에 묻는다.
- 어느 목표·상위 요구·규정·위험에서 왔는가?
- 이 요구를 제외하면 어떤 이해관계자 결과나 통제가 손실되는가?
- 같은 필요를 이미 다른 요구가 충족하는가?
- 필요의 근거와 결정 권한이 현재 유효한가?
집합에서는 목표에 연결되지 않은 고아 요구와, 목표는 있지만 실현할 하위 요구가 없는 빈 가지를 함께 찾는다. 개인화 추천처럼 `G-01`과 직접 근거가 약한 후보는 잘 썼더라도 이번 범위의 필요성을 통과하지 못할 수 있다. 판정은 `충족/결함/근거 확인 전/해당 없음`으로 기록하고 출처를 붙인다.
이 장의 품질 기준을 실제 검토 기록으로 옮길 때는 부록 C. 요구사항 품질 점검표를 사용할 수 있다. 모든 칸을 형식적으로 채우기보다 대상 요구의 위험과 상태에 맞는 기준을 선택한다.
### 2. 정확성
정확성은 요구가 권한 있는 업무 사실, 규칙, 데이터 의미와 합의된 이해를 바르게 표현하는 성질이다. 이해관계자의 머릿속 필요와 일치하는지를 기계적으로 증명할 수는 없으므로, 여기서는 참조할 수 있는 정책·용어·사례·결정 기록과의 일치로 판정한다. IREB 자료가 `정확성`보다 이해관계자의 필요에 적합한지를 뜻하는 `적절성`을 강조하는 이유도 이 경계를 보여 준다. 이 장에서는 목차의 정확성을 사용하되 필요성·타당성 검토와 혼동하지 않는다.
“최대 18학점까지 신청할 수 있다”는 문장은 명확해 보여도 `RULE-002`의 권한 있는 정책이 21학점이거나 학생 유형별 한도가 다르면 정확하지 않다. “정원이 없으면 거절한다”도 `RULE-004`의 적용 정원이나 `RULE-005`의 예약·우선 배정 예외가 있다면 일부 조건에서 틀리다. 구현이 문장대로 동작해도 업무적으로 잘못된 시스템이 된다.
정확성 검토의 최소 증거는 다음과 같다.
| 대상 | 대조할 근거 |
|---|---|
| 용어·상태 | 용어집, 상태 모델, 업무 사례 |
| 규칙·수치 | 최신 권한 문서, 발효일·버전, 결정자 |
| 데이터 | 원천 시스템 정의, 코드표, 표본 값과 정정 절차 |
| 예외 | 승인 권한, 과거 사례, 적용 범위 |
| 품질 목표 | 사용자·운영 영향, 기준선, 시험·비용 근거 |
검토자는 “그럴듯하다”가 아니라 어느 근거의 어느 버전과 일치하는지 기록한다. `SRC-POL-01`의 최신성이나 `RULE-001–RULE-005`의 세부 출처가 미확인이라면 정확하다고 승인하지 않고 `근거 확인 전`으로 둔다. 출처끼리 다르면 문장을 편집하지 말고 `ISS-001` 같은 쟁점으로 되돌린다.
### 3. 명확성
명확성은 의도한 독자가 요구를 한 가지 의미로 이해하는 성질이다. 쉬운 단어만 썼다고 명확하지 않다. 주체·조건·동작·결과·수량이 특정되고, 용어와 참조가 일관되어야 한다. [IREB 용어집](https://cpre.ireb.org/en/downloads-and-resources/glossary)은 비모호성을 서로 다른 사람들이 요구를 다르게 이해할 수 없는 정도로 설명한다.
다음 두 문장을 두 검토자가 읽는 상황을 보자.
> 신청이 완료되면 시스템은 결과를 즉시 제공해야 한다.
검토자 A는 `완료=요청 접수`, `결과=접수 번호`, `즉시=화면 전환 전`으로 읽을 수 있다. 검토자 B는 `완료=규칙 판정과 정원 반영`, `결과=승인·거절과 사유`, `즉시=2초 이내`로 읽을 수 있다. 문법에는 문제가 없지만 의미가 갈린다.
다음처럼 분리해 고친다.
- 요청을 유효하게 수신하면 시스템은 신청 식별자와 접수 상태를 제공해야 한다.
- 판정이 종료되면 시스템은 승인 또는 거절 상태와 적용된 사유를 제공해야 한다.
- 상태 조회 성능은 `QR-001`의 부하·측정 조건과 p95 기준으로 별도 정의한다.
명확성은 작성자가 설명해 주면 이해되는가로 판정하지 않는다. 두 검토자가 독립적으로 적용 조건, 예상 결과, 시험 예를 적어 비교한다. 차이가 있으면 단어·생략 조건·외부 참조 중 원인을 찾는다. 용어집에 `접수`, `판정 중`, `보류`, `승인`, `거절`, `취소`의 정의와 허용 전이를 두면 문장 길이를 늘리지 않고 해석을 맞출 수 있다.
### 4. 완전성
완전성은 필요한 정보가 빠지지 않은 성질이다. 개별 문장 완전성과 집합 완전성은 다르다. 한 문장은 조건·주체·행동·대상·결과·제약 중 그 의무를 판정하는 데 필요한 요소를 가져야 한다. 집합은 목표·범위와 중요 시나리오를 충족할 요구가 빠짐없이 있고, 필요한 관계·정의·출처를 포함해야 한다.
`IR-001`의 “규칙 서비스 실패 시 보류한다”는 개별 문장으로는 실패 조건, 주체, 자동 승인 금지, 보류·원인 결과를 적을 수 있다. 그러나 집합 수준에서는 보류의 좌석 점유, 학생 조회, 재평가 주체·기한, 끝내 판정하지 못했을 때의 종료, 정원·규칙이 바뀐 경우가 빠져 있다. 한 문장을 길게 만들어 모두 넣기보다 원자적 요구와 상태 모델로 묶는다.
완전성은 무한한 미래를 모두 명세한다는 뜻이 아니다. 11장의 범위와 중요 위험을 기준으로 합리적인 경계를 정한다. 다음 보기를 대조한다.
- 목표와 상위 요구: `G-01`, `BR-001`을 실현할 하위 요구가 있는가?
- 업무 흐름: 조회·신청·판정·결과·취소·복구가 시작부터 종료까지 이어지는가?
- 상태와 예외: 정상, 경계, 실패, 되돌림과 수동 처리가 있는가?
- 이해관계자: 학생·정책·운영·지원 관점이 빠지지 않았는가?
- 데이터와 인터페이스: 원천·기준 시점·오류·보존·책임이 있는가?
- 품질과 검증: 성능뿐 아니라 정확성·보안·접근성·감사와 시험 조건이 있는가?
빠진 항목을 발견하면 즉시 문장을 발명하지 않는다. 출처, 필요, 결정권자와 상태가 있는 요구 후보로 만들고 10장–14장의 분석·범위·합의로 되돌린다. 완전성 결함은 작성 기술만으로 해결되지 않는다.
### 5. 일관성
일관성은 요구들이 같은 조건에서 서로 모순되지 않고, 용어·단위·상태·참조와 추상 수준이 맞는 성질이다. 주로 요구 집합의 품질이지만 한 문장 안에서도 조건과 결과가 어긋날 수 있다. IREB CPRE Foundation 자료는 여러 요구를 담은 작업 산출물의 품질에서 서로 모순되지 않는 것을 중요한 기준으로 다룬다.
수강신청 요구 모음에서는 다음 충돌을 찾는다.
| 요구 A | 요구 B | 일관성 질문 |
|---|---|---|
| 정원 0이면 모든 신청을 거절 | `RULE-005` 우선 대상 배정 | 별도·예약 정원인가, `RULE-004`의 정원 한도를 바꾸는가? |
| 규칙 서비스 실패 시 `IR-001` 보류 | 모든 신청은 2초 안에 확정 결과 | 보류도 확정 결과인가, 두 요구가 충돌하는가? |
| 취소 즉시 좌석 반환 | 보류가 좌석을 점유한다는 가정 | 반환·예약·재배정의 원자적 시점은? |
| 승인 결과는 변경 불가 | 권한 있는 담당자는 오류 판정을 정정 | 정정이 새 상태 전이인지 예외 덮어쓰기인지? |
| `DR-001`은 규칙 버전 기록 | 외부 규칙 서비스는 버전을 제공하지 않음 `ASM-002` | 기록 요구를 어떻게 실현할 것인가? |
문장 표현을 흐려 충돌을 없애지 않는다. “가능하면 2초 안에 적절한 결과를 준다”는 일관적인 요구가 아니라 결정을 숨긴 문장이다. 적용 조건을 분리할 수 있는지, 실제 정책 우선순위가 무엇인지, 대안 중 무엇이 선택되었는지를 `DEC-001` 같은 결정 기록과 연결한다.
일관성 검토에는 용어표, 상태 전이, 결정표, 관계표와 단위 사전이 유용하다. 같은 숫자가 다른 관측 지점을 쓰거나, 같은 상태가 다른 종료 의미를 갖는지도 모순이다. 해결 뒤에는 양쪽 요구와 관련 시험을 함께 갱신한다.
### 6. 실행 가능성
실행 가능성은 알려진 기술·정책·법률·일정·비용·조직 능력 안에서 요구를 구현하고 운영할 현실적인 경로가 있는 성질이다. 어렵거나 비싸다는 이유만으로 실행 불가능한 것은 아니며, 근거 없이 “할 수 있다”는 개발자의 낙관도 판정이 아니다.
“어떤 장애에서도 모든 신청을 2초 안에 정확히 확정한다”는 문장은 외부 규칙 서비스의 지연·무응답과 충돌한다. 현재 안전 원칙 `IR-001`은 유효한 규칙 결과가 없을 때 자동 승인하지 않고 보류한다. 즉시 확정, 최신 규칙, 무제한 가용성을 모두 절대 조건으로 두면 함께 만족할 방법이 없을 수 있다. 이때 품질 목표를 조용히 낮추지 말고 대안을 비교한다.
- 확정이 불가능하면 접수·보류 상태와 다음 행동을 빠르게 제공한다.
- 승인된 규칙 스냅샷을 사용할 수 있는 정책·최신성 조건을 정한다.
- 고위험 예외는 수동 판정으로 보내고 처리 기한·권한을 명시한다.
- 부하·장애 시제품으로 응답시간과 정원 일관성을 조기에 검증한다.
실행 가능성의 증거는 시제품·부하 시험, 외부 인터페이스 계약, 정책·법률 검토, 비용·일정 추정, 운영 인력과 복구 훈련이다. 요구 자체와 선택한 설계의 실행 가능성을 구분한다. 한 설계가 어렵다고 필요를 폐기하지 않고 다른 설계를 찾는다. 반대로 검증 환경이나 운영 책임을 확보할 수 없다면 위험과 결정 기한을 기록한다.
집합 수준에서는 선행관계와 총자원도 본다. 각 요구가 따로 가능해도 같은 학기·예산에 모두 구현할 수 없다면 집합이 실행 가능하지 않다. 13장의 조건부 우선순위와 Must 집합을 비용·인력·외부 일정에 대조한다.
### 7. 검증 가능성
검증 가능성은 구현된 시스템이 요구를 충족하는지 객관적인 증거로 판정할 수 있는 성질이다. 명확성은 무엇을 뜻하는지에 관한 품질이고, 검증 가능성은 그 뜻이 실현되었는지 확인할 방법이 있는가에 관한 품질이다. 명확한 “학생이 만족해야 한다”도 사용자·과업·평가 기준이 없으면 검증하기 어렵다.
요구를 작성할 때 검증 개념을 함께 적는다.
| 요구 후보 | 검증 방법 | 필요한 조건·증거 | 합격 판정 |
|---|---|---|---|
| `QR-001` 상태 조회 p95 2초 | 부하 시험 | 합의된 부하·데이터·측정 경계, 충분한 표본 | 정의한 p95가 2초 이하이고 동반 오류 기준 충족 |
| `IR-001` 자동 승인 금지 | 장애 주입·상태 검사 | 시간 초과·무효·오래된 응답 사례 | 어떤 실패 사례에서도 승인 상태가 없고 보류·원인이 기록됨 |
| `DR-001` 판정 이력 | 기록 검사·재현 | 표본 신청, 규칙 버전, 상태 전이 | 필수 필드가 있고 결과를 원천까지 추적 가능 |
| 취소 후보 | 시나리오·상태 전이 시험 | 취소 가능·불가 상태, 동시 요청 | 허용 상태만 취소되고 정원·이력 결과가 정책과 일치 |
검증은 시험·검사·분석·시연과 운영 데이터 평가를 조합할 수 있다. 관찰 지점, 입력·환경, 예상 결과, 허용 오차와 판정 주체가 분명해야 한다. “충분히 빠른지 확인한다”는 검증 계획이 아니다.
요구를 시험하기 위해 구현 내부를 과도하게 지정하지 않는다. 외부에서 관찰할 수 없으면 필요한 계측·감사 인터페이스를 파생 요구 후보로 만들 수 있다. 데이터·환경을 구할 수 없다면 검증 가능성과 실행 가능성 모두에 결함이 있다. [IREB CPRE 자료](https://cpre.ireb.org/en/downloads-and-resources/downloads)는 구현된 시스템의 요구 충족 여부를 명확하게 확인할 수 있는지를 검증 가능성의 핵심으로 다룬다.
### 8. 추적 가능성
추적 가능성은 요구를 그 기원, 상위·하위 요구, 관련 결정, 구현·시험과 변경 영향에 연결할 수 있는 성질이다. 링크 수가 많은 것이 아니라 필요한 질문에 답할 수 있는 관계가 있어야 한다. [IREB 용어집](https://cpre.ireb.org/en/downloads-and-resources/glossary)은 요구를 기원으로 거슬러 올라가고 구현·시험으로 내려가며 의존 요구를 따라갈 수 있는 능력으로 추적성을 설명한다.
사례의 추적 사슬은 다음처럼 구성한다.
`BR-001`의 50% 목표는 `SRC-LOG-01`의 기준선 정의와 `ASM-001`, `ASM-004` 검증 없이는 근거가 약하다. `DR-001`의 규칙 버전은 `ASM-002` 확인에 기대고, `ISS-001`의 해결은 `DEC-001`의 정책 결정과 연결된다. 이러한 불확실성도 추적 대상이다.
개별 요구에는 고유 ID, 출처, 상위 목표, 상태와 검증 참조가 있어야 한다. 집합에서는 고아 요구, 끊긴 상위·하위 연결, 오래된 결정·시험 링크를 찾는다. 양방향 링크가 있다는 사실보다 변경 질문을 시험한다. `RULE-004`가 바뀌면 어떤 판정 문장, 상태·사유, 대기명단, 시험과 운영 안내가 영향을 받는지 실제로 찾을 수 있어야 한다.
### 9. 원자성
원자성은 요구가 하나의 핵심 의무를 표현해 독립적으로 이해·우선순위·승인·변경·검증할 수 있는 성질이다. 15장의 작성 규칙을 품질 판정으로 다시 본 것이다. 문장이 짧거나 접속사가 없다고 원자적인 것은 아니다. 반대로 하나의 결과를 완성하는 여러 필드가 있다고 반드시 비원자적인 것도 아니다.
다음 문장은 비원자적이다.
> 시스템은 신청을 승인하고 학생에게 푸시 알림을 보내며 관리자가 모든 기록을 엑셀로 내려받게 해야 한다.
승인, 외부 알림, 관리자 내보내기는 실패 형태·우선순위·보안·검증이 다르다. 승인됐지만 알림이 실패하거나 내보내기만 제외할 수 있으므로 나눈다. 또한 `푸시`, `엑셀`은 필요 근거 없이 설계를 고정한다.
원자성 판정 질문은 다음과 같다.
- 문장의 일부만 구현하거나 통과할 수 있는가?
- 포함된 행동들의 조건·주체·결과·실패가 다른가?
- 부분별 우선순위·변경 권한·출처가 다른가?
- 하나의 시험 결과로 전체 의무를 판정할 수 있는가?
- 나눈 뒤 상위 목적과 업무 결과가 끊기지 않는가?
지나친 분해도 피한다. “신청 ID를 생성한다”와 “신청 ID를 반환한다”가 하나의 승인 결과를 이루고 항상 같은 조건·원자적 처리로 검증된다면 함께 둘 근거가 있다. 원자성은 단어 수가 아니라 독립적인 의사결정 경계다. 집합에서는 분해된 요구들이 상위 요구를 함께 충족하는지도 완전성·추적성으로 검토한다.
### 10. 구현 독립성
구현 독립성은 요구가 필요 이상의 설계·기술 선택을 강제하지 않으면서 필요한 결과와 정당한 제약을 표현하는 성질이다. “특정 기술을 언급하지 않는다”는 절대 규칙이 아니다. 법률·조직 표준·외부 계약·상호운용성처럼 선택할 수 없는 제약은 출처와 범위를 붙여 요구에 포함할 수 있다.
| 설계에 치우친 문장 | 필요 중심 후보 | 확인할 정당한 제약 |
|---|---|---|
| Redis 캐시에서 상태를 조회한다 | `QR-001`의 운영 조건에서 상태 조회 응답 기준을 충족한다 | 기존 플랫폼 의무, 데이터 최신성 |
| Kafka 큐에 실패 요청을 넣는다 | 판정 불가 신청을 유실 없이 보류하고 재평가 가능하게 기록한다 | 승인된 메시징 표준, 복구 목표 |
| 초록색 팝업으로 승인 표시 | 학생에게 승인 상태와 신청 식별자를 인지 가능하게 제공한다 | 접근성·브랜드·채널 제약 |
| 엑셀 파일로 이력을 제공 | 권한 있는 운영자가 정의된 신청 이력을 분석 가능한 형태로 얻는다 | 실제 업무 도구·보안·상호운용 형식 |
구현 독립성을 높인다고 요구를 추상적인 희망으로 되돌리면 안 된다. “최적의 기술로 빠르게 제공한다”는 독립적인 것이 아니라 모호한 것이다. 관찰 가능한 조건·결과·측정 기준은 유지하고, 여러 대안에서 달성 가능한 수단만 열어 둔다.
검토자는 기술 이름이 정책·계약의 필수 제약인지, 승인된 결정인지, 한 설계안의 편의인지 묻는다. 근거가 없다면 설계 후보로 옮긴다. 기술 이름을 제거해도 필요한 결과와 검증 기준이 남아야 한다.
[INCOSE Guide to Writing Requirements](https://portal.incose.org/Web/iCore/Store/StoreLayouts/Item_Detail.aspx?Category=EBOOKS&iProductCode=GUIDEWRITEREQ) v4(2023)는 개별 요구와 요구 집합의 특성·작성 규칙을 함께 다룬다. [ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html)도 적용할 판본과 확인 날짜를 기준선에 기록한다.
두 동료 검토자가 같은 기준을 적용할 수 있도록 리뷰 기록을 다음처럼 만든다.
| 필드 | 기록 내용 |
|---|---|
| 대상 | 요구 ID·버전·기준선 |
| 속성 | 필요성부터 구현 독립성까지 적용한 품질 |
| 판정 | 충족 / 결함 / 근거 확인 전 / 해당 없음 |
| 근거 | 문제 구절, 출처·규칙·모델·시험 참조 |
| 반례 | 결함을 드러내는 입력·경계·실패 상황 |
| 영향 | 목표·사용자·설계·시험·운영에 생기는 결과 |
| 조치 | 문장 수정, 분해, 추가 도출, 정책 결정, 시제품 등 |
| 책임·기한 | 확인·승인 주체와 재검토 시점 |
예를 들어 두 검토자에게 “합의된 부하 시험 환경에서 인증된 학생이 자신의 신청 상태를 조회하면, 시스템은 성공 요청의 p95를 2초 이하로 유지해야 한다”는 `QR-001` 후보를 준다. 둘 다 필요성을 `근거 확인 전`, 명확성을 `결함`, 검증 가능성을 `근거 확인 전`으로 판정해야 한다. 이유는 2초 목표의 승인 근거, 부하 환경·측정 경계·오류 기준이 아직 없기 때문이다. 한 사람만 결함으로 본다면 판정 규칙이나 제공된 참조가 불충분한지 회고한다.
검토 순서는 `ID·상태 확인 → 개별 문장 품질 → 관련 요구와 집합 품질 → 반례·검증 개념 → 결함 유형과 조치 → 재검토`다. 체크 표시 수를 품질 점수로 합산하지 않는다. 필요성이나 정확성이 결함인 요구는 문체를 다듬기 전에 분석으로 돌리고, 집합 일관성은 한 문장 수정만으로 닫지 않는다.
5부의 결과는 개선된 문장, 문장 구조 템플릿, 품질 속성표와 근거가 있는 리뷰 기록이다. `BR-001`·`QR-001`의 수치, `RULE-001–RULE-005`, `ASM-001–ASM-004`, `ISS-001`과 `DEC-001`의 상태는 그대로 추적된다. 6부로 넘길 질문은 세 가지다.
1. 자연어 한 문장으로 충분한 정보와 여러 단계·예외가 필요한 정보를 어떻게 구분할 것인가?
2. 같은 요구를 유스케이스·사용자 스토리·상태·데이터·결정 모델로 표현할 때 어떤 정보가 늘거나 사라지는가?
3. 여러 표현을 함께 사용할 때 중복된 진실과 서로 다른 버전이 생기지 않도록 어떻게 연결할 것인가?
좋은 요구사항은 열 가지 형용사를 붙인 문장이 아니다. 근거가 있고 같은 의미로 이해되며, 빠짐없이 서로 맞고 실현·검증·추적할 수 있는 요구와 그 집합이다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 16장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
개별 문장과 요구 집합의 정확성·완전성·일관성·명확성·검증 가능성을 근거와 반례로 점검한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
이 장의 판단을 실제 작업 순서로 적용합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.