요구사항 관리: 요구사항 문서를 쓰고 지키는 법

“이런 걸 만들어 달라고 한 적이 없는데요.” 프로젝트가 끝나갈 무렵 이 말을 들으면 그동안의 노력이 흔들립니다. 흔한 원인 가운데 하나는 처음에 무엇을 만들지 분명히 정하지 못한 데 있습니다. 요구사항 관리는 고객과 이해관계자가 원하는 것을 끌어내 적고, 합의하고, 바뀔 때마다 통제하는 일입니다.

요구사항의 종류

요구사항은 보는 높이에 따라 나누어 적으면 빠뜨리는 것이 줄어듭니다.

비즈니스 요구사항: 왜 이 프로젝트를 하는가. 예: 고객 문의 처리 시간을 줄인다.
이해관계자 요구사항: 누가 무엇을 원하는가. 예: 상담원은 고객 이력을 한 화면에서 보고 싶다.
기능적 요구사항: 시스템이 무엇을 해야 하는가. 예: 고객 번호로 지난 상담 기록을 찾는다.
비기능적 요구사항: 얼마나 잘 해야 하는가. 예: 검색 결과가 2초 안에 나와야 한다.

비기능적 요구사항은 빠뜨리기 쉬운데, 나중에 성능이나 보안 문제로 돌아오기 쉽습니다. PMBOK 6판은 이 밖에 전환, 프로젝트, 품질 요구사항도 따로 나눕니다.

끌어내기: 묻는 방법을 섞는다

요구사항은 고객이 처음부터 정리해 주지 않습니다. 여러 방법을 섞어 끌어냅니다.

인터뷰: 핵심 이해관계자에게 직접 묻습니다.
워크숍: 여러 부서를 모아 함께 정리하고 충돌을 그 자리에서 풉니다.
관찰: 실제로 일하는 모습을 보면 말로 하지 않은 요구가 보입니다.
시제품: 화면 초안을 보여 주면 “이게 아니라 저거”가 빨리 나옵니다.

잘 쓴 요구사항과 추적

요구사항 문서에 적는 문장은 다음 조건을 갖추는 것이 좋습니다. 조건을 갖추지 못한 문장은 시험 단계에서 “이 정도면 된 것인가”를 두고 다툼이 생기기 쉽습니다.

명확함: 한 가지 뜻으로만 읽힙니다. “빠르게”, “편리하게” 같은 말 대신 숫자로 적습니다.
검증 가능함: 만들고 나서 충족했는지 시험할 수 있습니다.
하나씩: 한 문장에 요구 하나만 담습니다.
출처와 우선순위: 누가 요청했는지, 꼭 필요한지 있으면 좋은지 적습니다.

요구사항마다 번호를 붙이고, 그 요구가 어느 설계, 어느 결과물, 어느 시험으로 이어지는지 표로 이어 둡니다. 이것을 요구사항 추적 매트릭스라고 합니다. 이렇게 해 두면 빠뜨린 요구가 없는지, 요구가 바뀌면 어디에 영향이 가는지 바로 알 수 있습니다. 시험 단계에서 “이 요구는 어떤 시험으로 확인했는가”에 답할 근거도 됩니다.

바뀌는 요구를 다루는 법

요구사항은 프로젝트 도중에도 바뀝니다. 바뀌는 것 자체를 막기보다 통제하는 것이 목표입니다. 합의한 요구사항 문서를 기준선으로 삼고, 바꾸자는 요청은 변경요청으로 받아 일정과 비용, 리스크에 주는 영향을 따진 뒤 결정합니다. 결정한 내용은 문서와 추적 매트릭스에 반영합니다.

정리

요구사항 관리는 끌어내고, 적고, 합의하고, 바뀔 때 통제하는 일입니다. 비즈니스부터 비기능까지 높이를 나누어 빠짐없이 모으고, 명확하고 검증 가능한 문장으로 적으세요. 추적 매트릭스로 요구와 결과물을 이어 두면 “그런 걸 요청한 적 없다”는 말을 줄일 수 있습니다.

참고(확인 2026-10-03)

PMI, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 6판, 2017 (범위 관리, 요구사항 추적 매트릭스)