요구사항 정의와 절차
요구사항 정의서
앞선 내용을 바탕으로 프로젝트가 시작되면, 착수 단계에서 수행 계획서가 리뷰되고, 기획자들은 요구사항 수집 단계에서 요구사항 정의서를 작성한다.
요구 내용
클라이언트나 현업에서 발의된 요구사항을 정리한 것이며, 이를 어떻게 해결할지에 대한 해결 방법을 사전에 1차 협의한다.
- 이 과정이 원활하지 않으면 설계 시간이 길어지고, 오해가 생길 수 있기 때문에, 해당 요구사항에 대해 "이렇게 해결하겠습니다"라는 식으로 합의점을 도출해야 한다.
- 이 요구사항이 수용될지 여부는 PM이 결정하며, 계약 범위에 포함되면 수용, 그렇지 않으면 제외되는 방식이다.
구성 요소
등록일과 요구사항 근거
구현이 1차, 2차로 나누어지는 경우에는 요구사항을 구분하여 관리할 수 있고, 필터링을 통해 잘 확인할 수 있다.
- 등록일은 요구사항이 발의된 날짜이며, 발의자는 요구사항을 제안한 사람이나 팀의 이름을 적는다.
여기서 중요한 부분은 요구사항 근거,
- RFP나 사업 계획서, 혹은 미팅을 통해 나온 경우가 많다.
특히 미팅에서 나온 요구사항은 회의록을 근거로 해야 하며, 그 회의록에 기반하여 요구사항이 등록된다. 근거는 반드시 문서화되어 있어야 한다.
- ex. 클라이언트가 밤 11시에 전화로 "이거 좀 처리해주세요"라고 요청했을 때, 이는 요구사항이 될 수 있지만, 반드시 문서로 정리되어야 함
- "내일 정리해서 다시 보여드리겠습니다"라는 방식으로, 회의록을 근거로 요구사항이 확정됨. 이메일로 요청이 온 경우에도 반드시 미팅을 통해 회의록을 작성한 후 요구사항으로 등록해야 함. 지나가는 대화로 나온 내용은 요구사항이 되지 않는다.
- 요구사항 기록은 근거 문서를 기반으로 해야 하며, 기획자가 요구사항을 접수하더라도 수용 여부는 PM이 결정한다는 점을 상대방에게 명확히 전달해야 한다..
요구사항 ID
요구사항 아이디는 고유 값으로, 전시 상품에서는 주로 PRD라는 아이디를 사용한다.
- 예를 들어, PRD 001은 전시 상품의 첫 번째 요구사항을 의미.
- 마찬가지로 PRD 002, PRD 003 등이 있으며, 회원 CS 관련 요구사항은 mem을, 주문 결제는 ord를 쓴다.
이처럼 세 글자 영문자와 숫자를 조합해 고유 값을 생성하고, 이 요구사항 아이디는 화면 설계서에서 해당 영역에 정보가 들어가거나 정보 구조도에서 요구사항을 추적하는 데 사용된다.
=> 매치 시키는 용도
요구사항
요구사항은 특정 프로젝트에서 변경할 요소나 혹은 기능 디자인 등에 대한 다양한 요구 내용과 해결 방법이 명시되어 있는 문서를 의미한다.
요구사항은 특정 프로젝트에서 변경할 요소나 추가할 기능, 디자인 변경 등에 대한 요청 내용을 기록한 문서. “해줘”
>> 예를 들어, 버튼을 추가해야 한다거나, 기존 기능을 확장해야 한다는 요구사항 등이 있다.
요구사항은 고객사, 의사결정자, 현업 담당자들이 발의하고, 수행사의 담당자가 이를 관리한다.
>> 인하우스의 경우, IT 부서가 이를 관리한다.
요구사항에 대한 기능적 부분은 기획자가 처리하며, 디자인이나 기술적인 부분은 해당 팀에서 별도로 관리한다.
- 예를 들어, 브랜딩 관련된 로고 변경 같은 사항은 기획자가 아닌 해당 팀에서 관리하게 된다.
또한, 클라우드 서버 이전이나 인프라 변경과 같은 기술적인 사항은 IT 부서가 담당한다.
=> 요구사항은 계약 범위에 포함되는 요소이기 때문에, 이를 면밀히 관리하고 추적하여 최종 검수 단계에서 문제가 없도록 해야 한다.
요구사항이 관리되지 않는다면?
요구사항은 계약과 연관성이 깊고, 최종 검수 단계에서 요구사항이 모두 반영되었는지 확인할 수 있어야 한다.
=> 면밀하게 해야 한다.
- 요구사항이 제대로 관리되지 않으면, 나중에 "이거 해주기로 했지 않나요?"라는 식의 논란이 발생할 수 있다.
-> 그러므로 요구사항의 이력을 철저히 남겨두고 관리하는 것이 중요하다.
요구사항 정의서 구성 요소
요구사항 정의서에는 요구사항 아이디, 발의자, 등록 날짜, 해결 방법 등이 기록된다.
- 요구사항 아이디는 독립적인 고유 코드로, 상품 관리나 전시와 관련된 요구사항은 PRD 001, 주문 관련 요구사항은 ORD 001, 회원 관련 요구사항은 MEM 001과 같은 형식으로 관리된다. 이렇게 구분된 요구사항은 필터링을 통해 쉽게 관리할 수 있다
- 요구사항 구분자를 통해 필터링할 수 있도록 메뉴나 페이지 단위로 기입하는 것이 일반적이다.
- 예를 들어, 로그인과 회원 가입 관련 요구사항은 각각 따로 구분하여 관리할 수 있게 된다.
- 요구사항 발의자는 해당 요구사항을 발의한 사람이나 기관명으로 기록하며, 요구 내용은 요구사항 발의자가 발의한 내용에 요약된 정보.
- 해결 방법은 담당 기획자가 요구사항을 어떻게 처리할지에 대한 해석을 적는다.
- 수용 여부는 이제 해당 요구 사항을 PM이 보고 수용할 것인지를 판단한 결과
- 요구사항 발의자는 해당 요구사항을 발의한 인물이나 기관명
- 등록 수정 기간은 이제 회의록이나 RFP처럼 해당 요구 사항이 발생한 근거들을 기입한 것
요구사항 관리 단계
요구사항은 크게 두 단계로 관리된다.
첫 번째 단계에서는 다양한 출처에서 수집된 요구사항을 담당 기획자가 구체적으로 명시한다.
>> 이때 요구사항 발의자, 날짜, 출처를 기록하고, PM을 통해 수용 여부를 결정한다.
두 번째 단계에서는 수용된 요구사항에 대해 해결 방법을 제시하고, 발의자가 이를 수용하면 최종 확정됩된다.
확정된 요구사항만이 설계 단계로 넘어가게 된다.
해결 방법
해결 방법은 텍스트로 작성할 수도 있지만, 그래픽이나 리서치 리포트를 통해 더 구체적으로 제시하는 것이 좋다.
- 예를 들어, 샘플을 첨부하여 "이렇게 해결하겠습니다"라고 보여주면, 상대방이 더 쉽게 이해할 수 있다. 이렇게 해결 방법이 확정되면, 요구사항이 설계 단계로 넘어간다.