요구사항의 정의
요구사항 정의와 절차의 개념
요구사항 정의란 프로젝트에서 구현하거나 변경해야 할 기능, 요소, 디자인 등에 대해 공식적으로 기록하고 관리하는 행위를 의미합니다. 이는 단순한 요청 정리가 아니라, 계약 범위 안에서 무엇을 수행할 것인지 명확히 확정하는 절차입니다. 요구사항은 고객사나 의사결정자, 현업 담당자가 발의하고, 수행사에서는 담당 기획자가 이를 접수하여 관리합니다. 인하우스 조직의 경우에는 IT 부서가 해당 역할을 수행하게 됩니다.
요구사항은 “해달라”는 요청을 문서화한 것이지만, 동시에 “이렇게 해결하겠다”는 합의까지 포함하는 관리 문서입니다. 따라서 요구사항 정의서는 요청과 해결 방향을 함께 담는 구조를 갖습니다.
프로젝트 착수와 요구사항 정의서의 위치
프로젝트가 시작되면 착수 단계에서 수행 계획서를 리뷰하고, 이어서 요구사항 수집 단계가 진행됩니다. 이 과정에서 기획자는 요구사항 정의서를 작성합니다. 요구사항 정의서는 설계 이전 단계에서 프로젝트 범위를 구체화하는 역할을 합니다. 클라이언트나 현업에서 발의된 요구사항을 정리한 뒤, 이에 대해 어떻게 해결할 것인지 1차 협의를 진행합니다. 이 협의가 충분히 이루어지지 않으면 설계 단계에서 오해가 발생하고, 설계 기간이 길어질 수 있습니다. 따라서 요구사항에 대해 “이렇게 해결하겠습니다”라는 형태로 합의점을 도출하는 과정이 중요합니다.
다만 요구사항의 수용 여부는 기획자가 결정하지 않습니다. 최종 수용 여부는 PM이 판단하며, 계약 범위에 포함되는 경우에는 수용, 그렇지 않은 경우에는 제외하는 방식으로 관리됩니다. 이 기준은 상대방에게도 명확히 전달되어야 합니다.
요구사항의 구성 요소와 기록 원칙
요구사항 정의서에는 등록일, 발의자, 요구사항 근거, 해결 방법, 수용 여부 등의 정보가 포함됩니다. 특히 중요한 요소는 요구사항의 근거입니다. 요구사항은 반드시 문서화된 근거를 기반으로 등록되어야 합니다.
요구사항의 근거는 RFP, 사업 계획서, 공식 미팅 회의록 등입니다. 예를 들어 미팅 중에 도출된 내용이라면 반드시 회의록에 기록되어야 하며, 그 회의록을 기반으로 요구사항이 등록됩니다. 이메일로 요청이 온 경우에도 회의록을 통해 정리한 뒤 요구사항으로 확정하는 것이 원칙입니다. 단순한 전화 통화나 지나가는 대화는 그대로 요구사항이 될 수 없으며, 반드시 문서로 정리되는 과정을 거쳐야 합니다.
이처럼 요구사항은 문서 근거를 기반으로 등록되어야 하며, 기획자가 접수하더라도 수용 여부는 PM이 판단한다는 점이 명확히 구분되어야 합니다.
요구사항 ID와 추적 관리
요구사항은 고유한 아이디를 부여하여 관리합니다. 예를 들어 전시 상품 관련 요구사항은 PRD 001과 같은 형식으로 관리되며, 이후 PRD 002, PRD 003으로 이어집니다. 주문 결제와 관련된 요구사항은 ORD, 회원 관련 요구사항은 MEM과 같은 구분자를 사용합니다.
이처럼 세 글자의 영문 코드와 숫자를 조합하여 고유 값을 생성함으로써, 요구사항을 영역별로 구분하고 필터링할 수 있습니다. 이 요구사항 아이디는 화면 설계서나 정보 구조도에서 해당 영역과 매칭시키는 데 사용됩니다. 즉, 요구사항을 설계 산출물과 연결하여 추적하기 위한 기준값으로 기능합니다. 요구사항을 메뉴나 페이지 단위로 구분해 기입하는 것도 일반적인 방식입니다. 예를 들어 로그인과 회원 가입 관련 요구사항은 각각 구분하여 관리함으로써, 필요한 경우 필터링을 통해 쉽게 확인할 수 있습니다.
요구사항의 범위와 역할 구분
요구사항은 특정 프로젝트에서 변경할 요소, 추가할 기능, 디자인 변경 등 다양한 요청 내용을 포함합니다. 예를 들어 버튼 추가, 기존 기능 확장과 같은 항목이 이에 해당합니다.
기능적 요구사항은 기획자가 정리하고 해결 방향을 제시합니다. 반면 디자인 특화 사항이나 기술 특화 사항은 해당 팀에서 별도로 관리합니다. 예를 들어 브랜딩 관련 로고 변경은 디자인 팀이 관리하며, 클라우드 서버 이전이나 인프라 변경과 같은 기술 사항은 IT 부서가 담당합니다.
이처럼 요구사항은 역할에 따라 관리 주체가 구분되지만, 전체 범위에 대한 통합 관리와 추적 책임은 프로젝트 체계 안에서 유지되어야 합니다.
요구사항 관리가 필요한 이유
요구사항은 계약 범위에 포함된 요소이기 때문에, 최종 검수 단계에서 모든 요구사항이 반영되었는지 확인할 수 있어야 합니다. 요구사항이 제대로 관리되지 않으면, 프로젝트 말미에 “이 부분을 해주기로 하지 않았느냐”는 논란이 발생할 수 있습니다. 따라서 요구사항의 이력을 철저히 남기고, 등록·수정·수용 여부를 명확히 관리하는 것이 중요합니다. 요구사항은 단순 요청 목록이 아니라, 계약 이행 여부를 판단하는 기준이기 때문입니다.
요구사항 관리 단계
요구사항 관리는 크게 두 단계로 이루어집니다.
- 첫 번째 단계에서는 다양한 출처에서 수집된 요구사항을 기획자가 구체적으로 명시합니다. 이때 발의자, 날짜, 출처를 기록하고, PM을 통해 수용 여부를 결정합니다.
- 두 번째 단계에서는 수용된 요구사항에 대해 해결 방법을 제시합니다. 담당 기획자가 해결 방향을 정리하고, 발의자가 이를 수용하면 요구사항은 최종 확정됩니다. 확정된 요구사항만이 설계 단계로 넘어갈 수 있습니다.
해결 방법은 단순 텍스트 설명에 그치지 않고, 필요에 따라 그래픽이나 리서치 리포트를 통해 구체적으로 제시하는 것이 효과적입니다. 예를 들어 샘플을 첨부하여 해결 방식을 시각적으로 설명하면, 상대방의 이해도가 높아집니다. 이렇게 해결 방법까지 합의된 요구사항만이 설계의 기준이 됩니다.
정리
요구사항 정의서는 프로젝트 범위를 명확히 하고, 계약 범위 안에서 무엇을 수행할 것인지 확정하는 핵심 문서입니다. 요구사항은 반드시 문서 근거를 기반으로 등록되어야 하며, 고유 아이디를 통해 설계 산출물과 연결되어 추적 관리됩니다. 수집, 수용 판단, 해결 방법 합의라는 절차를 거쳐 확정된 요구사항만이 설계 단계로 넘어갑니다. 이러한 체계적인 관리가 이루어져야 최종 검수 단계에서 논란 없이 프로젝트를 마무리할 수 있습니다.