요구사항은 왜 '문서'가 되는가

한 줄 요약

요구사항 정의는 문서를 만드는 일이 아니라 말을 검증 가능한 문장으로 바꾸는 일이고, 번호를 붙이는 이유는 그 번호가 설계·개발·테스트·검수를 꿰는 실이 되기 때문이다.

현장 첫 장면

프로젝트 착수 2주차. PM 이 당신에게 회의록 뭉치를 던지며 말한다.
"이거 정리해서 요구사항정의서 초안 만들어 주세요. 금요일 검토회의 때 씁니다."

회의록에는 이런 문장이 있다.

> "주문 화면에서 조회가 좀 느리니까 개선했으면 좋겠고, 관리자는 엑셀로도 받아볼 수
> 있으면 좋겠네요. 아, 그리고 요즘 보안 감사 나와서 로그인 이력도 남겨야 합니다."

이 한 문단은 요구사항 세 개다. 그리고 셋 다 지금 상태로는 개발할 수 없다.
"좀 느리니까"는 몇 초를 말하는가? "엑셀로도"는 화면 그대로인가 다른 항목인가?
"로그인 이력"은 성공만인가 실패도인가, 보관 기간은?

요구사항 정의란 말을 검증 가능한 문장으로 바꾸는 일이다.

왜 번호를 붙이는가

SI 프로젝트에서 요구사항에 REQ-014 같은 ID 를 붙이는 이유는 관료주의가 아니다.
이 ID 하나가 이후 모든 문서를 꿰는 실이 되기 때문이다.

REQ-014 (요구사항정의서)  → SCR-032 주문조회 화면 (화면정의서)  → PGM-118 OrderSearchService (프로그램목록)  → TC-207 대량조회 성능 테스트 (단위테스트 시나리오)  → ITC-041 주문-정산 연계 테스트 (통합테스트)  → 검수확인서 항목 14번

이 연결이 끊기면 세 가지 사고가 난다.

1. 개발했는데 아무도 테스트 안 한 기능 — 오픈 후 첫 장애로 발견된다.
2. 테스트는 했는데 요구사항에 없던 기능 — 누가 지시했는지 아무도 모른다.
검수 때 "이건 과업 범위 밖인데 왜 했죠"라는 말을 듣는다.
3. 요구사항에는 있는데 개발이 없는 기능 — 검수 직전에 발견된다. 가장 아프다.

셋 다 막는 도구가 요구사항 추적표(RTM, Requirements Traceability Matrix) 다.
행은 요구사항, 열은 산출물. 빈칸이 곧 리스크다.

좋은 요구사항 문장의 조건

현장에서 통용되는 기준은 대략 이렇다.

• 검증 가능(testable) — "빠르게"가 아니라 "동시 100 사용자에서 3초 이내".

숫자가 없으면 검수 때 고객과 싸운다. 무조건 진다.

• 원자적(atomic) — 한 문장에 하나. "조회하고 엑셀 다운로드한다"는 둘로 쪼갠다.

쪼개야 진척률이 정확해진다. 안 쪼개면 영원히 "90% 완료"다.

• 출처가 있다(source) — 누가 언제 말했는지. 나중에 "그런 말 한 적 없다"가 나온다.

실제로 나온다. 반드시 나온다.

• 우선순위가 있다 — 상/중/하. 일정이 밀리면 '하'부터 다음 차수로 넘긴다.

우선순위 없이 시작한 프로젝트는 막판에 전부 '상'이 된다.

요구사항은 반드시 바뀐다 — 그래서 변경관리를 한다

신입이 가장 많이 하는 오해: "요구사항을 잘 정의하면 안 바뀐다."
안 바뀐다는 프로젝트는 없다. 관리되지 않는 변경이 있을 뿐이다.

변경관리의 최소 형태는 변경 요청 대장 한 장이다.

| 항목 | 왜 필요한가 |
| --- | --- |
| 변경 전 / 변경 후 | 무엇이 달라졌는지 나중에 재구성 가능 |
| 요청자 | 책임 소재. 고객사 현업인지 우리 PL 인지 |
| 영향도 | 연관 화면·프로그램·공수(MD). 이게 협상 카드다 |
| 승인 여부 | 승인 전 개발 착수 = 무상 개발 |

승인 전에 개발하지 마라. 이건 SI 판에서 가장 비싸게 배우는 교훈이다.
"급하니까 일단 해 놓고 문서는 나중에"로 시작한 일은 정산 때 근거가 없다.

과업대비표 — 검수의 최종 무기

공공 프로젝트에서는 과업대비표를 쓴다. 제안요청서(RFP)의 과업 항목과
실제 산출물을 1:1 로 대조한 표다. 검수 회의는 사실상 이 표를 한 줄씩 읽는 자리다.

RTM 을 프로젝트 내내 성실히 갱신했다면 과업대비표는 그걸 다시 정렬한 것에 불과하다.
안 했다면, 검수 2주 전에 전 팀원이 밤을 새며 역추적을 한다. 어느 쪽을 택할지는
프로젝트 첫 달에 결정된다.

이번 모듈에서 할 것

인터뷰 정리본에서 요구사항을 뽑아 번호를 붙이고, 추적표를 만들고,
협력사가 준 추적표에서 빠진 요구사항을 기계적으로 찾아내는 스크립트를 작성한다.
사람 눈으로 대조하지 않는다 — 500 건짜리 추적표는 눈으로 못 본다.