CMMI

Capability Maturity Model Integration, 능력 성숙도 모델 통합
Carnegie Mellon University 연구진이 개발
미국 국방성(DoD)에서 소프트웨어 외주 업체를 선정할 때 "이 회사가 믿고 맡길 만한 프로세스를 갖췄나?"를 평가하기 위해 만든 기준

https://ko.wikipedia.org/wiki/능력_성숙도_통합_모델
https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

성숙도	단계	약약어	주요 문서	추가되는 핵심 의미
Level 2 (Managed)	프로젝트 관리	SPP, SRS, SCMP, SQAP	프로젝트 계획서, 요구사항 명세서, 형상/품질 계획서	"프로젝트별 관리"가 핵심. 개별 프로젝트가 통제되고 있는지 확인
Level 3 (Defined)	공정 표준화	OSSP, SDD, STD, V&V	조직 표준 프로세스, 설계서, 테스트 기술서, 검증/확인 보고서	"조직 차원의 표준"이 핵심. 모든 프로젝트가 공통된 매뉴얼에 따라 수행됨
Level 4 (Quantitatively)	정량적 관리	PPB, PPM	프로세스 성능 베이스라인, 정량적 관리 보고서	"통계적 데이터"가 핵심. 숫자로 프로세스의 안정성을 예측함
Level 5 (Optimizing)	지속적 개선	CAR, DAR	원인 분석 보고서, 의사결정 분석 보고서	"결함 예방과 혁신"이 핵심. 스스로 문제를 찾아 프로세스를 최적화함

CMMI 기반 요구사항 세분화 및 개발 문서 체계

순서	성숙도	약어	영어 풀네임	한국어 명칭	주요 내용 및 포함 단계
1	L2	URS	User Requirement Specification	사용자 요구사항 명세서	고객의 비즈니스 언어로 작성된 요구사항. 개발의 최상위 기준점
2	L3	SyRS	System Requirement Specification	시스템 요구사항 명세서	하드웨어, 소프트웨어, 인력을 포함한 전체 시스템 관점의 요구사항
3	L3	SyDS	System Design Specification	시스템 설계서	시스템 요구사항을 기반으로 한 전체 시스템 구조(Architecture) 설계
4	L2	SRS	Software Requirement Specification	소프트웨어 요구사항 명세서	시스템 요구사항 중 '소프트웨어'가 구현할 기능을 상세 기술(L2 필수)
5	L3	SDD	Software Design Description	소프트웨어 설계서	SRS를 기반으로 한 모듈, 인터페이스, DB 등 소프트웨어 상세 설계
6	L2	SPP	Software Project Plan	프로젝트 계획서	요구사항 규모에 따른 일정, 예산, 인력 계획 (L2 핵심)
7	L2	RTM	Requirements Traceability Matrix	요구사항 추적표	URS → SyRS → SRS → 설계 → 코드 → 테스트 간 연결성 검증
8	L3	STP/STD	Software Test Plan/Description	테스트 계획/기술서	요구사항(SRS)이 제대로 구현되었는지 확인하기 위한 검증 문서
9	L2	SCMP	Software Configuration Mgmt Plan	형상 관리 계획서	위 문서들의 버전 관리 및 변경 통제 절차 (L2 필수)

문서 간 관계와 명칭의 '변종'이 생기는 이유

URS vs SRS: * URS는 "사용자가 무엇을 원하는가?"(What they need)에 집중하며 보통 발주처가 작성하거나 분석 단계 초기에 작성합니다.
SRS는 "개발자가 무엇을 만들 것인가?"(What we build)에 집중하며, CMMI 심사 시 개발팀의 산출물로 가장 먼저 확인하는 문서입니다.
SyRS와 SyDS의 등장 배경:
- 단순 웹 서비스 개발이 아니라, 하드웨어 장비와 소프트웨어가 결합된 임베디드나 대규모 시스템 프로젝트에서는 '시스템(System)' 레벨의 정의가 먼저 필요합니다. 그래서 SyRS(시스템 요구사항)와 SyDS(시스템 설계) 단계가 추가됩니다.
CMMI에서의 의미 (RTM의 중요성):
- CMMI 레벨 2와 3에서 가장 중요하게 보는 것은 RTM(요구사항 추적표)입니다.
- "URS에 있던 고객의 한 마디가 SRS의 어떤 항목이 되었고, 그것이 SDD의 어느 모듈로 설계되어 결국 어떤 테스트 케이스(STD)로 검증되었는가?"를 증명해야 합니다.
- 언급하신 SRS, SyRS 등의 문서는 이 추적성 체인을 구성하는 각각의 '고리' 역할을 합니다.

정리하자면, 규모가 큰 프로젝트일수록 URS → SyRS → SRS 순으로 문서가 세분화되며, CMMI 인증을 위해서는 이들 사이의 연결 고리를 문서화하는 것이 핵심입니다. 편의상 작은 프로젝트에서는 SyRS를 SRS에 통합하여 운영하기도 합니다.

Use Case Diagram
https://brunch.co.kr/@acc9b16b9f0f430/126

TDD, Test Driven Development
https://namu.wiki/w/테스트%20주도%20개발

SDD, Spec Driven Development
https://yozm.wishket.com/magazine/detail/3477/
https://news.hada.io/topic?id=23776

추적성 매트릭스, Traceability Matrix
https://imnow.tistory.com/entry/3-DO178과-추적성-매트릭스Traceability-Matrix

NASA의 Requirements Mapping Matrix
https://nodis3.gsfc.nasa.gov/displayCA.cfm?Internal_ID=N_PR_7150_002A_&page_name=AppendixD

GEMINI 로 초안 작성 후 수정