요구 수집 기법과 증거화

핵심 요약

수집 기법마다 잘 드러나는 정보와 편향이 다르다. 인터뷰는 맥락과 암묵 지식, 워크숍은 부서 간 충돌과 합의, 설문은 넓은 집단의 경향, 문서 분석은 공식 규칙, 관찰은 실제 행동, 데이터·로그 분석은 실행 흔적, 프로토타입은 구체적 피드백에 강점이 있다. 하나의 기법만으로 완전성을 가정하지 않고 상호 보완한다.

학습 목표

주요 요구 수집 기법의 적용 조건·장점·한계·산출물을 비교한다.
암묵 지식·갈등·대규모 표본·실제 행동 등 조사 목적에 맞는 기법을 선택한다.
질문·표본·진행자·프로토타입 등에 의한 편향을 식별한다.
수집 결과를 출처·시점·결정·미결·근거와 함께 증거화한다.

1. 수집 기법 비교

기법	적합한 상황	장점	한계·편향	대표 산출물
인터뷰	복잡한 맥락·암묵 지식·예외 파악	심층 질문과 후속 확인	인터뷰어 유도, 기억 오류, 소수 편향	질문지, 기록, 요구 후보, 쟁점
워크숍	여러 부서의 용어·규칙 충돌과 합의	상호 검증과 빠른 의사결정	권력 관계, 다수 의견 편향, 일정 부담	합의안, 결정 로그, 미결 목록
설문	다수 사용자의 빈도·선호·현황 파악	넓은 표본, 정량 비교	질문 해석 차이, 낮은 응답률, 깊이 부족	응답 데이터, 통계, 후속 조사 대상
문서 분석	규정·절차·계약·보고 정의 확인	공식 근거와 기존 구조 파악	문서 노후화, 실제 업무와 차이	출처 목록, 규칙 후보, 불일치 목록
관찰	실제 작업 순서·우회·수기 처리 파악	말로 설명되지 않는 행동 확인	관찰 효과, 드문 예외 누락, 개인정보	관찰 기록, 업무 흐름, 예외·병목
데이터·로그 분석	값 분포·사용 빈도·오류·예외 확인	실제 실행 흔적과 규모 확인	품질 문제, 의미·의도 파악 한계	프로파일 결과, 패턴, 이상·공백
프로토타입	추상 요구를 구체화하고 사용성 확인	빠른 피드백, 용어·흐름 확인	화면 선호가 업무 요구를 대체, 범위 고착	시안, 피드백, 수정 요구, 가정

기법 명칭이나 산출물 형식은 조직마다 달라질 수 있지만, 무엇을 확인하려는지와 어떤 편향을 보완할지가 선택의 핵심이다.

2. 기법 선택 기준

다음 질문을 사용해 기법을 조합한다.

지식의 성격: 문서화된 규칙인가, 숙련자의 암묵 지식인가?
이해관계자 수: 소수 전문가인가, 다수 사용자 집단인가?
충돌 수준: 부서 간 용어·책임·우선순위 합의가 필요한가?
현행 증거: 실제 데이터·로그·문서가 존재하고 신뢰할 수 있는가?
업무 빈도: 일상 업무인가, 드문 고위험 예외인가?
새로움: 기존 업무 개선인가, 경험이 없는 신규 서비스인가?
시간·접근 제약: 현장 관찰과 개인정보 열람이 가능한가?

예: 반복 업무의 수기 우회를 찾으려면 관찰과 로그 분석을 결합하고, 여러 부서의 고객 정의 충돌을 해결하려면 사전 인터뷰·문서 분석 후 워크숍을 수행한다.

3. 수집과 증거화 흐름

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

조사 질문·범위·대상 선정
        ↓
기법·표본·일정·윤리/보안 조건 설계
        ↓
수집 수행 및 원문 근거 보존
        ↓
요구 후보·사실·가정·의견·쟁점 구분
        ↓
출처 간 교차 확인과 후속 질문
        ↓
결정·미결·추가 조사·책임자 기록
        ↓
이해관계자에게 기록 확인

증거 기록에는 일시, 참여자·출처, 기준 시점, 질문 또는 관찰 맥락, 원문 요약, 해석, 요구 후보, 결정, 이견, 미결 사항, 관련 파일·데이터 위치를 포함한다. 개인정보와 민감 정보는 접근 권한과 보존 정책을 준수한다.

4. 기법 조합 사례

상황: 콜센터 이관 시스템의 개선 요구를 조사한다. 상담원은 입력 화면이 느리다고 말하지만 로그상 응답 시간은 기준을 만족한다.

조합

인터뷰로 ‘느리다’가 시스템 응답인지 반복 입력·검색·승인 대기인지 분해한다.
현장 관찰로 복사·붙여넣기와 별도 메모 같은 우회 행동을 확인한다.
로그·사용 데이터로 화면 이동 횟수, 실패 검색, 재입력 빈도를 측정한다.
워크숍에서 상담·품질관리·시스템 담당자가 원인과 우선순위를 합의한다.
필요한 경우 프로토타입으로 개선된 흐름을 검증한다.

단일 성능 로그만으로 사용자 진술을 부정하거나, 사용자 체감만으로 서버 성능 문제라고 결론 내리지 않는 것이 핵심이다.

5. 비교와 구분

판단 목적	1차 추천 기법	보완 기법	주의점
암묵적 예외 파악	인터뷰·관찰	로그·문서	말과 실제 행동 차이 확인
부서 충돌 해결	워크숍	사전 인터뷰·근거 분석	권한자 독점 발언 통제
다수 사용자 경향	설문	표본 인터뷰·로그	표본 편향과 질문 해석
규정 의무 확인	문서 분석	준법 담당자 확인	최신 개정·적용 범위
신규 흐름 구체화	프로토타입	인터뷰·워크숍	화면이 요구 자체가 되지 않도록 함

시험 판단 포인트

수집 기법은 목적·대상·갈등·증거·접근 조건에 따라 조합한다.
인터뷰는 심층 맥락, 워크숍은 충돌·합의, 설문은 넓은 표본, 관찰은 실제 행동에 강점이 있다.
문서·데이터·로그는 근거가 되지만 최신성·품질·업무 맥락을 검증해야 한다.
프로토타입은 이해를 돕는 수단이며 특정 화면 해법을 요구로 고정하지 않는다.
수집 결과는 사실·가정·의견·결정·미결 사항과 출처를 구분해 증거화한다.

자주 틀리는 부분

한 기법에서 나온 결과만으로 요구가 완전하다고 판단하지 않는다.
설문 응답 수가 많다는 이유만으로 응답 표본의 대표성을 자동 인정하지 않는다.
워크숍의 다수 의견을 규정·책임 권한보다 항상 우선하지 않는다.
프로토타입의 화면 선호를 업무 정보 요구와 동일시하지 않는다.

모범 답안

인터뷰: ‘느리다’가 응답 시간, 입력량, 검색 실패, 승인 대기 중 무엇인지 구분하고 구체 사례를 수집한다.
관찰: 화면 전환 수, 중복 입력, 수기 메모, 다른 시스템 왕복, 대기 행동을 기록한다.
로그·사용 데이터 분석: 서버 응답뿐 아니라 검색 실패율, 재시도, 화면 이동, 입력 취소, 처리 완료까지의 전체 시간을 분석한다.
문서 분석: 목표 처리 절차와 실제 절차의 차이를 확인한다.
워크숍: 상담·운영·개발 담당자가 증거를 비교해 원인과 우선순위를 합의한다.
프로토타입: 개선된 흐름이 실제 처리 단계와 체감 시간을 줄이는지 검증한다. 모든 기록에 기준일·표본·출처·미결 사항을 남긴다.

01여러 부서가 ‘활성 고객’의 정의를 다르게 사용하고 있어 근거를 비교한 뒤 합의가 필요하다. 가장 적절한 중심 기법은? ① 무작위 설문만 실시한다. ② 관련 문서·데이터를 사전 분석한 뒤 다부서 워크숍을 수행한다. ③ 한 명의 개발자에게 정의를 결정하게 한다. ④ 화면 프로토타입만 배포한다.

정답 및 해설

정답: ②

부서별 의미 충돌은 근거를 준비한 워크숍에서 차이와 결정 권한을 명확히 하는 것이 적합하다.
①은 깊은 의미·책임 충돌을 해결하기 어렵다.
③은 이해관계자 합의와 권한 근거가 없다.
④는 데이터 정의 충돌을 화면으로 대체한다.

02다음 중 관찰 기법의 대표 강점은? ① 모든 규정의 법적 효력을 자동 판정한다. ② 실제 작업 순서와 말로 설명되지 않은 수기 우회를 확인한다. ③ 대규모 모집단의 통계적 대표성을 항상 보장한다. ④ 시스템 로그의 데이터 품질을 자동 수정한다.

관찰은 실제 작업 행동, 비공식 우회, 순서와 병목을 직접 확인하는 데 강점이 있다.
①·③·④는 관찰만으로 보장할 수 없는 기능이다.

03다음 기법과 주요 위험을 연결하시오. - A. 인터뷰 - B. 설문 - C. 워크숍 - D. 프로토타입 - 선택: ㉠ 화면 해법에 요구가 고착 ㉡ 질문 유도·기억 편향 ㉢ 낮은 응답률·표본 편향 ㉣ 권력 관계·다수 의견 편향

정답: A-㉡, B-㉢, C-㉣, D-㉠

인터뷰는 질문과 기억 편향, 설문은 응답·표본 편향, 워크숍은 권력 관계, 프로토타입은 해결책 고착을 주의한다.

04사용자는 시스템이 느리다고 말하지만 서버 로그는 기준을 만족한다. 원인을 조사하기 위한 기법 조합과 각 기법에서 확인할 증거를 설계하시오.