---
title: "26장. 요구사항 확인"
description: "요구사항이 실제 사용자와 업무 목적에 맞는지 프로토타입·시나리오·사용자 피드백으로 확인한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
작성된 요구가 실제 이해관계자의 필요와 사용 맥락에 맞는지 어떻게 확인하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “작성된 요구가 실제 이해관계자의 필요와 사용 맥락에 맞는지 어떻게 확인하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
요구사항이 명확하고 일관되더라도 실제 사용자와 업무 목적에 맞지 않을 수 있다. 분석가와 개발자가 같은 문장을 이해했다는 사실은 올바른 문제를 풀고 있다는 증거가 아니다. 늦은 인수 단계에서야 기대와 다름을 발견하면 문서뿐 아니라 설계와 구현까지 되돌려야 한다.
이 장에서는 시나리오, 프로토타입, 사용자 평가와 수용 관점을 활용해 요구사항을 타당화한다. 누구의 어떤 필요를 어떤 환경에서 확인할지 정하고 피드백을 요구 후보와 결정에 연결해, 보기 좋은 시연이 아니라 실제 업무 적합성을 검증하는 방법을 다룬다.
### 1. 이해관계자 확인
요구사항 확인은 잘 쓴 문장을 승인받는 절차가 아니다. 제안한 요구사항이 실제 이해관계자의 필요와 사용 목적을 충족하고, 기대한 업무 효과를 만들며, 해결 범위 안에 있는지 증거로 판단하는 활동이다. 25장이 “요구사항을 제대로 정의했는가”를 물었다면 이 장은 “제대로 된 요구사항을 정의했는가”를 묻는다.
[IIBA의 Validate Requirements 공식 설명](https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/7-requirements-analysis-and-design-definition/7-3-validate-requirements/)은 요구사항이 기대효과를 지원하고 해결 범위와 맞는지를 확인하는 활동으로 설명한다. [NASA의 제품 실현 지침](https://www.nasa.gov/reference/5-0-product-realization/)도 검증을 명시된 요구의 준수 증거, 확인을 고객·사용자의 기대와 의도된 환경에서의 사용 증거로 구분한다. 이 책은 그 실무 구분을 사용한다. 다른 조직의 용어가 다르면 번역어만 맞추지 말고 질문·대상·증거를 대응시킨다.
수강신청 사례의 이해관계자는 발주자 한 명이나 평균적인 학생 한 명이 아니다.
| 관점 | 참여 후보 | 확인할 필요와 위험 |
|---|---|---|
| 학생 | 신입·재학생, 복수전공, 장애학생, 모바일·보조기술 사용자 | 신청 결과 이해, 다음 행동, 시간 압박, 접근성 |
| 학사 업무 | 담당자, 정책 책임자, 학과 승인자, 학생지원 창구 | 규칙 적용, 예외 처리, 문의·재처리, 책임 경계 |
| 운영 | 서비스 운영, 장애 대응, 데이터 정정 담당 | 피크 부하, 보류 적체, 복구, 관측과 감사 |
| 통제 | 개인정보, 보안, 접근성, 감사 담당 | 최소 수집, 권한, 설명 가능성, 준수 증거 |
| 외부 연계 | 인증·학사정보·규칙·알림 제공 책임자 | 데이터 의미, 장애, 지연, 변경과 지원 책임 |
참여자는 직함보다 영향을 기준으로 고른다. 가장 불편을 크게 겪거나 예외를 처리하는 사람이 빠지면 다수 의견으로 요구를 “확인”해도 실제 실패가 남는다. 의사결정권자와 실제 사용자를 구분하고, 참여하지 못한 집단은 대리인이 누구인지와 한계를 기록한다.
확인 계획에는 대상 요구, 이해관계자, 사용 맥락, 기법, 관찰할 행동과 결과, 결정 기준을 둔다. `ASM-001`처럼 반복 제출이 수동 재처리의 중요한 원인이라는 가정은 설문 동의로 닫지 않는다. 제출 로그와 문의·재처리 기록을 연결하고, 사용자가 왜 반복했는지 관찰해 사실 여부를 판단한다. `BR-001`의 50% 감소도 기준선이 확인되기 전에는 승인된 목표가 아니라 측정 가능한 후보다.
### 2. 시나리오 검증
이 절의 제목은 목차의 “시나리오 검증”을 따르지만, 여기서 시나리오는 25장의 문장 품질 검사가 아니라 **요구사항 확인**에 쓰인다. 실제 사용 맥락을 구체화해 제안한 요구가 필요와 결과에 맞는지 살피는 시나리오 기반 확인이다.
시나리오는 화면 순서만 적지 않는다. 목표, 참여자, 맥락, 사전조건, 과업, 사건, 기대 업무 결과와 관찰 항목을 묶는다.
| 항목 | 기록 내용 |
|---|---|
| 확인 질문 | 어떤 필요·가정·가치를 판단하려는가? |
| 참여자·맥락 | 누가, 어떤 기기·환경·시간 압박과 권한에서 수행하는가? |
| 사전조건 | 학적, 수강 이력, 강좌 상태, 정책 버전은 무엇인가? |
| 과업 | 참여자에게 달성할 목표를 어떻게 제시하는가? |
| 사건·변형 | 거절, 보류, 중복, 취소, 외부 장애와 동시 요청 중 무엇을 넣는가? |
| 관찰 | 행동, 질문, 오류 회복, 소요시간, 문의·수작업과 신뢰 신호를 어떻게 남기는가? |
| 판정 | 요구 유지·수정·제외, 가정 확인·기각, 추가 조사 중 무엇인가? |
`VAL-SCN-01` 후보는 “규칙 서비스가 응답하지 않는 신청”이다. 학생은 인기 강좌를 신청하지만 시스템은 `IR-001`에 따라 자동 승인하지 않고 보류한다. 참여자에게 화면 기능을 설명하지 않고 “신청이 정상적으로 접수됐는지 확인하고 필요한 다음 행동을 하라”고 과업을 준다. 보류가 거절과 다름을 이해하는지, 다시 제출하는지, 사유·신청 ID·예상 다음 상태를 찾는지, 도움을 요청하는지를 관찰한다.
같은 `IR-001`을 두 장에서 다르게 다룬다.
| 관점 | 질문 | 증거 |
|---|---|---|
| [25장](/learn/validation-management/chapter-25) 검증 | 시간 초과 때 자동 승인 없이 보류한다고 명확하고 시험 가능하게 썼는가? | 요구 문장, 상태 모델, 시험 방법, 결함 기록 |
| 26장 확인 | 안전 보류가 학생과 운영의 실제 목적을 해치지 않으며 회복 가능한가? | 학생 행동, 반복 제출, 문의, 보류 적체, 재평가 결과 |
시나리오는 정상 성공만으로 구성하지 않는다. 선수과목 미충족 거절, 마지막 좌석의 동시 신청, 동일 버튼 반복, 판정 중 취소, 취소 뒤 늦은 응답, 알림 유실, 학사정보 정정과 보조기술 사용을 변형으로 둔다. 모든 조합을 한 번에 시험하지 않고 위험·빈도·불확실성이 높은 시나리오부터 선택한다.
진행자가 “이해되시죠?”라고 묻거나 기대 행동을 가르치면 확인 증거가 약해진다. 참여자가 말한 의견과 실제 행동을 구분하고, 관찰 사실과 해석도 분리한다. 한 사람이 막혔다는 사실은 원인이 아니므로 후속 질문과 여러 자료로 설명을 보강한다.
### 3. 프로토타입
프로토타입은 요구를 빨리 확인하기 위한 학습 도구다. 완성품을 미리 예쁘게 그리는 일이 아니다. 확인 질문에 맞춰 충실도를 선택한다. 상태 이름과 정보 순서를 물을 때는 종이 스케치로 충분할 수 있고, 중복 제출·보류·취소의 시간 흐름을 보려면 클릭 가능한 상태 프로토타입이 필요하다. 응답시간이나 대규모 동시성은 화면 프로토타입으로 확인할 수 없다.
이번 사례의 프로토타입 범위는 다음처럼 제한한다.
- 강좌 선택과 신청 의도 확인
- 접수 ID와 접수·판정 상태의 구분
- 승인·거절·보류의 사유와 다음 행동
- 판정 중 취소 가능 여부와 충돌 결과 탐색 — `ASM-003`과 취소 정책이 미결이므로 확정 기능으로 간주하지 않음
- 키보드 이동, 초점, 오류 식별과 색상 외 상태 표현
실제 학적·개인정보는 쓰지 않고 경계 조건을 대표하는 합성 데이터를 준비한다. 특정 학생이나 실제 성적이 화면 녹화에 남지 않게 한다. 프로토타입에는 “학습용이며 확정 디자인·성능이 아님”을 표시하고, 구현된 것처럼 보이는 기능도 배후 처리가 가짜인지 설명한다.
프로토타입 기록에는 버전, 확인 질문, 표현한 요구 ID, 표현하지 않은 요소, 참여자 특성, 과업, 관찰, 결정과 후속 항목을 남긴다.
| 기록 항목 | 예시 |
|---|---|
| 질문 | 학생이 접수와 승인, 보류와 거절을 구분하는가? |
| 연결 요구 | `UR-001`, `FR-003`, `IR-001`, `UI-001` 후보 |
| 제외 | 실제 규칙 계산, 피크 성능, 알림 전달 성공률 |
| 관찰 | 보류 참여자 6명 중 몇 명이 재제출했는가; 사유와 다음 행동을 찾았는가 |
| 결정 | 상태 명칭 수정, 예상 처리 약속 보강, 추가 시나리오 필요 |
참여자 수를 미리 정답처럼 고정하지 않는다. 초기 탐색은 적은 참여자로 큰 문제를 찾고 반복 수정할 수 있지만, 접근성·역할·정책 차이를 대표하려면 별도 세션이 필요하다. 반복할수록 새 핵심 문제가 줄어드는지와 위험 집단이 포함됐는지로 다음 범위를 정한다.
일회용 프로토타입인지 제품으로 진화할 코드인지도 구분한다. 일회용 산출물을 일정 압박으로 제품에 편입하면 보안·접근성·오류 처리·유지보수 품질을 갖추지 못할 수 있다. 진화형이라면 처음부터 제품 기준과 변경 통제를 적용한다.
### 4. 워크스루
워크스루는 여러 이해관계자가 같은 시나리오를 처음부터 끝까지 따라가며 업무·시스템·데이터·운영 책임을 확인하는 활동이다. 화면별 의견 수집보다 “이 사건 다음에는 누가 무엇을 알고, 무엇을 해야 하는가”를 드러내는 데 유리하다.
수강신청 보류 워크스루에는 학생 대표, 학사 담당자, 규칙 서비스 책임자, 운영자, 학생지원 담당자와 기록자가 참여한다. 진행자는 사건 카드를 순서대로 제시한다.
1. 학생이 마감 직전 강좌 신청을 제출한다.
2. 접수는 성공했지만 규칙 서비스가 시간 초과한다.
3. 학생이 결과를 조회하고 같은 신청을 다시 제출한다.
4. 운영자는 보류 증가 경보를 본다.
5. 규칙 서비스가 회복해 이전 요청의 늦은 응답과 재평가 결과가 도착한다.
6. 학생은 이미 취소를 선택했거나 다른 강좌를 신청했을 수 있다.
각 단계에서 다음을 묻는다.
- 공식 현재 상태와 근거 데이터는 어디에 있는가?
- 학생이 보는 정보와 할 수 있는 행동은 무엇인가?
- 자동 처리와 사람 판단의 경계는 어디인가?
- 늦은 결과·중복·취소가 충돌하면 어떤 정책이 우선하는가?
- 담당자는 무엇을 관찰하고 누구에게 에스컬레이션하는가?
- 개인정보와 감사 이력은 어느 범위에서 남는가?
워크스루는 그 자리에서 가장 목소리 큰 사람이 정책을 정하는 회의가 아니다. 확인된 합의, 증거가 더 필요한 가정, 권한 있는 결정이 필요한 쟁점을 나눈다. 마지막 좌석과 우선순위 문제는 `ISS-001`로 유지하고, 정책 결정 전까지 `RULE-005`를 승인하지 않는다. `ASM-003`의 “보류 신청은 좌석을 점유하지 않는다”도 운영 편의만으로 확정하지 않고 공정성·악용·학생 기대를 함께 확인한다.
기록자는 발언 요약뿐 아니라 어느 단계에서 어떤 정보가 없었는지, 역할 사이 책임이 겹치거나 비었는지를 남긴다. 합의된 흐름은 상태·과정 모델과 요구에 반영하고, 바뀐 부분은 다시 25장의 일관성·완전성 검사를 거친다.
### 5. 업무 시뮬레이션
업무 시뮬레이션은 개별 화면 사용을 넘어 사람, 시스템, 정책, 부하와 시간 흐름을 함께 재현한다. 실제 운영에 가까운 역할과 사건을 배치해 제안한 요구가 전체 업무 성과를 만들 수 있는지 확인한다. 기술 부하 시험과 겹칠 수 있지만 목적은 단순 처리량 측정이 아니라 업무 결과와 운영 부담을 관찰하는 데 있다.
이번 사례에서는 다음 학기 수강신청 첫 30분을 축소해 재현한다.
| 시간대·사건 | 학생 역할 | 시스템·외부 조건 | 학사·운영 역할 | 관찰 지표 |
|---|---|---|---|---|
| 개시 직후 | 인기 강좌 동시 신청 | 마지막 좌석, 중복 제출 | 문의 채널 준비 | 접수·판정 혼동, 초과 배정 |
| 규칙 지연 | 상태 조회·재제출 | 일부 시간 초과와 보류 | 적체 감시·원인 분류 | 반복 제출, 보류 수·체류시간 |
| 부분 장애 | 취소·대체 강좌 선택 | 알림 유실, 조회는 가능 | 공지·지원·에스컬레이션 | 문의, 수동 조회·정정 |
| 회복 | 결과 확인 | 재평가와 늦은 응답 | 대사·복구 확인 | 이중 판정, 좌석·이력 일치 |
| 종료 | 결과·사유 확인 | 미종료 보류 존재 | 후속 처리 | 수동 재처리 건수·소요시간 |
시뮬레이션 데이터는 기존 로그의 분포와 승인된 용량 가정을 사용해야 한다. 아직 실제 기준선이 없으면 규모와 결과를 “예시”로 표시하고, 작은 모의실험의 성공을 피크 운영 보장으로 확대하지 않는다. `BR-001`의 50% 감소 후보를 판단하려면 이전 학기의 수동 재처리 정의, 첫 30분 건수, 처리시간과 원인 분류가 먼저 있어야 한다.
관찰 지표도 목표와 연결한다.
- 같은 의도의 반복 제출률과 기존 결과 재사용률
- 학생이 결과·사유·다음 행동을 스스로 찾은 비율
- 보류 발생률, 체류시간, 재평가 성공과 미종료 건수
- 상담·학사·운영의 수동 조회, 정정, 재처리 건수와 시간
- 수용량 초과, 복수 최종 판정, 취소 뒤 승인 같은 금지 사건
- 알림 실패와 공식 상태 조회 실패의 구분
지표의 평균만 보면 피크와 소수 집단의 실패가 가려진다. 시간 구간, 시나리오, 사용자 조건과 오류 유형으로 나누되 개인정보는 최소화한다. 결과가 나쁘면 화면만 고치지 않고 가정, 정책, 인터페이스 책임과 운영 절차까지 원인을 추적한다.
### 6. 수용 조건
수용 조건은 “사용자가 만족하면 완료” 같은 주관적 문구가 아니라 어떤 업무 결과와 품질, 증거가 있어야 요구 또는 해결을 받아들일 수 있는지 정한 기준이다. 기능별 acceptance criteria, 시스템·운영 수용 기준, 팀의 완료 정의는 관련될 수 있지만 같은 것이 아니다.
| 구분 | 질문 | 예 |
|---|---|---|
| 요구·기능 수용 조건 | 이 결과가 사용자의 과업을 충족했는가? | 보류 학생이 사유와 다음 행동을 확인한다 |
| 품질·운영 수용 기준 | 어떤 부하·장애·보안 조건에서 사용할 만한가? | 정의된 피크 모형에서 금지 사건이 없고 복구·대사가 된다 |
| 업무 성과 조건 | 목표한 가치가 관찰되는가? | 반복 제출·수동 재처리가 기준선 대비 줄어든다 |
| 완료 정의 | 팀이 산출물을 완료로 다루는 공통 절차는? | 검토·시험·문서·배포 조건을 충족한다 |
`G-01`에 대한 수용 조건 후보는 다음처럼 계층화한다.
1. **사용 결과**: 학생이 접수와 최종 판정을 구분하고, 승인·거절·보류의 사유와 가능한 다음 행동을 자신의 신청 ID로 확인한다.
2. **안전 결과**: 규칙 서비스 실패·무효·시간 초과에서 자동 승인이나 복수 최종 판정, 수용량 초과가 발생하지 않는다.
3. **회복 결과**: 보류가 추적 가능하며 재평가·취소·운영 개입 후 일관된 최종 상태 또는 승인된 종료 상태에 도달한다.
4. **운영 결과**: 첫 30분 반복 제출과 수동 재처리가 합의한 기준선·측정법에 따라 감소한다.
5. **포용·통제 결과**: 보조기술 사용자를 포함해 상태와 오류를 인지·조작할 수 있고, 권한·개인정보·감사 요구를 지킨다.
여기서 50%, p95 2초, 99.9% 같은 값은 출처·비용·측정환경이 합의돼야 수용 임계치가 된다. 임시 목표를 마치 계약된 숫자처럼 쓰지 않는다. 반대로 수치가 없다는 이유로 “사용자 만족”만 두지 말고, 금지 사건·과업 성공·회복 상태처럼 지금 합의할 수 있는 조건을 먼저 둔다.
수용 조건에는 증거 출처와 결정권자도 연결한다. 프로토타입 관찰은 개념 수용 증거가 될 수 있지만 성능·보안 수용을 증명하지 못한다. 부하 시험은 처리 성능을 보여도 학생이 보류를 이해하는지는 보여 주지 못한다. 여러 증거가 필요한 조건은 하나의 통과 표시로 축약하지 않는다.
### 7. 사용자 확인
사용자 확인은 대표자가 문서 끝에 서명하는 행위보다 넓다. 실제 사용자와 업무 책임자가 관련 맥락에서 요구를 이해하고 시도해 본 뒤, 필요·기대효과·제약에 대한 증거와 결정을 남기는 과정이다. 서명은 결정 기록일 수 있지만 요구가 옳다는 증거를 스스로 만들지는 않는다.
확인 세션 결과는 네 목록으로 나눈다.
- **확인됨**: 어떤 시나리오와 증거로 필요·결과가 지지됐는가.
- **조건부 합의**: 어떤 전제·수정·추가 증거가 충족돼야 하는가.
- **미합의**: 이해관계자 간 목표·정책·위험 수용이 어디서 다른가.
- **미결 항목**: 누가 언제 무엇을 조사·결정하며 미결 시 영향은 무엇인가.
#### 확인 기록 예시
| 항목 | 연결 대상 | 관찰·근거 | 결정 상태 | 후속 책임 |
|---|---|---|---|---|
| 접수·판정 구분 | `UR-001`, `FR-003` | 프로토타입 과업에서 상태 이해와 재제출 행동 관찰 | 수정 후 재확인 | 사용자 경험 책임자 |
| 안전 보류 | `IR-001`, `DR-001` | 학생 시나리오와 피크 운영 워크스루 | 조건부 합의 | 학사·운영 책임자 |
| 우선순위 배정 | `RULE-005`, `ISS-001` | 마지막 좌석에서 `RULE-004`와 정책 해석 불일치 | 미합의 | 정책 결정권자 |
| 수동 재처리 감소 | `G-01`, `BR-001`, `ASM-001`, `ASM-004` | 과거 기준선과 원인 자료 미확보 | 미결 항목 | 업무 성과 책임자 |
| 보류 좌석 점유 | `ASM-003` | 공정성·악용 영향 미검토 | 미결 항목 | 학사 정책 책임자 |
합의 목록에는 참여자와 대표 범위, 사용한 기준선 버전, 날짜, 조건과 반대 의견을 함께 남긴다. 불참한 집단을 “사용자 승인”으로 포함하지 않는다. 이해관계자 간 충돌은 다수결로 숨기지 않고 의사결정 권한과 상위 목표로 해결한다. 개인정보·접근성·법적 의무처럼 다수 선호로 면제할 수 없는 제약도 구분한다.
확인에서 요구가 바뀌면 25장 검증으로 되돌아간다. 예를 들어 학생 관찰로 보류 설명을 바꾸면 `FR-003`과 사용자 인터페이스 요구뿐 아니라 `IR-005` 알림, `DR-001` 사유 데이터, `QR-007` 접근성과 추적 링크의 일관성을 다시 검사한다. 검증에서 발견한 모호성 때문에 시나리오가 수행 불가능하면 문장을 고친 뒤 다시 확인한다.
26장의 최종 산출물은 **확인 시나리오**, **프로토타입 기록**, **수용 조건**, **합의·미합의 목록**이다. 이 네 가지가 있으면 “회의에서 좋다고 했다”를 넘어 어떤 맥락에서 무엇을 관찰했고 무엇이 아직 결정되지 않았는지 재현할 수 있다. 요구사항 기준선은 검증과 확인의 결함이 모두 처리되고, 남은 위험을 권한 있는 사람이 근거와 만료 조건을 갖춰 수용했을 때 비로소 다음 관리 단계로 넘어간다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 26장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
요구사항이 실제 사용자와 업무 목적에 맞는지 프로토타입·시나리오·사용자 피드백으로 확인한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.