> For the complete documentation index, see [llms.txt](https://krjaeh0.gitbook.io/j-log/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://krjaeh0.gitbook.io/j-log/database/design/requirementanalysisoverview.md).

# RequirementAnalysisOverview

## 요구사항 분석이란?

* 사용자가 원하는 기능과 데이터를 정의하여 데이터베이스 및 시스템 설계의 기초를 다지는 과정이다.
* 불완전한 시스템, 높은 유지보수 비용, 성능 저하 문제를 예방할 수 있다.

***

## 요구사항 분석 목표

{% stepper %}
{% step %}

### 목표 1

사용자가 원하는 기능과 데이터를 정확하게 이해 한다.
{% endstep %}

{% step %}

### 목표 2

데이터의 흐름과 관계를 정의한다.
{% endstep %}

{% step %}

### 목표 3

데이터베이스 설계의 기초를 마련한다.
{% endstep %}
{% endstepper %}

***

## 요구사항 분석의 주요 활동

<table><thead><tr><th width="167">단계</th><th>설명</th></tr></thead><tbody><tr><td>요구사항 수집</td><td>사용자 인터뷰, 설문 조사, 문서 분석을 통해 정보 수집</td></tr><tr><td>요구사항 분류</td><td>기능적 요구사항 / 비기능적 요구사항으로 분류</td></tr><tr><td>요구사항 명세화</td><td>데이터 흐름도(DFD), 유스케이스 다이어그램 등으로 요구사항 문서화</td></tr><tr><td>요구사항 검증</td><td>사용자가 원하는 기능과 일치하는지 확인</td></tr></tbody></table>

***

### 요구사항 수집(Requirement Elicitation)

* 요구사항 수집 방법

| 방법                          | 설명                                      |
| --------------------------- | --------------------------------------- |
| 인터뷰(Interview)              | 이해관계자(Stakeholder)와 직접 대화하여 요구사항을 수집한다. |
| 설문 조사(Survey/Questionnaire) | 대규모 사용자를 대상으로 특정 질문을 통해 데이터를 수집한다.      |
| 문서 분석(Document Analysis)    | 기존 시스템 문서를 검토하여 요구사항 파악한다.              |
| 워크숍(Workshop)               | 여러 관계자와 회의를 통해 요구사항을 논의한다.              |
| 프로토타이핑(Prototyping)         | 간단한 모델을 제작하여 사용자 피드백을 받는다.              |

***

### 요구사항 분류(Requirement Classification)

* 수집한 요구사항을 기능적 요구사항(Functional Requirement)과 비기능적 요구사항(Non-functional Requirement)으로 분류할 수 있다.

{% stepper %}
{% step %}

### 기능적 요구사항

* 시스템이 무엇을 해야 하는지를 정의
* 데이터 저장, 조회, 수정, 삭제 등의 기능 포함
* 예시

<table><thead><tr><th width="100">ID</th><th>요구사항 설명</th></tr></thead><tbody><tr><td>FR-01</td><td>사용자는 로그인 후 상품을 검색할 수 있어야 한다.</td></tr><tr><td>FR-02</td><td>사용자는 장바구니에 상품을 추가할 수 있어야 한다.</td></tr><tr><td>FR-03</td><td>관리자는 상품 정보를 추가, 수정, 삭제할 수 있어야 한다.</td></tr><tr><td>FR-04</td><td>사용자는 주문 후 결제할 수 있어야 한다.</td></tr></tbody></table>
{% endstep %}

{% step %}

### 비기능적 요구사항

* 성능, 보안, 확장성 등 시스템이 어떻게 동작해야 하는지를 정의
* 예시

<table><thead><tr><th width="140">ID</th><th>요구사항 설명</th></tr></thead><tbody><tr><td>NFR-01</td><td>시스템은 초당 100건 이상의 주문을 처리할 수 있어야 한다.</td></tr><tr><td>NFR-02</td><td>사용자 로그인 시 2초 이내에 응답해야 한다.</td></tr><tr><td>NFR-03</td><td>비밀번호는 암호화되어 저장되어야 한다.</td></tr><tr><td>NFR-04</td><td>장애 발생 시 10초 이내에 자동 복구되어야 한다.</td></tr></tbody></table>
{% endstep %}
{% endstepper %}

***

### 요구사항 명세화 (Requirement Specification)

* 요구사항을 문서로 정리하고, 시각적으로 다이어그램을 활용하여 명확하게 표현해야 한다.
* 요구사항 명세화 도구

| 도구                                                 | 설명                          |
| -------------------------------------------------- | --------------------------- |
| 유스케이스 다이어그램 (Use Case Diagram)                     | 사용자와 시스템 간의 주요 기능을 표현       |
| 데이터 흐름도 (DFD, Data Flow Diagram)                   | 데이터가 어떻게 흐르고 처리되는지 시각적으로 표현 |
| 요구사항 명세서 (SRS, Software Requirement Specification) | 요구사항을 문서화하여 상세히 정리          |

{% stepper %}
{% step %}

### 유스케이스 다이어그램(Use Case Diagram)

사용자가 시스템과 상호작용하는 방식을 표현하는 다이어그램이다.

```
사용자  →  (로그인)  →  (상품 검색)  →  (장바구니 추가)  →  (결제)
관리자  →  (상품 관리)  →  (재고 확인)
```

{% endstep %}

{% step %}

### 데이터 흐름도(DFD, Data Flow Diagram)

시스템 내에서 데이터가 어떻게 흐르고 처리되는지를 시각적으로 표현하는 다이어그램

```
[사용자] → (로그인 요청) → [사용자 인증 시스템]
[사용자] → (상품 검색) → [상품 데이터베이스]
[사용자] → (주문 요청) → [주문 처리 시스템]
```

{% endstep %}
{% endstepper %}

***

### 요구사항 검증 (Requirement Validation)

* 요구사항 분석이 끝난 후, 요구사항이 올바른지 검토하는 과정이 필요하다.
* 검증 방법

| 방법                               | 설명                       |
| -------------------------------- | ------------------------ |
| 검토(Review)                       | 프로젝트 팀과 함께 문서를 검토        |
| 프로토타이핑(Prototype Testing)        | 간단한 시제품을 만들어 사용자 피드백을 받음 |
| 테스트 케이스 작성(Test Case Generation) | 요구사항이 테스트 가능한지 확인        |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://krjaeh0.gitbook.io/j-log/database/design/requirementanalysisoverview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.