안녕하세요.
플래니지 Harry입니다.
오늘은 웹/앱 프로젝트 진행에서 시작이라고 할 수 있는 요구사항정의서를 설명해볼까 합니다.
제가 알고 있는 지식의 수준과 현재 이 글을 읽고 있는 다른 분들의 지식의 수준이 다를 수 있습니다. 참고해 주세요.
요구사항정의서가 뭔지
프로젝트를 시작하기에 앞서 고객 혹은 내부 프로젝트 진행 시 만들고자 하는 서비스 혹은 기능에 대한 요구 기능들을 정의하는 문서입니다.
요구사항 정의서는 다양한 형태로 제작될 수 있습니다. 프로젝트 비딩에서는 RFP 혹은 프로젝트 제작 문의 시 고객이 정리해 놓은 요구사항 문서 혹은 사업계획서, 기획서등 다 향한 형태로 요구사항들을 확인해 볼 수 있습니다.
고객 혹은 프로젝트에서 필요한 요구사항들을 한데 모아 요구사항에 대한 정의를 나열한것이 요구사항정의서입니다.
요구사항정의서가 필요한 이유는?
모든 프로젝트의 시작은 요구사항, 니즈에서부터 시작합니다.
1. 우리는 어떠한 목표를 가진다.
2. 목표를 위해서 우리는 무엇을 해야 할까?
3. 목표를 이루기 위해선 a, b, c, d... 가 필요하다.
4. a, b, c, d... 는 어떠한 효과를 가진다.
5. 이것을 통해 우리는 원하는 목표를 이루고 좋은 결과를 얻는다.
결론적으로 우리는 어떠한 목표를 이루기 위해 요구사항들을 정의하는데,
"목표를 위해 우리는 무엇을 해야 할까 -? 목표를 이루기 위해선 ~~ 이 필요하다."가 요구사항정의의 단계라고 생각합니다.
때문에 우리 기획자들은 고객 혹은 프로젝트에 필요한 기능과 요구조건이 무엇인지 정확하게 파악하고 분석할 필요가 있습니다.
왜냐하면 고객이 이루고자 하는바 또는 내부 프로젝트에서 목표로 하는 성과, 우리는 이것을 니즈라고 합니다.
기획자는 니즈를 파악하고 니즈를 해소해 줄 수 있는 해결책을 제시하고 계획해야 하는 역할을 가지고 있습니다.
이러한 니즈를 통해 우리는 기획을 진행하고 목표를 위한 발걸음을 떼기 시작하는겁니다.
요구사항정의서 어떻게 작성해?
요구사항정의서는 말 그대로 요구사항에 대한 내용을 사실에 기반하여 작성되어야 합니다.
요구사항의 내용과 의미가 달라질 수 있으므로 정확한 내용과 의미 전달이 최우선 되어야 합니다.
만일 초반에 얘기된 요구사항 내용과 달라질 경우 고객의 요구 혹은 프로젝트의 목표 설정이 달라지게되어 결국 잘못된 기획을 하는 대형사고가 발생될 수 있습니다.
요구사항 정의서 필수 항목
구분, 요구사항 ID, 요구사항명, 요구사항 상해내용, 요청자, 요청일자, 비고(협의사항)
1. 구분
요구사항이 적용되는 범위를 구분합니다.
예를 들어 플로젝트 개발이 필요한 작업 범위가 사용자(웹사이트)/관리자/파트너 관리자가 있다고 할 때 각 구분값을 통해
요구사항을 미리 나눠놓는 역할을 합니다.
예시) 웹, 앱, 관리자, 파트너 등 최상위 카테고리로 구분값을 나눔
2. 요구사항 ID
많은 요구사항들을 요구사항명으로 구분하고 찾아서 관리하기엔 시간이 너무 요소 됩니다.
우리는 각 요구사항별로 관리를 용이하기 위해서 ID를 부여합니다.
때문에 많은 요구사항 중 커뮤니케이션이 필요한 요구사항의 ID를 통해 빠르게 찾아서 내용을 확인한 뒤 커뮤니케이션을 통해 협의할 필요가 있습니다. 또한 해당 요구사항 ID와 기능정의서의 내용이 매칭이되어 조금 더 용이하게 관리하기위한 방법들로 프로젝트를 수행할 수도 있습니다.
ID를 지정하는 방법에는 기획자마다 스타일이 다르지만 통상적으로 사용되는 영어단어의 철자 중 이해하기 쉬운 단어와 숫자를 조합하여 코드화합니다.숫자로 조합하는 경우 각 숫자단위별 카테고리 정리가 필요합니다.
이 부분은 따로 한번 더 정리하는 글을 게시하겠습니다.
예시) AD-01, US-0101, HO_0102
3. 요구사항명
해당 요구사항이 어떤 요구사항인지를 표시하는 영역입니다.
간단하게 얘기해서 글 제목이라고 보시면 될것 같습니다.
누구든지 이 제목을 보고 어떤 요구사항인지 유추할 수 있는 정도로 간단 명료하게 작성되어야 합니다.
이것은 정책이 될 수도, 페이지가 될 수도, 기능이 될 수도 있습니다. 문서 스타일에 따라 일관성 있게 작성되어야합니다작성되어야 합니다.
예시)
(기능 또는 정책) 회원가입, 로그인, 회원정보 수정, 구독서비스, 회원탈퇴
(페이지) 메인페이지, 통계페이지, 주문내역 페이지
4. 요구사항 상세내용
해당 요구사항이 어떠한 내용을 가지고 있는지 상세하게 기재되어야 합니다.
어떤 목적으로 어떻게, 어디에 적용되어야하는지를 작성하는데
보통은"~~~ 기능을적용", "~~~ 이이 필요", "~~~ 이이 되어야함"되어야 함"과같이 정리되는 것이 일반적입니다.
예시)
회원가입은 SNS와 일반로그인으로 구현한다.
SNS 회원가입에는 구글, 애플, 카카오를 적용한다.
주문내역 페이지에 날짜 검색기능 필요
메인페이지에서는 대시보드 기능을 하는 차트가 출력되어야 함
5. 요청자
해당 요구사항을 제시한 요청자(혹은 단체, 부서 등)를 표기합니다.
기획 진행중 요구사항에 대한 내용이 정확하게 확인되지 않아 기능정의가 어려울 경우 담당자와의 추가 커뮤니케이션을 진행 할 수 있고, 요구사항이 중간에 바뀐경우 해당 요구사항을 요청한 최초 시점의 담당자를 확인할 수 있습니다.
RFP를 통해 요구사항을 정리하는 경우 출처를 남겨주시면 좋습니다.
예시) 홍길동, 전략 1팀 홍길동 대리, RFP 00페이지
6. 요청일자
해당 요구사항의 최초 접수일자를 기재해주시면 됩니다. 보통 프로젝트의 요구사항은 프로젝트 초반에 정리되기 때문에 연단위 표시가 생략되는 경우가 있지만, 정확한 날짜 표기를 위해 년/월/일 모두 사용해줍니다.
예시) 2023-01-01, 2023/01/01
- 요청자와 요청일자의 기재 목적은 최초 요구사항의 접수 이후 다른 이슈나 문제로 인해 요구사항이 변경되거나 해소되지 않은 경우
사실관계 확인을 위해 꼭 필요한 부분입니다. - 프로젝트 진행 중 다양한 문제가 발생되는데, 기능이 누락되거나/고객의 요청사항이 바뀌어 작업일정이 늘어나는 경우가
일부 발생됩니다. 이때 정확한 사실관계 확인 후 협의진행하여 프로젝트 흐름이 막히지 않아야 합니다.
7. 비고
해당 요구사항을 위해 참고해야할 부분이 있거나, 협의 또는 문의가 필요한 경우 내용을 남겨놓는 영역입니다.
워낙 많은 케이스의 비고 내용이 존재하기 때문에 상황에 따라 기재해주시면 되겠습니다.
이외 추가 가능 항목
우선순위(중요도), 수용여부, 협의내용, 난이도, 근거(출처)
1. 우선순위(중요도)
요구사항에 대한 우선순위를 분류합니다. 보통 상/중/하로 구분하게됩니다.
예시)
상 : 최우선 처리 요청사항
중 : 중요하지만 최우선 이후 처리 가능 요청사항
하 : 꼭 필요한 사항은 아니지만, 있어도 되고 없어도 되는 요청사항
2. 수용여부
요구사항을 수용할 수 있는지 없는지를 분류합니다.
수용/수용 안 함/철회/보류/재협의등 다양한 카테고리로 나뉘어지지만 [수용/수용안함]으로 구분해야 간단합니다.
요구사항 수용여부는 고객과의 최종 협의를 통해 기재되어야 하며, 협의가 되지 않은 상태로 확정 짓게 되면 프로젝트 진행에 굉장히 위험합니다.
예시)
수용 : 요구사항을 접수하여 처리하기로 함
수용 안 함 : 요구사항을 처리하지 않음
철회 : 협의 도중 예상치 못한 수행사 사정으로 처리할 수 없음
보류 : 기술상/정책상 혹은 내부 문제로 인해 협의 진행이 되지 않음
재협의 : 협의가 진행되지 않아 추가 협의가 필요함
3. 협의내용
요구사항에 대한 협의 내용을 기재합니다.
요구사항에 수용 시 어떤 방법으로 처리할것인가, 수용하지 못할 경우 왜 수용이 안되는지 등 수용 여부에 대한 사유 혹은
협의된 내용을 기재하면 됩니다.
4. 난이도
요구사항들의 구현 난이도를 표시합니다.
우선순위와 동일하게 상/중/하로 구분할 수 있습니다.
구현 난이도에 따라 작업일정 및 투입인력의 경력사항이 달라질 수 있기 때문입니다.
작업 일정과 투입인력의 능력 그리고 투입인력의 수에 따라 난이도가 달라질 수 있습니다.
예시)
상 : 구현 난이도 어려움, 작업일정/인력 많이 투입되어야 함, 상급 개발자/디자이너 필요
중 : 구현 난이도 약간 어려움, 작업일정/투입인력 협의 필요, 중/상급 개발자 디자이너 투입여부 협의
하 : 구현 난이도 일반, 작업일정/투입인력 일반, 초/중급 개발자 투입
5. 근거
요구사항이 발생된 근거를 남겨주시면 됩니다.
요구사항 근거를 남겨주실 때는 출처를 정확하게 남겨야 합니다.
앞서 설명드린 담당자/요청일자와 같은 명목으로 요구사항의 근거를
명확하게 남겨야 후에 분쟁이슈를 줄일 수 있습니다.
이렇게 오늘은 요구사항정의서에 대한 내용을 정리해 봤습니다.
제가 생각하는 요구사항 정의서에서 중요한 건 고객니즈파악, 요구사항 누락 방지, 분쟁 방지 이렇게 3개입니다.
고객의 니즈를 파악해 원하는 시스템, 서비스, 목표를 이룰 수 있도록 기획하고 프로젝트를 진행해야 합니다.
프로젝트 진행중 누락된 요구사항이 없는지 파악하고 관리해야되고, 요구사항이 달라진 경우 혹은 잘못 이해하여 잘못된 방향으로 진행된 경우 빠르게 방향을 수정하고 성공적으로 프로젝트를 진행하는데 있습니다.
경험해 본 프로젝트마다 요구사항정의서를 작성하고 관리하는 방법은 정말 다양했고,
제가 알려드린 방법이 정답이 절대로 아닙니다.
하지만 경험을 통해 최소한 저 정도 수준의 문서가 작성되어야 프로젝트를 진행하는데 어렵지 않다는 걸 알려드립니다.
오늘도 즐거운 기획하시기 바랍니다.
'기획' 카테고리의 다른 글
| 웹기획 업무 조언 (0) | 2023.08.07 |
|---|---|
| [웹기획 필수]기능정의서 작성방법 노하우 공개 (0) | 2023.08.03 |
| 웹/앱 기획자 필수 웹사이트 링크 공유 (1) | 2023.07.25 |
| 내가 보려고 만든 웹/앱 용어 (0) | 2023.07.25 |
| 웹 프로젝트 구축/개발 과정 (0) | 2023.07.24 |