# 사용자 요구사항 (User Requirements)

## 개요

**사용자 요구사항**(User Requirements)은 소프트웨어 공학 및 시스템 개발 과정에서 최종 사용자나 이해관계자가 시스템이 수행해야 할 기능, 성능, 제약 조건 등을 자연어(Natural Language)로 기술한 문서입니다. 이는 기술적인 구현 세부 사항보다는 "시스템이 무엇을 해야 하는가(What)"에 초점을 맞추며, 개발자와 사용자 간의 의사소통을 위한 공통된 이해의 기반이 됩니다.

사용자 요구사항 명세서(User Requirements Specification, URS)는 프로젝트의 성공적인 완수를 위해 필수적인 단계로, 명확하고 모호함이 없는 기술이 요구됩니다. 이 문서는 이후의 시스템 요구사항 명세서(System Requirements Specification, SRS)로 전환되는 기초 자료가 되며, 프로젝트 범위(Scope)를 정의하고 이해관계자의 기대치를 관리하는 데 핵심적인 역할을 합니다.

## 사용자 요구사항의 특징과 목적

사용자 요구사항은 개발자 중심의 기술적 언어보다는 비즈니스나 업무 관점에서 서술됩니다. 주요 특징과 목적은 다음과 같습니다.

### 1. 비기술적 언어 사용
개발자가 아닌 비즈니스 분석가, 프로젝트 매니저, 최종 사용자가 모두 이해할 수 있도록 전문 용어를 최소화하거나 설명을 포함하여 작성합니다. 이는 기술적 장벽을 낮추고 의사소통의 효율성을 높입니다.

### 2. 비즈니스 가치 중심
시스템이 해결해야 할 실제 비즈니스 문제나 사용자 경험을 강조합니다. 예를 들어, "데이터베이스에 SQL 쿼리를 실행한다"가 아닌 "사용자가 실시간으로 재고 상태를 조회할 수 있어야 한다"와 같이 표현합니다.

### 3. 검증 가능성
요구사항은 테스트 가능해야 합니다. "시스템이 빠르다"와 같은 모호한 표현보다는 "페이지 로딩 시간이 2초 이내여야 한다"와 같이 정량적 지표가 포함되어야 합니다.

## 사용자 요구사항과 시스템 요구사항의 차이

혼동하기 쉬운 두 개념의 차이를 명확히 구분하는 것이 중요합니다.

| 구분 | 사용자 요구사항 (User Requirements) | 시스템 요구사항 (System Requirements) |
| :--- | :--- | :--- |
| **대상 독자** | 비즈니스 담당자, 고객, 프로젝트 관리자 | 개발자, 테스트 엔지니어, 아키텍트 |
| **기술적 깊이** | 낮음 (비즈니스 관점) | 높음 (기술적 구현 관점) |
| **내용 예시** | "사용자는 주문 내역을 PDF로 다운로드할 수 있어야 한다." | "시스템은 iText 라이브러리를 사용하여 서버에서 PDF 파일을 생성하고, MIME 타입을 `application/pdf`로 설정하여 응답해야 한다." |
| **수정 빈도** | 상대적으로 낮음 (비즈니스 목표 변경 시) | 상대적으로 높음 (기술 스택이나 설계 변경 시) |

## 요구사항 수집 및 분석 방법

효과적인 사용자 요구사항을 도출하기 위해서는 다양한 기법이 사용됩니다.

### 1. 인터뷰 (Interviews)
주요 이해관계자와의 1:1 또는 그룹 인터뷰를 통해 직접적인 니즈(Needs)를 파악합니다. 개방형 질문을 통해 숨겨진 요구사항을 발견하는 데 유용합니다.

### 2. 설문 조사 (Surveys)
대규모의 사용자 집단을 대상으로 표준화된 질문을 통해 정량적 데이터를 수집합니다. 통계적 유의미성을 확보할 수 있다는 장점이 있습니다.

### 3. 관찰 (Observation)
현장(Ethnography)에서 사용자의 실제 업무 프로세스를 관찰하여 사용자가 스스로 인지하지 못하는 비효율성이나 숨겨진 요구사항을 발견합니다.

### 4. 프로토타이핑 (Prototyping)
초기 버전을 빠르게 제작하여 사용자에게 보여주고 피드백을 받으며 요구사항을 정교화합니다. 이는 모호한 요구사항을 명확히 하는 데 매우 효과적입니다.

## 요구사항 명세서 작성 시 고려사항 (INVEST 원칙 등)

좋은 사용자 요구사항은 다음과 같은 품질 기준을 충족해야 합니다.

*   **명확성 (Clarity):** 문장이 명확하고 해석의 여지가 없어야 합니다.
*   **일관성 (Consistency):** 다른 요구사항과 충돌하지 않아야 합니다.
*   **완전성 (Completeness):** 필요한 모든 기능과 제약 조건이 포함되어야 합니다.
*   **추적 가능성 (Traceability):** 각 요구사항이 특정 비즈니스 목표나 하위 요구사항과 연결되어야 합니다.
*   **검증 가능성 (Verifiability):** 테스트 케이스를 통해 충족 여부를 판단할 수 있어야 합니다.

## 결론

사용자 요구사항은 소프트웨어 개발 프로젝트의 나침반과 같습니다. 부정확하거나 불완전한 요구사항은 프로젝트의 범위 비확장(Scope Creep), 예산 초과, 일정 지연으로 이어질 수 있습니다. 따라서 이해관계자와의 지속적인 소통을 통해 요구사항을 명확히 정의하고, 변경 관리 과정을 엄격히 적용하는 것이 프로젝트 성공의 핵심 요소입니다.

## 관련 문서 및 참고 자료

*   [시스템 요구사항 명세서 (SRS)]
*   [요구사항 공학 (Requirements Engineering)]
*   [애자일 개발 방법론 (Agile Development)]
*   [IEEE 830 표준: 소프트웨어 요구사항 명세서 작성 가이드]

## 기능적 요구사항의 정의와 구성

**기능적 요구사항(Functional Requirements)**은 시스템이 특정 입력에 대해 어떻게 반응해야 하는지, 그리고 시스템이 반드시 수행해야 하는 구체적인 동작과 서비스를 정의한 것입니다. 이는 "시스템이 무엇을 하는가(What the system does)"에 집중하며, 비즈니스 프로세스를 자동화하거나 사용자의 목적을 달성하기 위한 핵심 기능을 기술합니다.

기능적 요구사항은 일반적으로 다음과 같은 **입력-처리-출력(Input-Process-Output)** 관점에서 구성됩니다.

*   **입력(Input):** 시스템이 동작하기 위해 필요한 데이터나 사용자의 행위 (예: 로그인 아이디와 비밀번호 입력)
*   **처리(Process):** 입력된 데이터를 바탕으로 시스템이 수행하는 논리적 연산이나 규칙 (예: DB 내 사용자 정보와 입력값 일치 여부 확인)
*   **출력(Output):** 처리 결과로 사용자에게 제공되는 정보나 시스템의 상태 변화 (예: 메인 페이지로의 화면 전환 및 로그인 성공 메시지 출력)

## 기능적 요구사항의 기술 방법

기능적 요구사항을 구체화하기 위해 실무에서는 다음과 같은 표준 방법론을 사용합니다.

### 1. 유스케이스 (Use Case)
사용자와 시스템 간의 상호작용을 시나리오 형태로 기술하는 방법입니다. '액터(Actor)'와 '목표'를 중심으로 시스템의 동작 흐름을 정의합니다.

**[유스케이스 작성 예시 템플릿]**
| 항목 | 내용 |
| :--- | :--- |
| **유스케이스명** | 상품 주문하기 |
| **액터(Actor)** | 구매 회원 |
| **사전 조건** | 사용자가 로그인 상태이며, 장바구니에 상품이 담겨 있어야 함 |
| **기본 흐름 (Basic Flow)** | 1. 사용자가 '주문하기' 버튼을 클릭한다. <br> 2. 시스템이 주문 정보를 확인하고 결제 수단 선택 화면을 표시한다. <br> 3. 사용자가 결제 수단을 선택하고 결제를 요청한다. <br> 4. 시스템이 결제를 처리하고 주문 완료 메시지를 출력한다. |
| **대안 흐름 (Alternative Flow)** | 4-a. 결제 잔액이 부족한 경우, 시스템은 오류 메시지를 출력하고 결제 수단 선택 화면으로 되돌아간다. |
| **사후 조건** | 주문 데이터가 DB에 저장되고, 재고 수량이 차감된다. |

### 2. 사용자 스토리 (User Story)
애자일 방법론에서 주로 사용하며, 최종 사용자의 관점에서 가치를 중심으로 짧게 기술합니다.
*   **형식:** `[페르소나]로서, [목표]를 위해, [기능]을 원한다.`
*   **예시:** "구매자로서, 빠른 결제를 위해, 이전에 사용한 카드 정보를 저장하는 기능을 원한다."

### 3. 기능 계층도 (Functional Hierarchy Diagram)
시스템의 전체 기능을 최상위 기능부터 하위 세부 기능까지 트리 구조로 도식화하여 기능 간의 포함 관계와 범위를 한눈에 파악할 수 있게 합니다.

## 비즈니스 프로세스 연결성

사용자 요구사항의 '비즈니스 가치 중심' 접근은 단순히 기능을 나열하는 것이 아니라, 해당 기능이 실제 **비즈니스 프로세스(Business Process)**의 어느 단계에서 어떤 가치를 창출하는지를 정의하는 것입니다.

예를 들어, "알림 서비스 제공"이라는 기능적 요구사항은 다음과 같은 비즈니스 프로세스로 연결됩니다.
*   **비즈니스 목표:** 고객 재방문율 증대 및 구매 전환율 향상
*   **프로세스 연결:** [장바구니 상품 방치] $\rightarrow$ [리마인드 알림 발송] $\rightarrow$ [사용자 재접속] $\rightarrow$ [결제 완료]
이처럼 기능적 요구사항은 비즈니스 워크플로우의 병목을 해결하거나 효율성을 높이는 수단으로서 정의되어야 합니다.

## 기능적 vs 기술적 요구사항 대비 사례

사용자 요구사항(What)과 이를 구현하기 위한 시스템/기술적 요구사항(How)의 차이를 명확히 하기 위한 대비표 예시입니다.

| 구분 | 기능적 요구사항 (User/Functional - What) | 기술적 요구사항 (System/Technical - How) |
| :--- | :--- | :--- |
| **인증** | "사용자는 생체 인식(지문, FaceID)을 통해 간편하게 로그인할 수 있어야 한다." | "iOS의 LocalAuthentication 프레임워크를 사용하여 생체 인증 토큰을 검증하고 JWT를 발급한다." |
| **성능** | "대량의 상품 목록 조회 시 사용자가 체감하는 대기 시간이 없어야 한다." | "Redis 캐시 계층을 도입하여 빈번히 조회되는 상품 데이터를 메모리에 저장하고 응답 시간을 100ms 이내로 제한한다." |
| **데이터** | "관리자는 월간 매출 보고서를 엑셀 파일 형태로 내려받을 수 있어야 한다." | "Apache POI 라이브러리를 사용하여 서버 사이드에서 `.xlsx` 파일을 생성하고 스트림 방식으로 다운로드 API를 구현한다." |

## INVEST 원칙의 세분화 적용 사례

INVEST 원칙 중 **독립적(Independent)**과 **작은(Small)** 관점은 요구사항의 입도(Granularity)를 결정하는 핵심 기준입니다. 요구사항이 너무 크면 추정이 어렵고, 너무 얽혀 있으면 변경 시 영향도 파악이 어렵습니다.

**[INVEST 원칙 적용 전후 비교]**

| 구분 | 적용 전 (Bad Case) | 적용 후 (Good Case) | 개선 포인트 |
| :--- | :--- | :--- | :--- |
| **요구사항** | "사용자는 마이페이지에서 내 정보 수정, 비밀번호 변경, 회원 탈퇴를 할 수 있다." | 1. "사용자는 마이페이지에서 기본 인적 사항을 수정할 수 있다." <br> 2. "사용자는 보안을 위해 비밀번호를 변경할 수 있다." <br> 3. "사용자는 계정을 완전히 삭제(탈퇴)할 수 있다." | **Small:** 하나의 거대한 요구사항을 세 개의 독립적인 기능으로 분리하여 개발 및 테스트 가능하게 함. |
| **요구사항** | "결제 시스템을 구축하고, 결제 완료 후 자동으로 이메일 알림을 보내며, 포인트 적립을 처리한다." | 1. "시스템은 선택한 결제 수단으로 결제를 처리한다." <br> 2. "결제 완료 이벤트 발생 시, 알림 서비스가 이메일을 발송한다." <br> 3. "결제 완료 후, 포인트 서비스가 정해진 비율로 포인트를 적립한다." | **Independent:** 결제-알림-포인트 기능을 분리하여, 알림 서비스에 장애가 발생해도 결제 기능은 정상 작동하도록 독립성을 확보함. |