---
title: "25장. 요구사항 검증"
description: "요구사항이 잘 작성됐는지 검증하기 위해 리뷰·분석·모델·시험 설계와 결함 기록을 요구 버전에 연결한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
요구사항 문서 자체의 결함을 구현 전에 어떻게 찾아내는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “요구사항 문서 자체의 결함을 구현 전에 어떻게 찾아내는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
잘 작성된 것처럼 보이는 요구사항도 실제로 구현 가능한지, 서로 일관되는지, 시험할 수 있는지는 별도로 확인해야 한다. 요구사항 검증을 문서 승인 절차로만 처리하면 결함의 근거와 수정 결과가 남지 않고, 뒤 단계에서 발견된 문제가 어느 버전에서 시작됐는지 추적하기 어렵다.
이 장에서는 리뷰·분석·모델 확인·시험 설계를 조합해 요구사항의 품질을 검증한다. 역할과 진입·종료 조건을 정하고 결함을 요구 버전에 연결하며, 지적 사항이 수정·합의·보류 중 어느 상태인지 증거와 함께 관리하는 방법을 살펴본다.
### 1. 품질 검사
요구사항 검증은 작성된 요구사항이 올바른 형식과 충분한 품질을 갖추었는지 객관적으로 살피는 일이다. 이 장에서는 “요구사항을 제대로 정의했는가”를 검증의 중심 질문으로 삼는다. 다음 장의 요구사항 확인은 “그 요구사항이 이해관계자의 필요와 기대효과를 충족하는가”를 묻는다. 두 활동은 서로 보완하지만 질문과 증거가 다르다.
| 구분 | 요구사항 검증 | 요구사항 확인 |
|---|---|---|
| 주된 대상 | 요구사항 문장, 모델, 목록과 연결 관계 | 필요, 사용 맥락, 업무 결과와 제안된 해결 방향 |
| 중심 질문 | 명확하고 일관되며 완전하고 시험 가능한가? | 실제 사용 목적과 기대효과에 맞는가? |
| 대표 활동 | 동료 검토, 검사, 분석, 추적성 점검 | 시나리오, 프로토타입, 워크스루, 업무 시뮬레이션 |
| 대표 증거 | 결함 기록, 수정 이력, 품질 체크리스트 | 관찰 기록, 수용 조건, 합의·미합의 목록 |
| 주의할 오해 | 구현된 소프트웨어 시험만을 뜻하지 않는다 | 서명이나 화면 선호 조사만을 뜻하지 않는다 |
표준과 조직마다 verification과 validation의 번역 및 적용 범위에는 차이가 있다. 따라서 프로젝트 시작 때 용어표에 이 구분을 기록하고, 외부 표준을 인용할 때는 그 표준의 원문 의미를 함께 확인한다. [IIBA의 Verify Requirements 공식 설명](https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/7-requirements-analysis-and-design-definition/7-2-verify-requirements/)은 요구사항이 올바르게 정의되고 사용할 만한 품질인지 확인하는 활동을 다룬다. Validate Requirements는 다음 장의 공식 링크에서 별도로 확인한다. [ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html)은 요구공학의 절차와 산출물, 좋은 요구사항의 특성을 다루는 기준이다. [IREB CPRE 공식 자료](https://cpre.ireb.org/en/downloads-and-resources/downloads)의 강의계획서와 용어집도 프로젝트 용어와 품질 기준을 맞추는 참고 기준으로 사용할 수 있다.
품질 검사는 문서를 다 쓴 뒤 한 번 여는 교정 회의가 아니다. 요구사항 묶음이 작을 때 반복해야 결함의 전파 비용이 작다. 이번 수강신청 사례에서는 21장–24장에서 만든 `FR`, `QR`, `DR`, `IR` 후보를 한 기준선으로 묶되, 아직 승인되지 않은 값과 가정은 그대로 표시한다. 검사 계획에는 다음이 필요하다.
1. **범위와 기준선**: 어떤 버전의 요구사항·모델·용어집·근거 자료를 검사하는가.
2. **진입 조건**: 식별자, 소유자, 상태, 출처, 측정 기준이 최소한 채워졌는가.
3. **역할**: 작성자, 진행자, 검토자, 기록자와 결함 처리 책임자는 누구인가.
4. **검사 관점**: 업무, 사용자, 데이터, 인터페이스, 품질, 운영 관점을 누가 맡는가.
5. **결함 등급**: 의미 오류, 누락, 충돌, 모호성, 추적 단절과 편집 오류를 어떻게 구분하는가.
6. **종료 조건**: 중대 결함이 해소되고 보류 결함에 책임자·기한·영향이 기록됐는가.
“검토 완료”는 회의를 열었다는 뜻이 아니다. 발견한 결함이 수정됐고, 수정이 다른 요구사항을 깨뜨리지 않았으며, 남은 예외가 의식적으로 수용됐다는 증거가 있어야 한다. 산출물은 **검증 계획**, **품질 체크리스트**, **검토 기록**이다.
리뷰 회의의 준비·역할·쟁점·종료 조건은 부록 I. 요구사항 리뷰 체크리스트로 운영할 수 있다. 검토할 내용의 품질 기준이 필요하면 부록 I에서 연결하는 부록 C를 함께 사용한다.
### 2. 명확성
명확한 요구사항은 관련 독자가 같은 의미로 해석할 가능성이 높다. 문법이 매끄러운 것만으로는 부족하다. 행위 주체, 촉발 조건, 대상, 기대 결과, 제약과 예외가 드러나야 한다. “신속하게”, “적절히”, “가능하면”, “사용자 친화적으로”처럼 판단 기준이 없는 말은 검토자가 서로 다른 결과를 상상하게 한다.
`FR-003` 후보를 예로 보자.
> 나쁜 예: 시스템은 학생에게 신청 결과를 빠르고 알기 쉽게 알려야 한다.
> 개선 후보: 수강신청 시스템은 인증된 학생이 자신의 신청을 조회할 때 승인·거절·보류 중 현재 상태, 공개 가능한 사유, 신청 식별자와 가능한 다음 행동을 제공해야 한다. 상태 조회 응답시간은 `QR-001`의 측정 조건을 따른다.
개선 문장은 “빠르게”를 다른 품질 요구에 연결하고, 결과가 무엇인지와 누가 볼 수 있는지를 드러낸다. 그러나 이것만으로 완성되지는 않는다. “현재”의 기준 시점, 공개 가능한 사유의 분류, 다음 행동의 정책은 데이터·보안·업무 규칙과 대조해야 한다.
명확성 검사는 단어 찾기로 끝나지 않는다. 서로 다른 역할의 검토자에게 요구사항을 읽고 다음을 독립적으로 적게 한다.
- 성공 결과와 실패 결과는 무엇인가?
- 언제 요구가 적용되고 언제 적용되지 않는가?
- 눈으로 보거나 측정할 수 있는 증거는 무엇인가?
- 알 수 없는 값이나 외부 책임은 무엇인가?
답이 크게 다르면 문장이 짧더라도 모호하다. 용어집도 함께 검사한다. “접수”, “신청”, “판정”, “승인”, “확정”, “통지”가 문서마다 바뀌면 화면과 데이터 상태가 어긋난다. 이 사례에서는 접수와 최종 판정을 구분하고, 알림 전달 여부가 공식 신청 상태를 바꾸지 않는다고 명시한다.
### 3. 일관성
일관성은 모든 문장을 같은 형태로 쓰는 것이 아니라 두 요구가 동시에 참일 수 있게 하는 성질이다. 한 요구 안의 수치·조건뿐 아니라 기능, 품질, 데이터, 인터페이스, 정책과 모델 사이를 검사한다. 이름은 같은데 뜻이 다른 의미 충돌과, 뜻은 같은데 이름이 다른 중복도 결함이다.
수강신청 묶음에는 다음 교차 검사가 필요하다.
| 검사 쌍 | 충돌 가능성 | 판단할 질문 |
|---|---|---|
| `FR-003` 결과 조회 ↔ `IR-005` 알림 | 알림 실패를 신청 실패로 오해 | 공식 상태는 어디에 있고 통지는 보조 채널인가? |
| `QR-002` 가용성 ↔ `IR-001` 안전 보류 | 보류를 장애 또는 정상 서비스로 다르게 집계 | 조회 가능·제출 가능·자동 판정 가능을 따로 측정하는가? |
| `RULE-004` 수용량 보호 ↔ `RULE-005` 우선순위 | 마지막 좌석의 배정 순서가 불명확 | 우선순위 적용 시점과 동시 요청 조정 규칙이 있는가? |
| `DR-005` 보존·개인정보 ↔ `QR-009` 감사성 | 감사라는 이유로 무기한 보존 | 목적별 보존기간·접근권한·파기 증거가 있는가? |
| `FR-005` 취소 ↔ 지연된 `IR-001` 응답 | 취소 뒤 늦은 승인이 상태를 덮음 | 판정 시도와 현재 상태를 대조하는가? |
특히 `ISS-001`은 “수용량을 넘기지 않는다”와 “우선순위에 따라 배정한다”가 마지막 좌석에서 어떻게 함께 성립하는지 정하지 못한 쟁점이다. 검토자가 임의로 결론을 내리지 않고 정책 책임자에게 보낸다. 답을 받기 전에는 관련 요구를 승인 상태로 바꾸지 않는다.
수치도 일관되게 읽어야 한다. `QR-001`의 p95 2초는 상태 조회라는 기능, 정의된 부하 시험 환경, 측정 구간과 제외 조건을 가진 후보 목표다. 이를 모든 화면이나 전체 신청 완료시간에 적용하면 다른 요구로 변한다. 단위, 모집단, 백분위, 측정 창과 시간대를 대조해 같은 숫자의 의미가 이동하지 않게 한다.
### 4. 완전성
완전성은 문서에 가능한 모든 내용을 넣는다는 뜻이 아니다. 승인된 범위 안에서 의사결정·설계·검증에 필요한 정보가 빠지지 않았고, 아직 모르는 것은 미결 항목으로 관리된 상태다. 빈칸을 임의의 숫자나 그럴듯한 정책으로 채우면 겉보기만 완전해진다.
한 요구의 완전성은 주체, 조건, 입력, 결과, 예외, 품질, 데이터와 외부 의존성을 본다. 요구사항 묶음의 완전성은 다음 축을 교차한다.
- **사용자와 역할**: 일반 학생, 접근성 보조기술 사용자, 학사 담당자, 운영자, 정책 책임자의 과업이 있는가.
- **상태와 생명주기**: 접수, 보류, 승인, 거절, 취소와 종료되지 않은 보류의 처리 조건이 있는가.
- **정상·대안·예외 흐름**: 규칙 미충족, 중복 제출, 외부 시간 초과, 늦은 응답, 기록 실패가 있는가.
- **데이터**: 기준 원천, 기준 시점, 품질 규칙, 이력, 보존·파기와 이관 대사가 있는가.
- **인터페이스**: 인증, 학사정보, 규칙, 알림의 책임과 오류 의미가 연결되는가.
- **품질**: 성능뿐 아니라 가용성, 회복, 보안, 개인정보, 접근성, 감사성과 운영성이 있는가.
- **범위 경계**: 결제처럼 필요가 확인되지 않은 기능을 억지로 넣지 않았는가.
예를 들어 `IR-001`이 규칙 서비스 실패 때 보류하도록 했어도 보류를 언제 재평가하고, 학생에게 무엇을 보여 주고, 끝내 판정할 수 없을 때 누가 어떤 기준으로 종료하는지가 없으면 생명주기가 완전하지 않다. 반대로 그 정책이 아직 합의되지 않았다면 요구 문장을 창작하지 않고 “정책 책임자, 결정 기한, 미결 시 영향”을 미결 항목에 기록한다.
완전성 검사에는 범위 밖도 필요하다. 현재 사례에서는 실제 결제 필요가 확인되지 않았다. 결제 인터페이스를 넣지 않았다는 사실은 누락이 아니라 경계 결정이다. 근거와 재검토 조건을 남겨야 나중에 누락과 의도적 제외를 구분할 수 있다.
### 5. 추적성
추적성은 식별자 사이에 링크를 많이 만드는 일이 아니라 결정의 이유와 영향, 검증 증거를 오갈 수 있게 하는 능력이다. 상향 추적은 요구가 어떤 목표·필요·근거에서 나왔는지 보여 주고, 하향 추적은 어떤 설계·시험·운영 지표가 이를 실현하고 증명하는지 보여 준다. 양방향 링크가 있어야 변경 영향과 고아 요구를 찾을 수 있다.
수강신청 사례의 최소 연결은 다음과 같다.
이 연결은 모두 승인됐다는 뜻이 아니다. `BR-001`과 `QR-001`은 기준선과 측정 환경이 확인되지 않은 후보 목표이며, `ASM-001`은 반복 제출이 수동 재처리의 큰 원인이라는 가정, `ASM-004`는 과거 자료가 비교 가능한 기준선이라는 가정이다. 링크에는 상태와 버전을 보존해야 “가정에서 파생된 요구”를 승인된 사실로 읽지 않는다.
추적성 검사는 네 가지 예외를 찾는다.
1. 출처·목표가 없는 **고아 요구**
2. 하위 요구나 검증 방법이 없는 **막다른 목표**
3. 폐기된 규칙 버전을 가리키는 **낡은 링크**
4. 같은 근거를 중복 복사한 뒤 서로 다르게 수정한 **불일치 복사본**
검토 기록에도 추적성을 둔다. 결함 ID가 영향을 받은 요구와 수정 버전을 가리키고, 다시 검사한 사람이 결과를 남긴다. 링크 개수보다 “왜 필요한가, 무엇이 영향을 받는가, 어떤 증거로 닫는가”에 답할 수 있는지가 중요하다.
### 6. 검증 가능성
검증 가능한 요구사항은 충족 여부를 유한한 비용과 합의된 방법으로 판단할 수 있다. “최고의”, “안전한”, “충분한” 같은 표현은 비교 기준과 관찰 방법이 없으면 판정할 수 없다. 기능 요구도 기대 결과가 보이지 않거나 외부 상태가 통제되지 않으면 검증하기 어렵다.
여기서 두 층을 구분한다.
- **요구사항 산출물의 검증**: 지금 작성한 문장이 품질 기준에 맞는지 검사한다.
- **제품의 요구 충족 검증**: 구현 후 분석·검사·시연·시험 등으로 제품이 그 문장을 만족하는지 객관적 증거를 얻는다.
이 장의 주제는 첫째지만, 둘째 방법을 미리 상상해야 문장의 검증 가능성을 판단할 수 있다. [NASA Systems Engineering Handbook의 검증·확인 지침](https://www.nasa.gov/reference/system-engineering-handbook-appendix/)은 분석, 검사, 시연, 시험 같은 방법과 검증 계획·행렬을 사용해 준수 증거를 관리하도록 설명한다.
각 요구에는 다음 정보를 연결한다.
| 항목 | 질문 |
|---|---|
| 방법 | 분석, 문서·구성 검사, 시연, 시험 중 무엇으로 판단하는가? |
| 환경 | 운영과 어떤 점이 같고 다른 조건에서 수행하는가? |
| 자극·데이터 | 어떤 입력, 상태, 경계값과 실패를 준비하는가? |
| 관찰 대상 | 화면, API, 데이터 이력, 로그와 운영 지표 중 무엇을 보는가? |
| 판정 기준 | 기대값, 허용오차, 임계치와 금지 결과는 무엇인가? |
| 반복성 | 같은 조건에서 다른 검토자도 같은 결론을 내릴 수 있는가? |
`IR-001`의 검증 후보를 예로 들면, 규칙 서비스가 정상 응답·명시적 오류·무효 응답·시간 초과·늦은 성공을 돌려주는 조건을 만든다. 신청이 자동 승인되지 않고 보류되며 원인 코드와 판정 시도가 `DR-001`에 연결되는지를 관찰한다. 단, 이 시험 설계가 가능하다는 사실만으로 보류 경험이 학생과 학사 운영에 적절한지는 알 수 없다. 그 질문은 26장의 시나리오와 업무 시뮬레이션에서 다룬다.
`QR-001`도 “2초”만으로 검증 가능하지 않다. 측정 시작·종료점, 동시 사용자와 데이터 규모, 워밍업, 표본 수, 백분위 계산, 외부 서비스 상태, 오류 응답 포함 여부와 반복 횟수가 있어야 한다. 목표값이 임시라면 시험은 가능해도 계약 판정은 보류한다.
### 7. 리뷰
리뷰는 관점이 다른 사람이 산출물을 체계적으로 읽고 결함과 질문을 기록하는 활동이다. 회의에서 처음 문서를 읽거나, 작성자가 설명으로 빈 문장을 보완하거나, 고위 책임자가 서명하는 것만으로는 충분하지 않다. 설명이 없어도 기준선 문서가 같은 의미를 전달해야 한다.
이번 사례의 동료 검토는 다음 흐름으로 운영한다.
1. **계획**: `FR-001–FR-005`, `QR-001–QR-011`, `DR-001–DR-006`, `IR-001–IR-006`과 관련 규칙·가정을 범위로 정한다.
2. **개요 공유**: 작성자가 목표·경계·용어·미해결 쟁점을 짧게 설명하되 결함 답을 즉석에서 강요하지 않는다.
3. **개별 준비**: 검토자는 맡은 관점으로 읽고 위치, 기대 기준, 관찰 사실, 영향과 질문을 기록한다.
4. **검토 회의**: 새 해결책 설계보다 결함의 존재·등급·소유자와 처리 기한을 합의한다.
5. **재작업**: 작성자가 수정하고 변경으로 영향을 받는 연결 요구까지 점검한다.
6. **후속 확인**: 진행자나 지정 검토자가 수정 증거를 확인하고 닫거나 다시 연다.
역할별 관점도 분명히 한다. 학생 대표는 상태·사유와 다음 행동을, 학사 담당자는 규칙·예외·운영 책임을, 개발·시험 담당자는 경계·검증 가능성을, 데이터 담당자는 원천·이력·보존을, 운영·보안·접근성 담당자는 장애·관측·권한·다양한 사용 조건을 살핀다. 모든 사람을 한 회의에 오래 묶기보다 개별 준비와 쟁점별 짧은 회의를 조합한다.
검토 기록 예시는 다음과 같다.
| 결함 ID | 대상 | 관찰 사실 | 등급 | 처리 | 상태 |
|---|---|---|---|---|---|
| `DEF-001` | `IR-001` | 보류 재평가·종료 조건 없음 | 중대 누락 | 정책 책임자에게 결정 요청 | 미해결 |
| `DEF-002` | `FR-003`, `IR-005` | 통지 실패가 판정에 미치는 영향 불명확 | 의미 충돌 | 공식 상태와 보조 채널 구분 | 수정 확인 |
| `DEF-003` | `QR-001` | 부하·표본·측정 구간 미정 | 검증성 | 성능 측정 계약 후보 작성 | 미해결 |
| `DEF-004` | `DR-005`, `QR-009` | 감사 이력 보존기간 불명확 | 개인정보 위험 | 목적별 보존 정책 확인 | 미해결 |
중대 결함이 열려 있으면 전체 묶음을 승인 상태로 바꾸지 않는다. 일정 때문에 보류 결함을 수용한다면 결정권자, 위험, 임시 통제, 만료일과 재검토 조건을 기록한다.
### 8. 체크리스트
체크리스트는 생각을 대신하는 채점표가 아니라 반복해서 놓치는 결함을 드러내는 기억 장치다. 모든 항목을 “예”로 만들기 위해 내용을 꾸미지 않는다. 답은 **예 / 아니요 / 해당 없음 / 확인 필요**로 기록하고, 해당 없음에는 근거를, 확인 필요에는 책임자와 기한을 둔다.
#### 요구사항 품질 체크리스트
| 범주 | 확인 질문 |
|---|---|
| 식별·상태 | 고유 ID, 버전, 소유자, 후보·승인·폐기 상태가 있는가? |
| 근거 | 목표·필요·규정·관찰 또는 명시된 가정으로 상향 추적되는가? |
| 단일성 | 한 문장에 독립적으로 변경될 여러 요구를 묶지 않았는가? |
| 명확성 | 주체·조건·대상·결과와 용어가 독립 독자에게 같은 뜻인가? |
| 일관성 | 관련 기능·품질·데이터·인터페이스·규칙과 동시에 성립하는가? |
| 완전성 | 정상·대안·오류·경계·상태 종료와 외부 책임을 다뤘는가? |
| 필요성 | 범위와 목표에 기여하며, 단순한 구현 선호를 요구로 위장하지 않았는가? |
| 실현 가능성 | 기술·운영·정책·일정 제약 안에서 가능하며 위험이 드러났는가? |
| 검증 가능성 | 방법·환경·입력·관찰 대상·판정 기준을 정할 수 있는가? |
| 추적성 | 하위 산출물·검증 증거와 변경 영향으로 내려갈 수 있는가? |
| 품질·데이터 | 측정 기준, 원천·기준 시점, 개인정보·보존 조건을 빠뜨리지 않았는가? |
| 인터페이스 | 상대 책임, 실패·시간 초과·중복·버전·재처리 의미가 있는가? |
체크리스트 수행 결과는 요약 점수보다 결함 목록으로 남긴다. 예컨대 95% 통과했더라도 마지막 좌석을 초과 배정할 수 있는 한 건의 충돌은 치명적일 수 있다. 반대로 편집 오류 여러 건이 핵심 정책 결함보다 우선하지 않는다. 위험과 영향으로 처리 순서를 정한다.
25장의 검증 계획 초안은 다음처럼 정리할 수 있다.
| 항목 | 이번 기준선 후보 |
|---|---|
| 대상 | [21장](/learn/specification-modeling/chapter-21)–[24장](/learn/specification-modeling/chapter-24)의 `FR·QR·DR·IR`, 관련 `RULE·ASM·ISS·DEC` |
| 기준 | 명확성, 일관성, 완전성, 추적성, 필요성, 실현 가능성, 검증 가능성 |
| 방법 | 관점별 동료 검토, 추적성 분석, 상태·용어·수치 교차검사 |
| 진입 | ID·상태·근거 표시, 미결 항목 목록, 기준선 버전 고정 |
| 종료 | 중대 결함 해소, 보류 항목의 소유자·기한·영향 기록, 후속 확인 완료 |
| 기록 | 검토 일시·참여 관점·결함·수정 버전·재검사 결과 |
검증을 마치면 다음 장으로 질문을 넘긴다. 문장이 완벽하게 명확해도 학생이 보류 사유를 이해하지 못하거나 학사 담당자의 첫 30분 업무가 줄지 않는다면 올바른 해결 요구가 아니다. 반대로 이해관계자가 좋아한 프로토타입이라도 개인정보·동시성·예외 조건이 명세되지 않았다면 개발 기준으로 사용할 수 없다. 두 활동의 증거를 함께 충족할 때 요구사항 기준선의 신뢰도가 높아진다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 25장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
요구사항이 잘 작성됐는지 검증하기 위해 리뷰·분석·모델·시험 설계와 결함 기록을 요구 버전에 연결한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.