요구사항 도출 기법

## 요구사항 도출 기법 (Requirements Elicitation Techniques)

요구사항 도출(Requirements Elicitation)은 소프트웨어 개발 초기 단계에서 **사용자와 이해관계자의 요구사항을 수집하고 분석하는 과정**입니다. 이 과정은 프로젝트의 성공 여부를 결정짓는 중요한 단계이며, 요구사항이 명확하지 않으면 프로젝트의 방향이 흔들리고, 추가 비용과 시간 낭비가 발생할 수 있습니다.

요구사항 도출을 위해 다양한 기법이 사용되며, 각 기법은 상황과 프로젝트의 특성에 맞게 선택해야 합니다. 주요 기법으로는 **인터뷰, 설문 조사, 워크숍, 브레인스토밍, 프로토타이핑** 등이 있습니다.

### 1. **인터뷰(Interview)**
인터뷰는 이해관계자(Stakeholder)와 **1대1 대화**를 통해 요구사항을 직접 수집하는 방법입니다. 인터뷰는 **구조화된 인터뷰**, **비구조화된 인터뷰**, **반구조화된 인터뷰**로 나눌 수 있습니다.

#### 유형
- **구조화된 인터뷰**: 사전에 준비된 질문 리스트를 기반으로 진행합니다.
- **비구조화된 인터뷰**: 정해진 질문 없이 자유롭게 대화를 나누며 요구사항을 수집합니다.
- **반구조화된 인터뷰**: 기본 질문 리스트는 있지만, 상황에 따라 추가 질문이 가능합니다.

#### 장점
- 이해관계자의 생각과 기대를 직접 확인할 수 있습니다.
- 요구사항의 상세한 내용을 파악할 수 있습니다.

#### 단점
- 시간과 비용이 많이 소요될 수 있습니다.
- 인터뷰어의 능력에 따라 결과가 달라질 수 있습니다.

### 2. **설문 조사(Questionnaire/Survey)**
설문 조사는 다수의 이해관계자에게 **질문지를 배포**하여 요구사항을 수집하는 방법입니다. 이 방법은 대규모 사용자 집단의 의견을 수집하는 데 유용합니다.

#### 유형
- **폐쇄형 설문**: 예/아니오, 1~5점 척도 등 미리 정해진 답변을 선택하게 합니다.
- **개방형 설문**: 자유롭게 의견을 작성할 수 있는 질문으로 구성됩니다.

#### 장점
- 많은 사람의 의견을 짧은 시간에 수집할 수 있습니다.
- 데이터 분석이 용이합니다.

#### 단점
- 질문의 품질에 따라 결과가 영향을 받을 수 있습니다.
- 응답률이 낮을 경우 신뢰성이 떨어질 수 있습니다.

### 3. **워크숍(Workshop)**
워크숍은 다양한 이해관계자가 한 자리에 모여 **의견을 교환하고, 협의하는 회의 방식**입니다. 이를 통해 요구사항에 대한 공통된 이해를 도출할 수 있습니다.

#### 장점
- 여러 이해관계자의 의견을 동시에 수렴할 수 있습니다.
- 토론을 통해 문제를 신속하게 해결할 수 있습니다.

#### 단점
- 많은 사람들이 모이기 어렵고, 일정 조율이 필요합니다.
- 토론이 길어질 경우 비효율적일 수 있습니다.

### 4. **브레인스토밍(Brainstorming)**
브레인스토밍은 **자유로운 아이디어 제시**를 통해 창의적인 요구사항을 도출하는 방법입니다. 팀원들이 서로의 생각을 공유하며, 아이디어를 발전시킬 수 있습니다.

#### 장점
- 창의적이고 다양한 아이디어를 도출할 수 있습니다.
- 빠르게 많은 요구사항을 수집할 수 있습니다.

#### 단점
- 제시된 아이디어의 품질이 낮을 수 있습니다.
- 참가자 간의 의견 충돌이 발생할 수 있습니다.

### 5. **프로토타이핑(Prototyping)**
프로토타이핑은 **시제품(Prototype)을 만들어** 사용자에게 보여주고 피드백을 받아 요구사항을 도출하는 방법입니다. 특히 요구사항이 불명확하거나 사용자 경험(UI/UX)이 중요한 프로젝트에서 유용합니다.

#### 유형
- **페이퍼 프로토타입**: 손으로 그린 화면 설계도로, 간단하게 아이디어를 표현할 수 있습니다.
- **고충실도(High-fidelity) 프로토타입**: 실제와 가까운 수준으로 만들어진 시제품입니다.

#### 장점
- 사용자가 요구사항을 쉽게 이해하고, 명확한 피드백을 제공할 수 있습니다.
- 요구사항의 불확실성을 줄이고, 개발 리스크를 낮출 수 있습니다.

#### 단점
- 프로토타입 개발에 시간과 자원이 소요될 수 있습니다.
- 사용자가 프로토타입을 실제 제품으로 오해할 위험이 있습니다.

### 6. **관찰(Observation)**
관찰 기법은 사용자의 작업 환경을 직접 **관찰하고 분석**하여 요구사항을 도출하는 방법입니다. 특히, 사용자 인터뷰나 설문 조사에서 정확한 정보를 얻기 어려운 경우 유용하게 사용됩니다.

#### 장점
- 사용자의 실제 작업 방식과 문제점을 파악할 수 있습니다.
- 인터뷰에서 놓칠 수 있는 중요한 정보를 얻을 수 있습니다.

#### 단점
- 시간이 오래 걸릴 수 있습니다.
- 관찰하는 동안 사용자가 평소와 다르게 행동할 가능성이 있습니다.

### 7. **사용 시나리오(Use Case)**
사용 시나리오는 사용자가 시스템을 어떻게 사용할지를 **시나리오 형식으로 문서화**한 것입니다. 이를 통해 시스템의 기능 요구사항을 명확히 정의할 수 있습니다.

#### 장점
- 사용자 요구사항을 직관적으로 표현할 수 있습니다.
- 시스템의 기능과 사용 흐름을 명확하게 정의할 수 있습니다.

#### 단점
- 모든 사용 시나리오를 작성하는 데 시간이 소요될 수 있습니다.
- 비정형적인 요구사항을 반영하기 어렵습니다.

### 요구사항 도출 기법 비교표

| 기법            | 장점                                | 단점                              | 적용 시기                         |
|-----------------|-------------------------------------|-----------------------------------|----------------------------------|
| 인터뷰          | 상세한 요구사항 수집 가능            | 시간 소요, 인터뷰어 능력 의존     | 초기 요구사항 수집 단계           |
| 설문 조사       | 많은 사람의 의견 수집 가능           | 낮은 응답률, 질문 품질 문제       | 대규모 사용자 집단이 있을 때      |
| 워크숍          | 다양한 의견 수렴, 문제 해결 용이     | 일정 조율 어려움, 시간 소요       | 복잡한 요구사항 도출 시           |
| 브레인스토밍    | 창의적인 아이디어 도출               | 아이디어 품질 문제, 의견 충돌     | 초기 아이디어 단계                |
| 프로토타이핑    | 명확한 피드백 제공, 요구사항 명확화  | 개발 시간과 자원 필요             | UI/UX 중심의 프로젝트             |
| 관찰            | 실제 작업 방식 파악 가능             | 시간 소요, 사용자의 행동 변화 가능| 실제 사용 환경 분석 시            |
| 사용 시나리오   | 직관적 표현, 기능 정의 용이          | 모든 시나리오 작성 어려움         | 기능 요구사항 정의 단계           |

### 결론
요구사항 도출 기법은 프로젝트의 특성, 이해관계자의 요구, 개발 환경 등에 따라 적절하게 선택하여 사용해야 합니다. 다양한 기법을 조합하여 사용하면 요구사항의 **완전성과 일관성**을 높일 수 있습니다. 이 과정에서 명확하고 상세한 요구사항을 정의하는 것이 성공적인 소프트웨어 개발의 핵심입니다.