요구사항 관리
요구사항 관리란 제품, 시스템, 프로젝트의 요구사항을 전체 수명 주기에 걸쳐 체계적으로 수집, 문서화, 검증, 우선순위 지정, 추적하는 과정이다.
요구사항 관리는 수집(elicitation)에서 시작한다. 인터뷰, 워크숍, 또는 직접 관찰을 통해 고객, 사용자, 사내 이해관계자가 실제로 무엇을 필요로 하는지 파악한다. 요구사항을 모으고 나면 이를 문서화하고 모순이 없는지 점검한 뒤, 시스템이 반드시 해야 하는 일인 기능 요구사항과 보안, 성능, 사용성 같은 비기능 요구사항으로 나눈다. 그다음에야 우선순위 지정이 이루어지는데, 흔히 요구사항을 필수(must-have), 있으면 좋음(should-have), 있어도 됨(could-have), 하지 않음(won't-have)으로 분류하는 MoSCoW 기법을 사용한다.
문서화에는 보통 고객이 달성하고자 하는 바를 담은 요구사항 명세서(Lastenheft)와, 제공자가 이를 어떻게 구현할지 설명하는 대응 사양서(Pflichtenheft)가 포함된다. 요구사항 추적 매트릭스는 개별 요구사항 하나하나를 출처, 상태, 그리고 이후 충족 여부를 확인하는 테스트 케이스와 연결한다. 애자일 프로젝트에서는 흔히 제품 백로그가 이 역할을 대신하며, 요구사항은 사용자 스토리 형태로 기록되어 스프린트마다 다듬어지고 구현된다.
프로젝트 도중 요구사항이 바뀌면 제대로 된 변경 관리 프로세스가 작동해야 한다. 모든 변경은 평가되고, 비용과 일정에 견주어 검토된 뒤, 공식 승인을 거쳐야만 반영된다. 이 단계를 건너뛰면 예산이나 일정 조정 없이 납품 범위가 서서히 늘어나는 스코프 크리프(scope creep)가 발생한다. 탄탄한 요구사항 관리야말로 현실적인 견적, 명확한 책임 소재, 검증 가능한 결과를 애초에 가능하게 만드는 토대다.
실용 예시
포장 기계를 제작하는 중견기업이 새로운 주문 처리 소프트웨어를 계획하고 있다. 요구사항 관리의 일환으로 프로젝트 팀은 영업, 생산, 출하 부서의 직원 12명을 인터뷰해 개별 요구사항 84건을 수집한다. MoSCoW 방식으로 우선순위를 매긴 뒤 1차 릴리스에는 31건의 필수 요구사항이 남았고, 이는 18쪽 분량의 요구사항 문서에 담긴다. 구현 도중 청구서 관련 요구사항 하나가 바뀌자 변경 관리 절차가 이를 추적 매트릭스에 기록해, 관련자 모두가 원래 요구사항까지 거슬러 추적할 수 있게 한다.
Leanshift의 도움 방식
요구사항 관리와 Kaizen은 같은 태도를 바탕에 둔다. 무언가를 개선하기 전에 실제로 무엇이 필요한지 정확히 이해해야 한다는 것이다. 요구사항을 꼼꼼히 수집하고 일관되게 추적하면 개선 작업이 증상이 아니라 진짜 목표를 겨냥하게 된다. 이 명확함 자체가 하나의 프로세스 작업이며, 정말 중요한 것이 무엇인지 드러내고 다른 사람들이 계속 개선해 나갈 수 있는 탄탄한 토대를 마련해 준다.
자주 묻는 질문
요구사항 관리와 Lastenheft 같은 요구사항 명세서는 어떻게 다른가?
요구사항 관리는 지속적인 프로세스이고, 요구사항 명세서(Lastenheft) 같은 문서는 그 산출물 중 하나일 뿐이다. 명세서는 고객이 달성하고자 하는 바를 담고, 이에 대응하는 사양서(Pflichtenheft)는 제공자가 이를 어떻게 구현할지 설명한다.
프로젝트에서 요구사항 관리는 언제 시작해야 하는가?
이상적으로는 프로젝트 자체가 시작되기 전, 컨셉이나 제안 단계에서 시작해야 한다. 구현이 이미 시작된 후에 요구사항을 정리하면 값비싼 재작업과 스코프 크리프로 이어질 위험이 있다.
Scrum 같은 애자일 프로젝트에서는 요구사항 관리가 어떻게 이루어지는가?
일회성 문서가 아니라 제품 백로그를 통해 반복적으로 진행된다. 요구사항은 사용자 스토리 형태로 기록되고, 지속적으로 우선순위가 매겨지며, 스프린트마다 다듬어지고 구현된다.