8장. 요구사항 도출 기법

인터뷰·관찰·워크숍·프로토타이핑 등 도출 기법을 질문과 위험에 맞춰 조합하고 각 기법의 한계를 보완한다.

학습 목표

“인터뷰·관찰·워크숍·문서 분석·프로토타입을 언제 어떻게 선택하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

인터뷰, 관찰, 워크숍, 설문, 문서 분석과 프로토타이핑은 서로 경쟁하는 정답이 아니다. 인터뷰는 경험의 의미를 들을 수 있지만 실제 행동을 모두 보여 주지 못하고, 관찰은 행동을 보여 주지만 정책의 근거까지 설명하지는 못한다. 한 기법의 결과만 믿으면 그 기법이 보지 못하는 부분이 요구사항의 빈칸으로 남는다.

이 장에서는 조사 질문과 불확실성의 성격에 맞춰 여러 도출 기법을 조합하는 법을 다룬다. 수강신청 사례에서 어떤 기법이 어떤 증거를 만들고 서로의 한계를 어떻게 보완하는지 비교하며, 제한된 시간 안에서 실행 가능한 도출 전략을 구성한다.

‘요구사항 도출 기법’ 장의 핵심 상황과 역할을 보여 주는 손그림 — ‘요구사항 도출 기법’에서 먼저 확인해야 할 문제와 판단 기준.

1. 인터뷰

인터뷰는 한 명 또는 소수의 참여자와 대화하며 경험, 판단, 용어, 예외와 우려를 깊게 탐색하는 기법이다. 정책 소유자의 결정 근거, 학생의 최근 신청 경험처럼 맥락과 후속 질문이 중요한 주제에 적합하다. 많은 사람의 비율을 추정하거나 실제 행동을 직접 증명하는 도구는 아니다.

‘인터뷰’의 핵심 관계를 설명하는 손그림 — 인터뷰: 핵심 대상과 판단 근거.

준비할 때 7장의 조사 질문과 참여자 선정 근거를 정하고, 소개·동의·주제·시작 질문·후속 질문을 담은 대화 안내서를 만든다. GOV.UK의 심층 인터뷰 지침은 실제 사례와 이야기에 집중하고, 열린 중립 질문을 사용하며, 안내서를 경직되게 읽지 말라고 권한다. 접근 가능한 장소·도구, 통역·보조, 기록자와 녹음 처리도 준비한다.

학생에게 “새 상태 화면이 좋겠습니까?” 대신 “최근 결과를 알 수 없었던 신청을 처음부터 이야기해 주세요”라고 묻는다. 답변에서 행동·판단·느낌을 구분하고 “그때 무엇을 보았습니까?”, “다음에 무엇을 했습니까?”로 구체화한다. 정리할 때 발언, 해석, 후보, 반례와 후속 증거를 분리한다. 기억과 사회적 바람직성, 인터뷰어의 유도라는 한계는 관찰·로그·다른 참여자 인터뷰로 보완한다.

2. 워크숍

워크숍은 서로 다른 이해관계자가 정해진 결과를 함께 만들거나 차이를 드러내도록 진행하는 구조화된 협업 세션이다. 교무처·학과·운영팀이 RULE-005의 대상·동률·예외를 같은 자리에서 비교하는 데 유용하다. 많은 참석자를 모은 회의가 자동으로 워크숍이 되는 것은 아니다.

‘워크숍’의 핵심 관계를 설명하는 손그림 — 워크숍: 핵심 대상과 판단 근거.

준비 단계에서 결정할 질문, 참여 역할, 사전 자료, 시간 상자, 진행 규칙과 산출물 양식을 보낸다. 최종 결정권자와 도메인 전문가를 구분하고, 권력 차이 때문에 말하기 어려운 참여자에게 사전 인터뷰나 익명 입력 경로를 마련한다. 수행할 때 사실·가정·쟁점·대안을 다른 영역에 기록하고, 합의와 단순 침묵을 구분한다.

수강신청 규칙 워크숍의 안건은 ① 용어와 현행 근거 확인, ② 정상·예외 시나리오 적용, ③ 충돌 규칙과 결정권 확인, ④ 미해결 질문·담당자·기한 지정 순으로 구성할 수 있다. 결과는 규칙 초안과 결정 로그이지 참석자의 모든 발언을 섞은 회의록이 아니다. 집단사고와 목소리 큰 사람의 지배는 문서 분석, 소그룹 작업과 사후 개별 확인으로 보완한다.

3. 브레인스토밍

브레인스토밍은 짧은 시간에 많은 관점·위험·대안·질문을 생성하는 기법이다. 알려지지 않은 미지를 탐색하거나 “외부 학사 서비스가 늦을 때 어떤 일이 생길 수 있는가?”의 사건 후보를 넓히는 데 적합하다. 아이디어 수가 곧 요구사항 수나 품질을 뜻하지는 않는다.

‘브레인스토밍’의 핵심 관계를 설명하는 손그림 — 브레인스토밍: 핵심 대상과 판단 근거.

먼저 생성 목표와 범위를 한 문장으로 정하고, 판단을 미루는 생성 단계와 근거를 붙여 묶고 평가하는 단계를 분리한다. 수강신청 사례에서는 학생·교무·운영·지원 역할의 관점에서 실패 상황을 개별 작성한 뒤 함께 분류한다. “서버 증설” 같은 해결책이 나오면 버리지 말고 어떤 문제와 가정을 해결하려는지 되묻는다.

산출물은 요구사항 확정본이 아니라 조사 질문·위험·대안 후보와 출처다. 친숙한 아이디어로 쏠리고 실제 제약을 놓치는 한계가 있으므로 학칙·로그·관찰로 확인한다. 참여자 다양성이 부족하면 아이디어 다양성도 보장되지 않는다.

4. 관찰

관찰은 사람이 실제 환경에서 업무를 수행하는 행동, 도구, 인계, 우회와 방해를 직접 살피는 기법이다. 익숙해서 설명하지 않는 암묵지와 말한 절차·실제 행동의 차이를 찾는 데 강하다. 관찰자는 행동은 볼 수 있지만 그 목적을 자동으로 알 수 없으므로 해석을 당사자에게 확인해야 한다.

상담원이 결과 미확인 문의를 처리하는 장면을 관찰한다면 대상 과업, 장소·시간, 관찰자 역할, 기록 범위와 중단 조건을 정한다. 화면·학생 정보가 노출될 수 있으므로 처리 근거와 동의, 마스킹, 접근·보존 정책을 개인정보 담당자와 확인한다. 관찰 때문에 행동이 달라질 수 있다는 점도 기록한다.

시각 → 촉발 사건 → 행동 → 사용 정보·도구 → 판단 → 결과·중단 → 관찰자의 질문 형식으로 남긴다. 상담원이 개인 메모의 사유 코드 표를 보는 행동은 공식 요구가 아니라 우회 단서다. 왜 사용하는지, 규정과 맞는지 인터뷰·문서로 교차 확인한다. 드문 장애나 계절 집중 현상은 현장 관찰만으로 만나기 어려우므로 기록·시나리오와 조합한다.

5. 설문

설문은 같은 질문을 많은 참여자에게 제시해 경험·인식·자기 보고의 분포를 파악하는 기법이다. 인터뷰에서 발견한 결과 미확인 유형이 학생 집단에 얼마나 퍼져 있는지 탐색하는 데 유용하다. 숨은 요구를 처음부터 깊게 발견하거나 실제 성능을 측정하는 수단은 아니다.

모집단과 표본, 응답 경로, 질문 순서, 선택지의 상호 배타성·포괄성, 무응답과 중복 응답 처리를 미리 정한다. “시스템이 느려서 재신청했습니까?”는 원인과 행동을 한꺼번에 유도한다. “마지막 신청에서 결과를 확인하기 전 무엇을 했습니까?”와 선택지·기타·후속 이유를 나눈다. 배포 전 인지 인터뷰나 소규모 시험으로 같은 뜻으로 읽히는지 확인한다.

응답률과 비율만 보고 전체 학생을 대표한다고 단정하지 않는다. 신청에 실패한 학생이 더 많이 응답하거나 접근성 장벽이 있는 학생이 설문 자체에 참여하지 못할 수 있다. 결과에는 질문 문구·표본·수집 기간·결측을 함께 보존하고, 로그·인터뷰와 대조한다.

6. 문서 분석

문서 분석은 학칙, 업무 지침, 위원회 결정, 계약, 인터페이스 명세, 장애 보고처럼 이미 기록된 자료에서 용어·규칙·의무·차이와 공백을 찾는 기법이다. 권한 있는 근거와 과거 결정을 찾는 데 강하지만 문서가 최신이거나 실제 업무와 일치한다고 보장하지 않는다.

먼저 문서 소유자, 판·시행일, 적용 대상, 승인 상태와 대체 문서를 확인한다. RULE-005라면 ‘졸업예정자’, ‘전공필수’, ‘우선 평가’의 정의와 적용 기간, 동률·예외 조항을 추출한다. 문장마다 출처 위치 → 해석 → 영향받는 프로세스·데이터·후보 → 질문을 연결한다.

문서 간 충돌은 최신 날짜만으로 고르지 않는다. 상위 규정과 위임 관계, 결정권자와 실제 적용 이력을 확인한다. 문서에 없는 관행은 곧바로 무효라고 보지 않고 관찰·인터뷰로 이유를 찾는다. 분석이 끝났다는 기준은 관련 문서를 모두 읽었다는 말이 아니라 핵심 규칙의 근거·적용 범위·불일치·미해결 소유자가 드러난 상태다.

7. 기존 시스템 분석

기존 시스템 분석은 현재 시스템의 동작·구성·상태·코드·설정·오류 기록을 살펴 업무 지식과 제약 후보를 찾는 기법이다. 문서화되지 않은 검증 순서와 예외를 발견하고 전환 영향을 예측할 수 있다. 그러나 현재 구현이 곧 올바른 요구사항이라는 뜻은 아니다.

수강신청에서 동일 학생·강좌의 중복 요청이 어떻게 처리되는지, 판정 상태가 어떤 순서로 바뀌는지, 규칙 버전이 기록되는지, 외부 오류가 어떤 코드로 변환되는지 추적한다. 테스트 환경에서 재현하고 코드·설정·운영 기록을 연결한다. “기존 시스템이 막는다”는 사실은 정책, 결함, 기술 한계 중 무엇인지 별도 확인한다.

산출물은 현행 동작 목록, 숨은 규칙 후보, 기술 부채·전환 의존성과 검증 질문이다. 보안상 민감한 구성과 실제 개인정보 접근은 최소 권한으로 제한한다. 낡은 동작을 그대로 복제하는 위험은 정책 소유자·사용자·목표 업무와 대조하여 줄인다.

8. 화면 분석

화면 분석은 현재 화면의 정보, 입력, 선택, 피드백과 이동에서 사용자 과업·용어·검증 규칙 후보를 찾는 기법이다. 빠르게 현행 접점을 이해할 수 있지만 화면에 없는 수작업·외부 연계·정책과 사용자의 실제 목적을 놓친다.

화면별로 진입 조건, 사용 역할, 표시 데이터의 출처, 가능한 행동, 오류·빈 상태·권한 차이와 다음 단계를 기록한다. 수강신청 화면의 비활성 신청 버튼을 보고 “신청 불가”라고만 적지 말고, 불가 사유가 보이는지, 학생이 다음 행동을 판단할 수 있는지 UR-001과 대조한다. 처리 중과 실패가 같은 메시지라면 반복 제출 가설과 연결한다.

화면이 요구하는 데이터가 실제 업무 데이터와 같은 뜻인지, 숨겨진 기본값과 시간 제한이 있는지도 확인한다. 화면 캡처는 판·환경·역할·시각을 붙인다. 화면을 새 요구의 설계로 복사하지 않고 관찰과 사용자 여정으로 실제 사용을 확인해야 한다.

9. 데이터 분석

데이터 분석은 로그·상태 이력·문의·정정 기록 같은 자료에서 수량, 분포, 순서, 상관관계와 이상 패턴을 찾는 기법이다. BR-001의 기준선과 ASM-001을 검토하는 데 필요하지만 수치만으로 행동의 이유나 정책의 정당성을 알 수 없다.

분석 전에 질문, 단위와 기간, 사건·상태 정의, 데이터 생성 경로, 누락·중복·시간대와 접근 권한을 확인한다. 첫 30분의 ‘수동 재처리’가 팀마다 다른 상태를 포함하면 50% 감소 기준은 비교할 수 없다. 동일 학생·강좌 요청을 묶을 키와 시간 창을 정하되, 식별 가능한 원자료를 불필요하게 복사하지 않는다.

결과는 집계값과 함께 계산식·필터·제외·품질 한계를 남긴다. 반복 요청과 결과 미확인이 함께 나타나도 인과로 단정하지 않고 인터뷰·관찰로 확인한다. 개인정보 보호법 현행 본문과 기관 정책에 따라 처리 목적과 범위, 접근·보존·폐기를 사전에 검토한다.

10. 프로토타이핑

프로토타이핑은 아직 없는 상호작용·정보·업무 대안을 구체적인 모형으로 만들어 이해관계자가 보고 수행하며 피드백하게 하는 기법이다. 말로 설명하기 어려운 상태와 흐름을 탐색하는 데 유용하지만, 보기 좋은 화면이 요구의 타당성이나 기술 실현 가능성을 증명하지는 않는다.

수강신청에서는 접수·처리·승인·거절·보류 상태와 사유를 다른 충실도로 표현할 수 있다. 시험할 질문을 먼저 정하고, “이 화면이 마음에 드는가?”가 아니라 “지금 신청이 접수되었는지, 다음에 무엇을 해야 하는지 말해 달라”고 과업을 준다. 장애학생과 보조기술 사용 조건도 초기부터 포함한다.

피드백은 화면 수정 목록과 요구 후보를 분리한다. 색상 변경은 설계 의견일 수 있지만 보류 상태를 실패로 오해했다는 관찰은 정보·용어 요구의 근거다. 프로토타입의 가짜 데이터·생략 기능·확정되지 않은 정책을 분명히 표시해 이미 구현이 약속되었다는 오해를 막는다.

11. 포커스 그룹

포커스 그룹은 비슷하거나 관련된 특성을 가진 참여자들이 진행자의 질문에 서로 반응하며 인식·언어·차이를 탐색하는 집단 토의다. 다양한 학생이 공정성, 결과 설명과 우선 배정을 어떻게 이해하는지 빠르게 비교할 수 있다. 합의나 통계적 대표성을 얻는 기법은 아니다.

참여자 구성이 발언 안전성과 주제에 맞는지 살핀다. 학생과 최종 성적·예외를 결정하는 교직원을 같은 집단에 넣으면 솔직한 경험이 가려질 수 있다. 진행자는 모든 사람이 말할 경로를 만들고, 동조·갈등·침묵과 비언어 반응을 기록한다. 민감 경험은 개별 인터뷰 선택지를 제공한다.

산출물은 공통 주제, 서로 다른 관점, 사용하는 표현과 추가 질문이다. 한 사람의 강한 주장과 집단의 분포를 혼동하지 않고 설문·개별 인터뷰·기록으로 확인한다. 포커스 그룹이 적합한지는 참여자 상호작용이 정보를 더 만드는가로 판단한다.

12. 사용자 여정

사용자 여정은 한 사용자가 목표를 향해 시간순으로 거치는 단계, 접점, 행동, 정보, 어려움과 결과를 연결한다. 시스템 화면 흐름보다 넓어 신청 준비, 학과 문의, 본 신청, 결과 확인, 이의·대체 강좌 탐색까지 볼 수 있다. 감정 곡선만 그리는 자료가 아니다.

졸업예정 학생과 신입생처럼 의미 있는 맥락별 여정을 실제 인터뷰·관찰로 만든다. 각 단계에 목표, 촉발 사건, 사용 채널, 필요한 정보, 규칙, 실패와 지원 역할을 붙인다. 결과 미확인 뒤 새로 고침·친구 문의·상담 전화로 이어지는 흐름은 UR-001, ASM-001과 상담 업무를 한 장면에 연결한다.

여정은 개인의 경험을 모든 사용자에게 일반화하거나 미래 화면을 정당화하는 데 쓰지 않는다. 근거가 없는 단계는 가정으로 표시하고 다른 참여자·데이터로 확인한다. 업무 프로세스가 조직의 수행을 중심으로 본다면 사용자 여정은 사용자의 목표와 경험을 중심으로 본다는 차이를 유지한다.

13. 시나리오

시나리오는 특정 상황에서 주체와 시스템·업무가 상호작용해 결과에 이르는 구체적인 이야기다. 추상적인 규칙을 실제 사례에 적용하고 정상·대안·예외·경계 조건을 탐색하는 데 유용하다. 모든 가능한 경우를 완전하게 열거하는 형식은 아니다.

“우선 배정 기간에 졸업예정 학생이 정원 한 자리 남은 전공필수를 신청하는 동시에 학사 규칙 서비스가 지연된다”처럼 주체, 시작 상태, 사건과 기대 결과를 둔다. 참여자에게 다음 행동·판정·필요 정보와 책임자를 묻고 RULE-004, RULE-005, IR-001, DR-001의 공백을 표시한다.

시나리오는 실제 사례, 위험과 경계값에서 선택한다. 행복 경로만 쓰면 예외를 숨기고, 극단 사례만 쓰면 일상 가치가 가려진다. 결과는 요구·시험의 후보가 되지만 4부에서 중복·모순·범위를 분석한 뒤 정제한다.

14. 유스케이스

유스케이스는 목표를 가진 액터와 대상 시스템 사이의 상호작용을 주 흐름·대안·예외 흐름으로 구조화한다. 시스템 경계와 외부에 보이는 책임을 찾는 데 좋다. 화면 설계 순서나 내부 코드 절차를 쓰는 형식은 아니다.

‘강좌 신청’ 유스케이스라면 학생의 자격 있는 요청을 시작 조건으로 두고, 접수·규칙 평가·승인 또는 거절·결과 제공을 주 흐름에 둔다. 정원 소진, 중복, 외부 지연과 보류, 취소를 대안·예외로 탐색한다. 각 단계가 필요로 하는 규칙·데이터·인터페이스를 질문한다.

도출 단계의 유스케이스는 빈칸과 충돌을 드러내는 탐색 모델이다. 지나치게 빨리 상세화하면 현재 해결 방식에 고정되고 사용자 여정·조직 업무를 놓친다. 시스템 밖의 수동 예외 처리는 유스케이스에서 사라지지 않도록 업무 프로세스와 함께 본다.

15. 이벤트 분석

이벤트 분석은 시스템이나 업무가 반응해야 하는 외부·시간·상태 사건을 식별하고, 발생 조건·필요 정보·응답·후속 상태를 찾는 기법이다. 사용자가 시작하지 않는 요구와 시간 기반 업무를 발견하는 데 강하다.

수강신청의 외부 이벤트는 학생 요청과 정책 변경, 시간 이벤트는 신청 시작·마감과 보류 재평가 기한, 상태 이벤트는 정원 소진·학적 변경·외부 서비스 복구다. 각 이벤트에 “누가 알리는가?”, “중복·지연·순서 역전이면?”, “처리하지 못하면?”을 묻는다.

이벤트 목록만으로 프로세스 순서와 목적을 다 설명할 수는 없다. 로그·인터페이스·상태 모델과 대조한다. 이벤트의 소유자와 탐지 근거가 없거나 응답 뒤 최종 상태가 정의되지 않았다면 요구 후보가 아직 충분하지 않다.

16. 업무 프로세스 분석

업무 프로세스 분석은 5장의 현행·목표 흐름을 입력으로 활동·결정·인계·대기·재작업을 검토하여 요구 후보와 업무 변화 조건을 찾는다. 화면이나 한 부서만 최적화해 전체 시간이 늘어나는 일을 막는다.

수강편람 등록부터 폐강까지 단계마다 입력·출력, 역할, 규칙, 데이터, 시스템과 성과를 붙인다. 반복 제출이 어디에서 중복 상태를 만들고 상담·재처리로 넘어가는지, 보류가 어느 역할의 작업 목록에 들어가고 언제 끝나는지 추적한다. 현행 수작업이 제거 대상인지 필요한 통제인지 이유를 묻는다.

산출물은 병목·공백·중복·통제와 현행-목표 차이에서 나온 요구·조직 조치 후보다. 평균 처리시간만 보지 않고 오류·공정성·복구·접근성도 함께 본다. IIBA의 기법 안내도 프로세스 분석을 효율성과 효과, 가치 창출 기회를 살피는 기법으로 제시한다.

17. 인터페이스 분석

인터페이스 분석은 시스템·사람·조직 사이에서 교환되는 데이터, 사건, 책임과 오류를 조사한다. API 필드 목록에 한정되지 않는다. 통합인증, 학사 규칙, 알림뿐 아니라 학생-상담원, 교무처-학과의 업무 인계도 인터페이스다.

각 접점에 제공자·소비자, 목적, 데이터 의미·원본·시점, 촉발 조건, 순서·중복, 시간 제한, 정상·부분·실패 응답, 보안·개인정보, 변경·장애 책임을 기록한다. IR-001에서는 유효한 판정 정보의 조건, 시간 제한, 보류 생성과 재평가·통지 책임을 외부 서비스 소유자와 교무처가 함께 확인해야 한다.

인터페이스 문서가 존재해도 실제 호출과 다르거나 업무 의미가 빠질 수 있으므로 추적 로그·계약·운영자 인터뷰·장애 시나리오로 교차 확인한다. 완료 기준은 모든 필드를 아는 것이 아니라 경계에서 정보나 책임이 유실될 때도 의미 있는 상태와 담당자가 남는가이다.

기법을 선택할 때는 익숙함보다 조사 질문과 증거의 성격을 먼저 본다. 다음 표는 절대적인 배정표가 아니라 7장의 도출 계획을 검토하기 위한 출발점이다.

알아내려는 것	우선 기법	보완 기법	단독 사용 시 놓치기 쉬운 것
개인의 실제 경험·판단	인터뷰·관찰	사용자 여정·화면 분석	기억 편향 또는 행동의 목적
집단의 분포·빈도	설문·데이터 분석	인터뷰·문서 분석	왜 발생했는지와 기록되지 않은 집단
규칙의 권한 있는 근거	문서 분석·워크숍	시나리오·기존 시스템 분석	문서와 실제 적용의 차이
부서 간 충돌·인계	워크숍·프로세스 분석	개별 인터뷰·관찰	권력 차이로 말하지 못한 의견
암묵적 수작업·우회	관찰·기존 시스템 분석	인터뷰·데이터 분석	관찰할 수 없는 드문 사건
미래 정보·상호작용	프로토타이핑·시나리오	인터뷰·접근성 평가	업무 타당성·기술 실현 가능성
시스템 밖 시간·상태 사건	이벤트 분석	로그·인터페이스 분석	사건 사이의 전체 업무 목적
경계의 데이터·책임	인터페이스 분석	장애 시나리오·운영자 인터뷰	내부 처리와 계약 밖의 관행

기법 조합에는 선후 관계가 있다. 문서와 로그를 먼저 읽으면 인터뷰에서 구체적인 사례를 물을 수 있지만, 그 자료의 분류 체계를 사실로 고정할 위험도 있다. 반대로 인터뷰부터 하면 참여자의 언어를 얻지만 강한 첫 설명이 이후 분석을 지배할 수 있다. 그래서 첫 탐색 뒤 가설을 기록하고, 다음 기법이 그 가설을 반박할 수 있도록 설계한다. 학생 인터뷰에서 ‘상태 미표시’ 가설이 나왔다면 로그는 반복 요청의 시각 관계를 보고, 관찰은 화면을 본 뒤 실제 행동을 보며, 반례 인터뷰는 재시도하지 않은 학생의 판단을 찾는다.

모든 활동에 공통으로 사용할 준비·정리 기준도 있다.

준비: 조사 질문, 참여자·출처 선정 근거, 필요한 선행 자료, 기록·동의·접근성, 민감 정보와 중단 조건을 정했는가?
수행: 사실과 해석을 구분하고, 예상과 다른 정보·반례·침묵을 기록하며, 참여자가 이해하지 못한 용어를 강요하지 않았는가?
정리: 원자료 위치, 관찰·발언 요약, 요구 후보·가정·쟁점, 연결된 ID, 확인 상태와 후속 책임자가 있는가?
교차 확인: 같은 결론을 반복하는 출처가 아니라 서로 다른 한계를 가진 출처를 비교했는가?
종료: 계획한 질문에 필요한 근거 수준을 충족했는지, 남은 불확실성과 다음 분석 단계의 사용 범위를 밝혔는가?

예를 들어 ‘학생 설문 1회’는 빠르고 저렴해 보여도 장애학생의 실제 조작 장벽, 규칙의 공식 근거와 외부 장애 복구를 답하지 못한다. 반대로 모든 학생을 길게 관찰할 필요도 없다. 로그로 규모를 찾고 의미 있는 패턴과 조건을 표집해 인터뷰·관찰하며, 정책과 실패는 별도의 소유자·시나리오로 확인하는 편이 목적에 맞다.

비용과 일정이 부족할 때는 기법을 무작정 줄이지 말고 불확실성이 초래할 피해를 기준으로 선택한다. BR-001의 기준선이 없으면 투자 성과를 판정할 수 있으므로 데이터 정의와 분석을 생략하기 어렵다. RULE-005의 예외·동률이 불명확하면 잘못된 배정 피해가 생길 수 있으므로 정책 소유자가 참여하는 문서 분석과 시나리오 검토가 우선이다. 반면 여러 화면 대안을 고해상도 프로토타입으로 모두 만드는 일은 낮은 충실도의 모형과 핵심 과업 관찰로 줄일 수 있다.

민감도도 선택을 바꾼다. 예외 승인이나 접근 장벽을 여러 부서 앞에서 말하기 어려운 참여자에게 워크숍만 요구하지 않고 개별 인터뷰·비동기 입력을 제공한다. 실제 개인정보가 없어도 질문에 답할 수 있으면 합성 데이터나 비식별 집계를 사용한다. 원자료가 꼭 필요하다면 접근 역할, 분석 환경, 반출 금지와 폐기 시점을 활동 계획에 넣는다. 이러한 조정은 부가적인 연구 운영이 아니라 신뢰할 수 있는 증거를 얻기 위한 기법 설계의 일부다.

이 장의 17개 기법은 체크리스트처럼 모두 수행할 목록이 아니다. SWEBOK v4.0a도 이해관계자 집단에 따라 적합한 기법이 다를 수 있음을 설명하고, IIBA KnowledgeHub는 인터뷰·관찰·문서·데이터·프로토타입·워크숍 등을 서로 다른 분석 기법으로 제시한다.

수강신청 도출에서는 깊이와 맥락은 인터뷰·관찰, 규모는 설문·데이터, 권한 있는 근거는 문서, 충돌은 워크숍·시나리오, 미래 상호작용은 프로토타입으로 보완한다. 선택 기준은 조사 질문, 출처의 특성, 불확실성, 위험, 비용, 접근성과 민감도다. 다음 장에서는 어떤 기법을 쓰든 표면적 기능 요청에 머물지 않도록 질문을 정상·예외·경계·수량·권한·실패로 확장한다.

선택한 기법의 한계와 이를 보완할 다음 증거가 계획표에 함께 적혀 있어야 기법 조합이 실제 조사 순서로 작동한다.

2. 근거와 예외 표시

본문의 판단 질문으로 누락된 근거와 예외를 표시한다.

3. 다음 행동 기록

확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.