---
title: "7장. 요구사항 도출"
description: "어떤 지식을 누구에게 어떤 기법으로 확인할지 정하고 원자료·관찰·해석·요구 후보와 승인 상태를 분리한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
이미 말해진 요청 너머의 필요·제약·가정을 어떻게 발견하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “이미 말해진 요청 너머의 필요·제약·가정을 어떻게 발견하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
요구사항 도출은 사람들을 모아 원하는 기능을 묻는 회의 한 번으로 끝나지 않는다. 알고 싶은 지식의 종류와 위험에 따라 적절한 출처와 기법이 달라지며, 발언과 실제 행동, 공식 규정과 현행 관행이 서로 다를 수 있다. 준비 없이 시작하면 많은 기록을 얻고도 무엇을 믿어야 할지 판단하기 어렵다.
이 장에서는 도출 목표와 범위를 세우고 이해관계자별 질문, 자료, 일정과 기록 방식을 계획한다. 원자료·관찰·해석·요구 후보를 분리하고 확인 상태를 남겨, 이후 분석에서 출처와 추론을 되짚을 수 있는 도출 계획을 만드는 방법을 설명한다.
### 1. 요구사항은 왜 그냥 물어봐서는 나오지 않는가
“어떤 기능이 필요하십니까?”라고 물으면 대답은 쉽게 나온다. 학생은 더 빠른 신청 버튼을, 교무처는 관리자 화면을, 운영팀은 서버 증설을 말할 수 있다. 하지만 이 답들은 각자가 경험한 증상과 익숙한 해결책을 압축한 말이다. 누구도 전체 업무·규칙·예외·데이터·외부 장애를 한 번에 설명하기 어렵고, 반복해서 해 온 일은 너무 당연해 말하지 않기도 한다. 앞으로 생길 상황은 경험한 적이 없어 답할 수 없다.
요구사항 도출(elicitation)은 완성된 요구사항을 이해관계자의 머릿속에서 꺼내는 활동이 아니다. 변화와 관련된 정보를 여러 출처에서 **끌어내고, 탐색하고, 식별하며, 불확실성을 드러내는 반복 활동**이다. [IIBA의 2025년판 Business Analysis Standard](https://www.iiba.org/globalassets/business-analysis-resources/the-business-analysis-standard/files/the-business-analysis-standard.pdf)는 도출 수행의 결과를 곧바로 확정 요구사항이 아니라 ‘미확인 도출 정보’로 둔다. 그 뒤 정확성과 다른 정보와의 일관성을 확인한다.
수강신청 사례에서는 “결과를 빨리 보여 달라”는 학생 발언만으로 `QR-001`을 확정할 수 없다. 실제로 기다린 시간과 학생이 결과를 확인하는 행동을 관찰하고, 로그에서 응답시간 분포와 반복 요청을 확인하며, 운영팀과 측정 지점을 합의해야 한다. “졸업예정자를 우선한다”는 말도 학칙·시행 시점·대상·동률 처리·예외 승인자를 확인해야 `RULE-005`의 근거가 된다.
도출의 목적은 말을 많이 모으는 데 있지 않다. 2부에서 남긴 미해결 질문에 어떤 증거가 필요한지 정하고, 서로 다른 출처의 설명이 어디서 일치하거나 충돌하는지 찾는 것이다. 질문 하나의 답을 그대로 요구사항으로 옮겼다면 출처·관찰 사실·해석·후보·확인 상태가 분리되어 있는지부터 다시 살핀다.
### 2. 요구사항의 출처
요구사항 출처는 필요·제약·규칙·성공 기준을 발견하거나 확인할 수 있는 사람, 조직, 문서, 시스템, 데이터와 사건이다. 이해관계자는 핵심 출처지만 유일한 출처는 아니다. [SWEBOK Guide v4.0a](https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf)는 고객·사용자·도메인 전문가·운영·지원·규제 주체뿐 아니라 기존 문서, 다른 시스템, 조직 정책과 프로세스, 컴퓨팅 환경도 출처로 식별하고 평가하도록 설명한다.
6장의 이해관계자 지도와 5장의 업무 자료를 출처 지도로 바꾸면 다음과 같다.
| 확인할 정보 | 사람·조직 출처 | 비인적 출처 | 편향·한계 |
|---|---|---|---|
| 결과 미확인과 반복 제출 | 다양한 학생, 상담원 | 요청·상태 로그, 문의 기록, 기존 화면 | 기억 오류, 로그 상관관계 부족 |
| 수동 재처리와 예외 | 교무 운영, 학과 사무실 | 정정 목록, 업무 지침, 처리 이력 | 개인별 우회 절차가 기록되지 않음 |
| 선수과목·학점·우선순위 | 정책 소유자, 도메인 전문가 | 학칙, 위원회 결정, 규칙 버전 | 현행 문서와 실제 적용 차이 |
| 외부 장애와 복구 | IT 운영, 서비스 소유자 | 연계 명세, 장애 보고, 계약·지표 | 정상 흐름 위주 문서 |
| 접근 장벽 | 장애학생, 지원센터 | 보조기술 평가, 문의·지원 기록 | 대리인 의견이 당사자 경험을 대체할 위험 |
출처마다 `SRC` 번호, 소유자, 적용 기간, 접근 권한, 최신성, 기대할 정보와 한계를 붙인다. 예를 들어 `SRC-LOG-01`은 직전 학기 첫 30분의 신청·상태 전이 로그, `SRC-POL-01`은 현재 시행 중인 학사 규정, `SRC-STU-01`은 서로 다른 신청 조건을 가진 학생 표본이라고 기록할 수 있다.
출처 수가 많다고 완전한 것은 아니다. 같은 부서의 인터뷰 세 건은 같은 관점을 반복할 수 있다. 문제·규칙·위험마다 최소한 `말한 경험`, `실제 기록 또는 관찰`, `권한 있는 근거` 중 어떤 조합이 필요한지 정한다. 출처가 서로 다르면 평균내지 않고 차이를 쟁점으로 보존한다.
### 3. 명시적 요구와 잠재적 요구
명시적 요구는 이해관계자가 말하거나 문서가 직접 표현한 필요와 조건이다. 잠재적 요구는 업무 행동, 예외, 데이터 또는 실패 사례 속에 들어 있지만 아직 요구의 형태로 표현되지 않은 필요다. 잠재적이라는 말은 분석가가 마음대로 상상해도 된다는 뜻이 아니다. 발견의 단서는 있어야 하며, 해석은 확인 전까지 후보로 남는다.
학생이 “신청 결과와 거절 이유를 바로 알고 싶다”고 말하면 `UR-001`과 연결되는 명시적 요구다. 상담원이 결과가 보이지 않는 학생에게 신청 번호와 로그 시각을 물어 수동 조회하는 모습을 관찰했다면, 접수 식별자와 상태 이력 조회의 필요가 잠재적으로 드러난다. 운영 기록에서 외부 학사 서비스 오류 뒤 일부 요청이 최종 상태 없이 남아 있다면 보류·재평가·통지 조건을 더 물어야 한다. 이 기록만으로 구현 방식을 정하지 않는다.
| 원자료 | 관찰 사실 | 해석한 요구 후보 | 확인할 사람·증거 |
|---|---|---|---|
| 학생 발언 | 결과가 보이지 않아 다시 눌렀다고 말함 | 접수·처리 상태를 구분해 보여 줄 필요 | 실제 행동 관찰, 요청 로그 |
| 상담 관찰 | 신청 번호 없이 시간·강좌로 검색 | 학생과 담당자가 공유할 조회 식별자 필요 | 상담원·개인정보 담당자 |
| 장애 로그 | 규칙 연계 실패 뒤 상태 공백이 있음 | 보류 상태와 재평가 책임 필요 | 운영·교무처, `IR-001` 검토 |
| 규정 문서 | 우선 배정 대상은 있으나 동률 규정이 불명확 | 동률·예외 결정 규칙 필요 | 정책 소유자와 결정 이력 |
말하지 않은 요구가 모두 필수는 아니다. 사용자가 익숙한 우회 방법을 선호할 수도 있고, 관찰된 동작이 잘못된 관행일 수도 있다. 후보에는 발견 계기와 예상 가치를 적고, 문제 `G-01`과의 연결, 반례, 결정 권한을 확인한다. 명시성과 중요도도 별개다. 크게 말한 기능이 낮은 가치일 수 있고, 말하지 않은 감사·복구 조건이 핵심일 수 있다.
### 4. 알려진 요구와 알려지지 않은 요구
도출 계획은 내용뿐 아니라 **지식 상태**를 다룬다. 알려진 요구는 출처와 조건을 설명할 수 있는 항목이고, 알려진 미지(known unknown)는 답해야 할 질문을 알고 있지만 답이 없는 항목이다. 알려지지 않은 미지는 질문 자체를 아직 발견하지 못한 영역이다. 마지막 것은 목록으로 직접 적을 수 없으므로 다양한 관점·기법·반례를 통해 노출 가능성을 높인다.
현재 사례의 지식 상태를 나누면 이렇다.
- **알려진 사실:** 현행 `UR-001`–`IR-001` 후보와 `RULE-001–RULE-005`, 문제 정의 0.1, 목표 `G-01`이 기록되어 있다.
- **알려진 미지:** 첫 30분 기준선, `QR-001`의 측정 부하, 우선순위 동률 처리, 보류 재평가 기한과 권한은 미확정이다.
- **가정:** 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 `ASM-001`은 로그와 관찰로 검증해야 한다.
- **알려지지 않은 미지에 대비할 영역:** 드문 학적 상태, 동시 변경, 네트워크 단절, 보조기술 사용, 학과별 비공식 예외를 서로 다른 기법으로 탐색한다.
“모든 요구를 찾았는가?”는 답할 수 없는 질문이다. 대신 중요한 영역의 출처가 빠지지 않았는지, 정상·예외·경계·실패를 살폈는지, 새 정보가 나올 통로와 재계획 조건이 있는지를 묻는다. [ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html)은 2024년에 현행으로 확인되었고 현재 개정 예정 상태다. 표준이 완전성을 보장하는 마법의 절차를 제공하는 것은 아니다. 생명주기 전체에서 요구 관련 활동과 정보 항목을 관리해야 한다는 기준을 준다.
지식 상태에는 마지막 확인 날짜, 책임자와 다음 행동을 붙인다. 미확정을 숨기지 않으면 구현을 늦추는 것이 아니라 위험이 큰 질문을 먼저 처리할 수 있다.
### 5. 도출 계획
도출 계획은 `무엇을 알아야 하는가 → 어느 출처에서 → 왜 이 기법으로 → 누가 참여해 → 어떤 기록을 만들고 → 누가 어떻게 확인하는가`를 연결한다. 인터뷰 일정표만 만들면 출처와 목표가 끊긴다. IIBA 표준도 준비 단계에서 활동 범위, 적합한 기법, 자료·자원, 참여자와 물류를 정하고 활동이 만들어 낼 결과를 분명히 하도록 안내한다.
2부의 미해결 질문을 계획으로 바꾸면 다음과 같다.
| 조사 목표 | 출처·참여자 | 기법 조합 | 산출물·확인 | 우선 이유 |
|---|---|---|---|---|
| 반복 제출과 재처리의 원인·규모 | 학생 표본, 상담원, 운영팀, `SRC-LOG-01` | 인터뷰·관찰·로그 분석 | 행동-로그 대조표 / 운영·학생 확인 | `BR-001` 기준선과 문제 검증 |
| 규칙의 출처·예외·우선순위 | 정책 소유자, 학과, 규정·결정 이력 | 문서 분석·규칙 워크숍·시나리오 | 규칙 쟁점표 / 결정권자 확인 | 잘못된 승인 위험이 큼 |
| 다양한 학생의 신청 조건 | 장애·졸업·교환 등 학생, 지원센터 | 접근 가능한 인터뷰·여정·프로토타입 | 장벽·조건 목록 / 당사자 확인 | 대표성 누락 위험 |
| 보류·복구의 실제 업무 | 교무 운영, IT·외부 연계 운영자 | 사건 분석·인터페이스 분석·모의 시나리오 | 상태·책임 초안 / 공동 확인 | `IR-001` 구체화 |
계획표에는 **포화 조건**도 둔다. 같은 유형의 인터뷰에서 새 정보가 거의 나오지 않는다는 이유만으로 전체 도출을 끝내지 않는다. 특정 조사 질문과 이해관계자 집단에서 새로운 개념·예외가 줄었는지, 다른 출처의 모순이 해소되었는지 판단한다. 학생 인터뷰가 포화되어도 정책 소유자나 외부 연계 운영자의 지식은 비어 있을 수 있다. 완료 판단은 사람 수보다 출처 지도의 칸별 증거 상태에 근거한다.
활동 순서도 위험에 따라 바꾼다. 잘못된 자동 승인처럼 피해가 크고 되돌리기 어려운 문제는 규칙·장애·권한 조사를 먼저 한다. 화면 용어처럼 낮은 충실도의 프로토타입으로 빠르게 배울 수 있는 문제는 짧은 주기로 반복한다. 개인정보나 불이익 경험을 다루는 활동은 참여자가 거절·중단해도 불리하지 않도록 안내하고, 원자료가 없어도 목적을 달성할 수 있는 최소 기록 방식을 먼저 찾는다.
| 계획 검토 질문 | 남겨야 할 근거 |
|---|---|
| 이 활동이 답할 조사 질문은 정확히 무엇인가? | 문제·가정·규칙·위험과의 연결 |
| 이 참여자가 필요한 이유와 대표 범위는 무엇인가? | 선정 기준과 빠진 집단 |
| 선택한 기법이 출처의 어떤 한계를 보완하는가? | 대안 기법과 선택 근거 |
| 확인 전 결과를 누가 어떻게 사용할 수 있는가? | 상태, 접근 권한과 금지된 사용 |
| 새 정보나 위험이 나오면 무엇을 재계획하는가? | 중단·추가·확대 조건과 책임자 |
각 활동에는 선행 자료, 질문 주제, 기록자, 시간, 장소·접근성, 녹음 여부와 동의, 민감 정보 최소화, 관찰자 역할, 중단 조건을 둔다. 실제 학생·운영 로그에는 개인정보가 포함될 수 있으므로 [개인정보 보호법 현행 본문](https://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EA%B0%9C%EC%9D%B8%EC%A0%95%EB%B3%B4%EB%B3%B4%ED%98%B8%EB%B2%95)과 대학 정책에 따라 처리 근거·범위·접근·보존을 담당자와 확인한다.
계획은 순차적일 필요가 없다. 첫 인터뷰에서 나온 용어를 문서에서 확인하고, 로그 분석의 이상 패턴을 다음 관찰 질문으로 보낸다. 비용이 크거나 민감한 활동 전에 저비용 문서·데이터 탐색을 할 수 있지만, 그것이 당사자 참여를 대체해서는 안 된다.
### 6. 도출 결과 기록
도출 결과는 회의 요약 한 문단으로는 부족하다. 누가 실제로 한 말인지, 관찰자가 본 행동인지, 분석가의 해석인지, 요구 후보인지 구분되지 않으면 나중에 반박하거나 확인할 수 없다. 원자료 전체를 요구사항 저장소에 복사하는 것도 답이 아니다. 목적에 필요한 근거만 연결하고 접근 권한을 분리한다.
세션 기록의 최소 구조는 다음과 같다.
| 항목 | 기록 예 |
|---|---|
| 활동·시각·참여 역할 | `ELI-INT-01`, 학생 인터뷰, 신청 경험이 다른 학생 1명 |
| 조사 질문 | 결과 미확인 뒤 무엇을 했고 왜 그렇게 판단했는가? |
| 원자료 위치 | 접근 제한 녹취·메모 식별자, 보존 기한 |
| 관찰 사실·발언 요약 | 처리 중 표시가 없어 같은 강좌를 다시 제출했다고 설명 |
| 해석·요구 후보 | 접수 여부와 처리 상태를 구분할 필요가 있을 수 있음 |
| 연결 | 문제 정의 0.1, `ASM-001`, `UR-001`, `QR-001` |
| 상태·후속 | 미확인 / 실제 화면 관찰과 로그 상관관계 확인 |
요구 후보 문장은 확정 요구처럼 “해야 한다”로 단정하기보다 주체·상황·필요·근거와 미확정 조건을 담는다. 예를 들면 “학생은 반복 제출 여부를 판단할 수 있도록 접수 식별자와 현재 처리 상태를 확인할 필요가 있다는 후보가 도출됨”이라고 쓰고, 표시 방식은 설계 후보로 분리한다.
서로 모순되는 기록도 삭제하지 않는다. 학생은 보류를 실패로 느끼지만 운영팀은 잘못된 승인을 막는 안전 상태라고 볼 수 있다. 두 출처, 발생 조건과 우려를 남겨 4부의 충돌 분석 입력으로 보낸다. 좋은 기록은 결론이 매끄러운 기록이 아니라 출처로 돌아가 사실·해석·결정을 분리할 수 있는 기록이다.
### 7. 도출 결과 확인
확인은 참가자에게 회의록 전체를 보내 “이상 없으면 동의”라고 하는 절차가 아니다. 도출한 정보가 의도와 맞고, 다른 자료와 일관되며, 다음 분석에 쓸 만큼 분명한지 관련 출처와 함께 점검하는 활동이다. IIBA 표준은 도출 결과 확인의 목적을 수집 정보의 정확성과 다른 정보와의 일관성을 확인하여 공유된 이해를 얻는 데 둔다. **확인된 도출 정보**도 아직 승인된 요구사항은 아니다. 분석·협상·명세와 검증을 거쳐야 한다.
확인 방법은 정보 성격에 맞춘다. 인터뷰 발언은 짧은 요약과 해석을 당사자에게 되돌리고, 규칙은 정책 소유자에게 조항·용어·예외·시행일을 확인한다. 관찰에서 추정한 목적은 수행자에게 묻고, 로그 패턴은 운영팀과 데이터 정의·누락·시간대·중복 집계를 검토한다. 상충은 한쪽에게 맞춰 고치지 않고 쟁점으로 공동 확인한다.
| 요구 후보·가정 | 확인 질문 | 확인 근거 | 결과 상태 |
|---|---|---|---|
| 반복 제출은 결과 미확인에서 비롯된다 | 실제로 어떤 표시 뒤 몇 번 다시 제출했는가? | 관찰·동일 학생/강좌 요청 로그 | 일부 확인, 다른 원인 조사 |
| 우선 배정은 졸업예정자 전반에 적용된다 | 대상·강좌·기간·동률·예외는 무엇인가? | 학칙·위원회 결정·정책 소유자 | 미확인 쟁점 유지 |
| 외부 장애 시 보류한다 | 보류 생성·재평가·통지·해제 권한은? | 장애 절차·모의 시나리오 | `IR-001` 세부 후보 추가 |
| 판정 기록으로 문의를 설명할 수 있다 | 어떤 사유와 규칙 버전이 실제 문의에 필요한가? | 상담 사례·`DR-001` 필드 검토 | 필드별 확인 필요 |
확인 기록에는 확인자, 날짜, 제시한 내용, 동의·수정·반대, 근거와 후속 행동을 남긴다. 응답하지 않았다는 사실을 동의로 바꾸지 않는다. 또한 개인정보·민감한 경험이 담긴 원자료를 모든 참여자에게 공유하지 않고, 확인 목적에 맞게 최소화·비식별화한다.
이 장에서 정리한 결과는 출처 지도, 도출 계획표, 세션 기록 양식, 요구 후보와 미해결 질문 목록이다. 8장에서는 이 계획의 각 조사 목표에 인터뷰·관찰·문서·데이터·프로토타입 같은 기법을 왜 선택하고 어떻게 조합할지 구체화한다. 판단 기준은 기법의 이름을 많이 넣었는지가 아니라 출처의 한계를 다른 기법이 보완하며, 결과가 확인 전 상태를 정직하게 유지하는가이다.
다음 장으로 넘길 때는 각 조사 질문에 우선 기법과 보완 기법, 얻어야 할 최소 증거와 중단 조건이 연결되어 있는지도 확인한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 7장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
어떤 지식을 누구에게 어떤 기법으로 확인할지 정하고 원자료·관찰·해석·요구 후보와 승인 상태를 분리한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.