# 소프트웨어 요구사항

> 처음부터 배우고, 실무에서 바로 찾아 쓰는 요구사항 안내서

## Docs

- [요구사항 실무 학습서](/): 개념을 순서대로 배우고, 당장 필요한 업무와 도구를 바로 찾는 요구사항 학습 사이트입니다.

## 학습 경로

- [학습 경로](/learn): 요구사항의 기초부터 수강신청 프로젝트 워크숍까지 50개 주제를 7단계로 학습합니다.

### 1단계. 요구사항의 기초

- [1단계. 요구사항의 기초](/learn/foundations): 문제, 목표, 요구 수준과 이해관계자를 구분한다.
- [1장. 소프트웨어는 요구사항에서 시작한다](/learn/foundations/chapter-01): 기능 이름만으로 시작한 프로젝트가 왜 서로 다른 기대와 재작업을 만드는지 살펴보고, 요구사항을 문서가 아닌 공유 지식으로 이해한다.
- [2장. 요구사항이란 무엇인가](/learn/foundations/chapter-02): 요구사항과 목표·정책·설계·시험 조건의 경계를 구분해 문장 모양이 아니라 출처와 결정 책임으로 대상을 판별한다.
- [3장. 요구사항의 종류와 수준](/learn/foundations/chapter-03): 비즈니스부터 시스템·소프트웨어 수준까지 요구의 추상도를 나누고 기능·품질·데이터·인터페이스 책임을 연결한다.
- [4장. 문제를 정의한다](/learn/foundations/chapter-04): 받은 기능 요청을 곧바로 해법으로 확정하지 않고 관찰된 증상, 문제, 원인 가설과 측정 가능한 목표로 되돌린다.
- [5장. 비즈니스와 업무를 이해한다](/learn/foundations/chapter-05): 문제가 실제 업무의 어느 단계와 규칙·데이터·역할·외부 시스템에서 생기는지 현행과 목표 흐름으로 확인한다.
- [6장. 이해관계자를 찾는다](/learn/foundations/chapter-06): 화면을 쓰는 사용자뿐 아니라 정책·운영·감사와 외부 서비스 책임자까지 찾아 결정 권한과 영향을 구분한다.

### 2단계. 발견과 분석

- [2단계. 발견과 분석](/learn/discovery-analysis): 근거를 수집하고 요구 후보를 분석·협상 가능한 상태로 만든다.
- [7장. 요구사항 도출](/learn/discovery-analysis/chapter-07): 어떤 지식을 누구에게 어떤 기법으로 확인할지 정하고 원자료·관찰·해석·요구 후보와 승인 상태를 분리한다.
- [8장. 요구사항 도출 기법](/learn/discovery-analysis/chapter-08): 인터뷰·관찰·워크숍·프로토타이핑 등 도출 기법을 질문과 위험에 맞춰 조합하고 각 기법의 한계를 보완한다.
- [9장. 좋은 질문을 만드는 법](/learn/discovery-analysis/chapter-09): 정상·예외·경계·수량·권한·실패 질문으로 모호한 답변을 분석 가능한 인터뷰 기록과 확인 항목으로 바꾼다.
- [10장. 요구사항 분석](/learn/discovery-analysis/chapter-10): 수집한 후보에서 중복·누락·모순·모호성과 실현 가능성 문제를 찾아 의사결정 가능한 분석 결과로 바꾼다.
- [11장. 범위를 정의한다](/learn/discovery-analysis/chapter-11): 제품·시스템·업무·데이터 경계와 외부 시스템 책임을 정해 범위 확대와 책임 공백을 함께 막는다.
- [12장. 요구사항을 구조화한다](/learn/discovery-analysis/chapter-12): 목표에서 이해관계자·시스템·소프트웨어 요구로 내려가는 계층과 분해·할당·파생 관계를 명시한다.
- [13장. 요구사항의 우선순위를 결정한다](/learn/discovery-analysis/chapter-13): 가치·비용·위험·의존성을 근거로 우선순위를 토론하되 점수와 기법이 권한 있는 결정을 대신하지 않게 한다.
- [14장. 요구사항 충돌과 협상](/learn/discovery-analysis/chapter-14): 충돌하는 이해관계와 제약을 대안·트레이드오프·결정 기록으로 다뤄 합의의 범위와 재검토 조건을 남긴다.

### 3단계. 명세와 모델링

- [3단계. 명세와 모델링](/learn/specification-modeling): 질문에 맞는 표현 형식을 선택하고 서로 모순되지 않게 연결한다.
- [15장. 좋은 요구사항을 작성하는 법](/learn/specification-modeling/chapter-15): 한 문장에 한 의무를 담고 주체·조건·행동·결과를 분명히 해 검토하고 시험할 수 있는 요구사항을 작성한다.
- [16장. 좋은 요구사항의 품질](/learn/specification-modeling/chapter-16): 개별 문장과 요구 집합의 정확성·완전성·일관성·명확성·검증 가능성을 근거와 반례로 점검한다.
- [17장. 자연어 요구사항 명세](/learn/specification-modeling/chapter-17): 자연어 문장 패턴과 금지 요구를 사용해 정상 동작뿐 아니라 해서는 안 되는 결과와 실패 경계를 표현한다.
- [18장. 유스케이스와 시나리오](/learn/specification-modeling/chapter-18): 사용자의 목표를 기본·대안·예외 흐름으로 나누고 액터·사전조건·종료조건이 있는 유스케이스로 정리한다.
- [19장. 사용자 스토리와 백로그](/learn/specification-modeling/chapter-19): 목표와 사용자 가치를 Epic·Feature·Story·Task로 분해하되 백로그 계층이 요구의 근거를 대신하지 않게 한다.
- [20장. 모델로 표현하는 요구사항](/learn/specification-modeling/chapter-20): 컨텍스트·상태·시퀀스·데이터·결정 모델을 목적에 맞게 선택하고 모델 사이의 모순과 미결정 정책을 찾는다.
- [21장. 기능 요구사항](/learn/specification-modeling/chapter-21): 수강신청의 기능을 접수·판정·조회·중복 방지·취소 책임으로 분해하고 사건·상태·규칙과 연결한다.
- [22장. 비기능 요구사항](/learn/specification-modeling/chapter-22): 성능·가용성·신뢰성·보안·사용성 등 품질 기대를 환경·자극·응답·측정치가 있는 시나리오로 바꾼다.
- [23장. 데이터 요구사항](/learn/specification-modeling/chapter-23): 학생·강좌·신청·판정 데이터의 의미와 원천, 품질, 생명주기, 이력, 개인정보와 이관 책임을 정의한다.
- [24장. 인터페이스 요구사항](/learn/specification-modeling/chapter-24): 사용자·API·파일 인터페이스의 데이터 의미와 오류·재시도·중복·시간 제한·복구 책임을 계약으로 정리한다.

### 4단계. 검증과 관리

- [4단계. 검증과 관리](/learn/validation-management): 품질·타당성·식별·추적·변경·상태를 일관되게 관리한다.
- [25장. 요구사항 검증](/learn/validation-management/chapter-25): 요구사항이 잘 작성됐는지 검증하기 위해 리뷰·분석·모델·시험 설계와 결함 기록을 요구 버전에 연결한다.
- [26장. 요구사항 확인](/learn/validation-management/chapter-26): 요구사항이 실제 사용자와 업무 목적에 맞는지 프로토타입·시나리오·사용자 피드백으로 확인한다.
- [27장. 요구사항 식별과 속성](/learn/validation-management/chapter-27): 요구사항을 안정된 ID와 속성·상태·버전으로 관리해 문장이 바뀌어도 의미와 결정 이력을 잃지 않게 한다.
- [28장. 요구사항 추적성](/learn/validation-management/chapter-28): 목표에서 요구·설계·시험으로 내려가고 다시 근거로 올라오는 양방향 추적 관계를 목적별로 구성한다.
- [29장. 요구사항 변경 관리](/learn/validation-management/chapter-29): 변경 요청의 필요성·영향·비용·위험과 대안을 비교하고 근거 없는 승인이나 가상 수치를 만들지 않는다.
- [30장. 요구사항 상태와 생명주기](/learn/validation-management/chapter-30): 요구의 합의 상태, 구현 작업 상태와 검증 결과를 분리하고 상태 전이의 권한·증거·이력을 정의한다.

### 5단계. 전달로 연결

- [5단계. 전달로 연결](/learn/delivery): 의도와 수용 기준을 잃지 않고 개발 산출물로 전환한다.
- [31장. 요구사항에서 기능으로](/learn/delivery/chapter-31): 요구사항을 기능·흐름·화면·API로 전환하면서 일대일 대응을 피하고 각 설계 후보의 기여 범위를 기록한다.
- [32장. 요구사항에서 화면으로](/learn/delivery/chapter-32): 사용자 목표와 상태·정보·행동 요구를 UX 흐름과 화면 후보로 옮기고 접근성과 오류 회복을 함께 검토한다.
- [33장. 요구사항에서 시스템 설계로](/learn/delivery/chapter-33): 기능·품질·데이터·인터페이스 요구를 컴포넌트 책임과 상호작용에 할당하고 설계 근거를 보존한다.
- [34장. 요구사항에서 시험으로](/learn/delivery/chapter-34): 요구와 설계 후보에서 수용 조건과 시험 판정 기준을 만들고 미정 정책을 시험이 몰래 확정하지 않게 한다.

### 6단계. 환경별 적용과 현대적 주제

- [6단계. 환경별 적용과 현대적 주제](/learn/context-future): 하나의 절차를 강요하지 않고 상황별 위험과 증거에 맞춰 방법을 선택한다.
- [35장. 계획 기반 개발의 요구사항](/learn/context-future/chapter-35): 계획 기반 개발에서 단계별 산출물·검토·기준선과 변경 통제를 운영하면서 선행 문서의 한계를 관리한다.
- [36장. 애자일 개발의 요구사항](/learn/context-future/chapter-36): 애자일 개발에서 목표·백로그·정제·수용 조건과 발견 활동을 연결해 요구 근거가 빠른 개발 과정에서 사라지지 않게 한다.
- [37장. 제품 개발의 요구사항](/learn/context-future/chapter-37): 제품 성과와 사용자 문제에서 기회를 찾고 해법 후보·실험·학습 지표를 분리해 기능 생산을 목표로 착각하지 않는다.
- [38장. SI 프로젝트의 요구사항](/learn/context-future/chapter-38): SI·발주 환경에서 계약 범위·인수 기준·변경 절차와 공급자 책임을 명확히 하되 불확실성을 숨기지 않는다.
- [39장. 운영과 유지보수의 요구사항](/learn/context-future/chapter-39): 운영 중 들어오는 장애·문의·정책 변경을 요구사항 지식으로 되돌리고 관측·복구·변경 책임을 지속적으로 관리한다.
- [40장. 요구사항과 UX](/learn/context-future/chapter-40): 사용자 여정의 준비·행동·장벽·회복을 요구 근거와 연결하고 화면 한 장을 넘어 전체 경험을 분석한다.
- [41장. 요구사항과 아키텍처](/learn/context-future/chapter-41): 서비스 블루프린트로 사용자 접점과 전면·후면 업무, 지원 시스템과 실패 복구 책임을 한 흐름에서 본다.
- [42장. 요구사항과 도메인 지식](/learn/context-future/chapter-42): 도메인 용어·규칙·상태·사건과 경계를 모델링해 같은 단어를 서로 다르게 해석하는 문제와 시스템 간 책임 혼합을 줄인다.
- [43장. AI 시대의 요구사항](/learn/context-future/chapter-43): AI가 만든 요구 후보를 출처 대조·인간 검토·승인과 분리하고 환각·편향·개인정보·재현성 위험을 통제한다.

### 7단계. 수강신청 프로젝트 워크숍

- [7단계. 수강신청 프로젝트 워크숍](/learn/workshop): 하나의 수강신청 사례로 발견·분석·명세·설계·추적·변경을 완주한다.
- [44장. 프로젝트 시작](/learn/workshop/chapter-44): 흩어진 수강신청 사례를 프로젝트 브리프와 이해관계자·범위·가정·위험으로 다시 조립해 시작 조건을 만든다.
- [45장. 요구사항 도출](/learn/workshop/chapter-45): 브리프의 질문을 인터뷰·관찰·문서·로그 조사로 실행하고 원자료와 해석·후보·확인 상태를 구분한다.
- [46장. 요구사항 분석](/learn/workshop/chapter-46): 도출 결과의 중복·누락·충돌과 해법 고정을 분석하고 요구 계층·파생 관계·협상 결과로 구조화한다.
- [47장. 요구사항 명세](/learn/workshop/chapter-47): 분석 결과를 검토 가능한 요구사항 명세로 묶고 기능·품질·데이터·인터페이스와 열린 결함을 함께 제시한다.
- [48장. 설계로 전환](/learn/workshop/chapter-48): 명세 후보를 설계 탐색 입력으로 사용해 기능·데이터·인터페이스 책임을 할당하되 미정 정책을 확정하지 않는다.
- [49장. 추적 관계 구축](/learn/workshop/chapter-49): 요구·설계·시험·변경 사이의 관계 유형·방향·버전을 기록해 필요성·충족·영향 질문에 답할 추적망을 만든다.
- [50장. 요구사항 변경](/learn/workshop/chapter-50): 새 우선순위 정책 요청을 접수해 영향·대안·승인 조건을 분석하고 보류된 변경과 기존 기준선 후보를 구분한다.

## 실무 가이드

- [실무 가이드](/guides): 현재 하려는 업무에 맞는 최소 실행 순서와 관련 학습 페이지, 도구를 바로 찾습니다.
- [문제와 범위 정의](/guides/problem-scope): 해결책 이름만 제시됐거나, 팀마다 해결할 문제와 책임 범위를 다르게 이해하는 상황에서 사용할 최소 실행 경로입니다.
- [이해관계자 파악과 인터뷰 준비](/guides/stakeholder-interviews): 누구에게 무엇을 확인해야 할지 불분명하거나, 익숙한 사용자의 의견만 반복해서 듣는 상황에서 사용할 최소 실행 경로입니다.
- [요구사항 문장 작성](/guides/writing-requirements): 요구 후보가 모호하거나 해결 방법을 미리 정한 채 작성돼 구현·검토·시험이 엇갈리는 상황에서 사용할 최소 실행 경로입니다.
- [유스케이스·스토리·모델 선택](/guides/choosing-specification): 요구를 유스케이스, 사용자 스토리, 모델 가운데 무엇으로 표현할지 결정해야 하는 상황에서 사용할 최소 실행 경로입니다.
- [요구사항 품질 검토](/guides/quality-review): 요구사항 초안이나 기준선 후보를 구현에 넘기기 전에 표현상의 결함과 실제 필요와의 불일치를 찾아야 하는 상황에서 사용할 최소 실행 경로입니다.
- [우선순위와 충돌 협상](/guides/prioritization-negotiation): 모든 요구가 최우선이거나, 정책·가치·위험·노력 사이의 충돌을 하나의 기준으로 결정하기 어려운 상황에서 사용할 최소 실행 경로입니다.
- [변경 영향과 추적성 관리](/guides/change-traceability): 정책·범위·요구 변경이 들어왔지만 어떤 설계·시험·운영 항목을 다시 봐야 할지 불분명한 상황에서 사용할 최소 실행 경로입니다.
- [설계·시험 전환](/guides/design-test-handoff): 합의된 요구를 기능·화면·아키텍처·시험 작업으로 넘기면서 의도나 수용 기준을 잃기 쉬운 상황에서 사용할 최소 실행 경로입니다.
- [AI 사용 결과 검토](/guides/ai-assisted-review): AI로 요구 후보·요약·검토 의견을 만들었지만 출처와 누락, 근거 없는 확정, 결정 책임을 점검해야 하는 상황에서 사용할 최소 실행 경로입니다.

## 도구함

- [도구함](/toolkit): 용어집, 문장 패턴, 질문 목록, 점검표와 관리 양식을 웹에서 바로 찾아 사용합니다.
- [요구사항 용어사전](/toolkit/glossary): 요구사항을 작성·검토할 때 같은 용어를 같은 뜻으로 사용하도록 핵심 정의와 혼동하기 쉬운 지점을 정리한다.
- [요구사항 문장 패턴](/toolkit/sentence-patterns): 주체·조건·행동·결과가 분명한 요구사항 문장을 작성하고 검토하는 데 쓸 수 있는 패턴과 점검 카드를 제공한다.
- [요구사항 품질 점검표](/toolkit/quality-checklist): 요구사항의 정확성·완전성·일관성·명확성과 검증 가능성을 근거와 함께 살펴보는 실무용 점검표다.
- [인터뷰 질문 목록](/toolkit/interview-questions): 요구사항 인터뷰의 목적과 대상을 준비하고 발언 원문·관찰·해석을 구분해 기록하는 질문과 양식을 제공한다.
- [요구사항 정의서 예제](/toolkit/requirements-specification): 대학 수강신청 사례로 요구사항 정의서의 구성과 항목 수준을 살펴보고 프로젝트에 맞게 조정할 기본 구조를 제공한다.
- [요구사항 관리대장 예제](/toolkit/requirements-register): 요구사항의 ID·버전·상태·근거·책임과 변경 이력을 관리하기 위한 필드 규칙과 대장 예제를 제공한다.
- [요구사항 추적표 예제](/toolkit/traceability-matrix): 목표·요구·설계·시험 사이의 누락과 변경 영향을 확인할 수 있도록 추적 관계와 작성 예제를 정리한다.
- [변경요청서 예제](/toolkit/change-request): 변경 제안의 접수부터 영향 분석·대안·결정·후속 조치까지 한 기록으로 관리하는 변경요청서 예제다.
- [요구사항 리뷰 체크리스트](/toolkit/review-checklist): 요구사항 리뷰의 대상·역할·쟁점·결정·재검토와 종료 조건을 회의 전후로 관리하는 운영 체크리스트다.