핵심 인사이트 (3줄 요약)
- 본질: 요구사항 공학은 **요구 도출(Elicitation)→분석(Analysis)→명세(Specification)→검증(Validation)→관리(Management)**의 체계적 프로세스로 소프트웨어가 무엇을 해야 하는지를 정의한다.
- 가치: 프로젝트 실패의 60%+가 요구사항 문제(누락·모호·변경)에서 발생하며, 개발 후반 요구 변경 비용은 초기 대비 50~200배이므로 체계적 공학이 필수이다.
- 판단 포인트: 기능 요구사항(FR)과 비기능 요구사항(NFR, 성능·보안·가용성)을 구분하고, 요구사항 추적 매트릭스(RTM)로 전 생명주기 추적해야 한다.
Ⅰ. 개요 및 필요성
도출 → 분석 → 명세(SRS) → 검증 → 관리
↑____________________________| (반복)
- 📢 섹션 요약 비유: 요구사항 공학은 건축의 설계도 작업이다. 설계도 없이 짓기 시작하면 완공 후 벽을 허물어야 한다.
Ⅱ. 아키텍처 및 핵심 원리
| 활동 | 핵심 기법 |
|---|
| 도출 | 인터뷰, 워크숍, 프로토타이핑 |
| 분석 | 우선순위(MoSCoW), 갈등 해결 |
| 명세 | SRS(IEEE 830), 유스케이스 |
| 검증 | 리뷰, 프로토타입 검증 |
| 관리 | RTM(추적 매트릭스), 변경 관리 |
Ⅲ~Ⅴ. 결론
요구사항 공학은 프로젝트 성공의 가장 중요한 첫 단추이며, Agile에서도 User Story·BDD로 지속적으로 수행된다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|
| SRS | 요구사항 명세서 |
| RTM | 요구사항 추적 매트릭스 |
| MoSCoW | 우선순위 분류 |
| User Story | Agile 요구사항 |
| NFR | 비기능 요구사항 (품질 속성) |
📈 관련 키워드 및 발전 흐름도
[비공식 요구 수집 (~1990s)] → [IEEE 830 SRS (1998)]
→ [유스케이스 (UML, 2000s)] → [User Story (Agile, 2005~)]
→ [현재: AI 요구사항 분석 — 자연어→요구사항 자동 분류]
👶 어린이를 위한 3줄 비유 설명
- 요구사항 공학은 설계도예요. 집을 짓기 전에 뭘 만들지 정확히 그려야 해요.
- 설계도 없이 짓으면 다 짓고 나서 벽을 허물어야 해서 돈이 50배 더 들어요.
- "무엇을, 얼마나 빠르게, 얼마나 안전하게" 모두 적어둬야 완벽한 설계도예요!