# Requirements Generator

> 제품 소개 문서(PDF, 마크다운, 슬라이드 요약 등)를 분석하여 소프트웨어 요구사항 정의서와 제약사항 문서를 자동 생성한다. 사용자가 "요구사항 만들어줘", "제약사항 작성해줘", "requirements 문서 생성", "constraints 문서 생성" 등을 요청하거나, 제품 Brief/소개 문서를 기반으로 요구사항이나 제약사항을 도출해달라고 할 때 이 스킬을 사용한다. 기능정의서, 제품 소개서, 워크숍 슬라이드 요약 등 어떤 형태의 소스 문서든 분석 가능하다.

- Skill: `aws-samples/requirements-generator` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aws-samples/requirements-generator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aws-samples/requirements-generator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: aws-samples (https://skillmd.com/u/aws-samples)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aws-samples/requirements-generator

---


# Requirements & Constraints Generator

제품/서비스 소개 문서를 분석하여 구조화된 요구사항 정의서와 제약사항 문서를 생성하는 스킬.

## 핵심 원칙

소스 문서에 명시된 정보만으로 요구사항과 제약사항을 도출한다. 추측이나 억지로 채우지 않는다. 소스 문서에서 확인할 수 없는 항목은 반드시 **"정보 부족"**으로 표시하고, 문서 말미에 정보 부족 항목 요약 테이블을 제공한다.

## 워크플로우

### 1단계: 소스 문서 분석

사용자가 지정한 소스 문서(PDF, 마크다운, 이미지 등)를 읽고 다음을 추출한다:

- 제품/서비스명, 핵심 가치, 목적
- 시스템 아키텍처, 모듈 구성
- 기능 목록 및 상세
- 사용자 유형
- 기술 스택, 외부 연동
- 비용/일정/리소스 정보
- 도메인 고유 구조 (레벨, 카테고리 등)

### 2단계: 문서 생성

사용자 요청에 따라 요구사항, 제약사항, 또는 둘 다 생성한다.

**요구사항 정의서** 생성 시 `references/requirements_template.md`를 읽고 그 구조를 따른다.

**제약사항 문서** 생성 시 `references/constraints_template.md`를 읽고 그 구조를 따른다.

### 3단계: 정보 부족 항목 정리

문서 말미에 정보 부족 항목 요약 테이블을 추가한다:

```markdown
> **정보 부족 항목 요약**
>
> | 항목 | 부족 내용 |
> |------|----------|
> | {항목} | {어떤 정보가 부족한지} |
```

## 요구사항 정의서 작성 가이드

`references/requirements_template.md`를 읽어 전체 구조를 확인한다. 핵심 규칙:

### ID 네이밍

- 기능 요구사항: `FR-{영역약어}-{순번 3자리}` (예: FR-CON-001, FR-MON-002)
- 비기능 요구사항: `NFR-{순번 3자리}`
- 이력 저장: `FR-HIST-{순번 3자리}`

### 우선순위 판단

소스 문서에서 명시적으로 확인 가능한 핵심 기능은 **Must**, 부가/확장 기능은 **Should**, 선택적 기능은 **Could**로 분류한다. 판단 근거가 불명확하면 Must로 기본 설정하되 근거 컬럼에 "우선순위 확인 필요"를 표기한다.

### 기능 영역 도출

소스 문서의 모듈/기능 구조를 그대로 반영하여 영역을 나눈다. 소스 문서에 없는 영역을 임의로 만들지 않는다.

### 비기능 요구사항

소스 문서에서 성능 수치, 보안 요건, 호환성, 비용 기준 등이 언급되면 비기능 요구사항으로 도출한다. 구체적 수치가 없으면 "정보 부족"으로 표기한다.

### 추적 매트릭스

문서 말미에 영역별 요구사항 개수를 Must/Should/Could로 집계한다.

## 제약사항 문서 작성 가이드

`references/constraints_template.md`를 읽어 전체 구조를 확인한다. 핵심 규칙:

### ID 네이밍

| 카테고리 | 접두사 |
|---------|--------|
| 플랫폼/디바이스 | PC |
| 기술적 제약 | TC |
| 비즈니스 제약 | BC |
| 콘텐츠 제약 | CC |
| 운영 제약 | OC |
| 법적/규제 제약 | LC |
| 일정/리소스 제약 | SC |
| 데이터/연동 제약 | DC |
| 미확정 사항 | PD |
| 가정사항 | AS |

### 제약사항 도출 관점

소스 문서에서 다음을 찾아 제약사항으로 도출한다:

- **플랫폼**: 대상 플랫폼, OS, 디바이스, 프로토콜 고정
- **기술적**: 데이터 저장 방식, API 제한, 외부 의존성, 보안 요건
- **비즈니스**: 도메인 구조 고정, 비용 기준, 기능 범위 제한
- **콘텐츠**: 데이터 포맷, 소스/대상 제한
- **운영**: 모니터링, 교육, 설정 관리
- **법적**: 암호화, 데이터 보관/삭제, 규정 준수
- **일정**: 구축 기간, 인력, 마일스톤
- **데이터/연동**: 외부 시스템 연동, 키 구조, 정합성

### 미확정 사항 (PD)

소스 문서에서 상세 스펙이 없는 항목을 미확정 사항으로 도출한다. 담당 팀과 영향 범위를 추정하여 기재한다.

### 가정사항 (AS)

시스템이 정상 동작하기 위한 전제 조건을 도출한다. 검증 기준과 미충족 시 영향을 함께 기재한다.

### 요약 매트릭스

문서 말미에 카테고리별 제약사항 개수를 집계한다.

## 출력 파일

- 요구사항: `{프로젝트약어}_requirements.md`
- 제약사항: `{프로젝트약어}_constraints.md`
- 저장 위치는 사용자가 지정한 경로를 따른다. 미지정 시 현재 디렉토리에 저장한다.

## 언어

소스 문서의 언어를 따른다. 기술 용어(ID, API, DynamoDB 등)는 영문 그대로 사용한다.

