Q5. 요구사항 정의는 어떤 식으로 하나요?

 

지윤 :

선배님… 저 이번에 신규 기능 기획하게 됐는데요,

개발팀으로부터 “일단 요구사항을 정리해 달라”는 말만 들었어요.

근데 막상 책상 앞에 앉으니까, 대체 뭘 어디서부터 써야 할지 전혀 모르겠어요.

요구사항 정의, 어떻게 시작해야 하나요?

선배 :

많이 당황했겠다. 근데 처음엔 누구나 그래, 지윤 님.

요구사항 정리는 생각보다 복잡한 퍼즐이라, 막연하게 시작하면 길을 잃기 딱 좋아.

그래서 나는 항상 이렇게 시작하라고 말해.

“문제부터 정확히 정의하라.”

이 문제를 정의하기 위해서는 다음의 네 가지 단계를 꼭 기억해 둬.

ⓐ 문제를 명확하게 정리하기 - ⓑ 사용 시나리오로 풀어보기 - ⓒ 요구 기능 정리하기 - ⓓ 비즈니스/운영/개발 관점에서 제약 사항을 확인하기

선배 :

먼저 "문제를 명확하게 정리하기"를 설명해 줄게. 문제를 명확하게 정리하기 위해서는

"왜 이 기능을 만들려고 하는가?", "사용자는 지금 어떤 불편을 겪고 있나?", "기존 기능으로는 왜 해결이 안 되나?"와 같은 근본적인 의문을 풀어가는 과정을 거쳐야 해. 예를 들어볼게.

만일 알림 기능과 관련해서 너무 많이 들어온다는 피드백이 접수됐다고 가정해 보자.

이때, 그냥 "알림 설정 화면을 만들자."라고 결론 내기에 앞서서 아래와 같은 형식으로 쪼개보는 거야.

 

질문	예시
누가?	장바구니에 물건을 담아 놓은 고객
언제?	장바구니에 물건을 담아놓은 시점에서 7일 후부터 매일
어떤 문제가?	알림이 하루에 5개 이상 와서 알림을 차단하거나 앱을 삭제 함.
현재 기능의 한계는?	유저가 직접 설정하거나 빈도 설정을 할 수 없음

 

이와 같은 문제의 분해와 재조립 과정을 거쳐서

"사용자 맞춤 알림 빈도 설정 기능"이라는 요구사항이 생기는 거야.

선배 :

두 번째로 "사용 시나리오로 풀어보기"야.

"이 기능이 실제로 언제 어떻게 쓰일까?"와 같은 생각을 글로 써보는 거지.

그러면 생각이 명확해지고 빠진 요구사항도 드러나게 돼.

 

No.	요건 정의
1	고객은 마이페이지 > 알림 설정에서 상품 알림 수신 빈도를 설정할 수 있다.
2	빈도 설정 옵션은 하루 1회, 주 1회, 전체 차단 중 선택할 수 있다.
3	설정한 값은 다음 날부터 적용되며, 설정은 언제든지 변경할 수 있다.

지윤 :

음.. 두 번째 단계는 어디서 들었던 거 같은데..

혹시 "유저.. 스토리.."라고 하는 것과 비슷한 건가요?

선배 :

오... 맞아! 사용 시나리오는 유저스토리라는 이름으로 불리기도 해.

회사마다 불리는 이름은 조금 다를 수 있는데, 여기서는 사용 시나리오로 정의한 거야. 

여기까진 잘 이해한 것 같으니 세 번째 단계인 "요구 기능 정리하기"를 풀어볼게.

 

이 단계에서는 "이제 무엇을 만들 것인가?"를 해결해야 해.

한 마디로 문제도 파악했고, 사용자 시나리오도 그려봤다면 이제 개발자와

디자이너가 실제로 구현할 수 있도록 기능을 구체화해야 하는 거지. 표준화된 양식은 없지만

나는 이렇게 정리하곤 해.

 

항목	내용
기능 명	알림 빈도 설정 기능
주요 동작	알림 수신 주기 선택, 저장, 적용
위치	마이페이지 > 알림 설정
기본값	하루 1회 수신으로 기본값 설정
예외 처리	설정 저장 실패 시 안내 메시지 노출
상태 변화	설정 저장 시 즉시 적용 표시, 단 실제 반영은 익일부터 적용.

 

아, 요구사항은 정리하다 보면 가끔 혼동하는 경우가 있는데, 바로 요구사항과 정책, UI을 혼용하는 거야.

요구사항은 "이 기능이 왜, 어떤 상황에서, 무엇을 해야 하는가?"로 정의되고,

정책은 "이 기능이 어떻게 동작해야 하는가?"로, 마지막으로 UI는 "사용자가 그것을 어떻게 경험해야 하는가?"로 정의되는데, 요구 기능 정리 시 이 세 가지를 분리해서 문서화해 보면 훨씬 명확한 커뮤니케이션을 할 수 있어.

지윤 :

와... 저 선배님 말씀만 듣고 있는데, 요구 사항 정리를 다 한 것 같아요!

빨리 마지막 단계도 말씀해 주세요!

선배 :

막 빨리 해보고 싶지?ㅎㅎㅎ

자, 마지막 단계는 "비즈니스/운영/개발 관점에서 제약 사항 정리"야.

쉽게 풀어보면 이 기능을 개발하거나 운영을 하는 관계자들의 입장에서 생각해 보는 과정을 의미해.

예컨대 이런 거지, 운영팀 관점에선 "이 기능 개발하면 고객 문의는 줄어들까?"

개발팀의 관점에선 "이거 구현하려면 푸시 발송 시스템의 구조를 바꿔야 하지 않나?" 

그리고 마케팅팀 관점에선 "알림 줄이면 전환율 떨어지는 거 아닌가?"

 

이런 부분까지 고려해서 정리하면 기술적으로도 논리적으로도 탄탄한 기획이 만들어져.

지윤 님도 경험해 봐서 알 거야. 어제도 개발자가 "이거 개발하려면 이거 이거 고쳐야 해서 시간 많이 들어가요."

했을 때 어버버거리고 당황했었잖아?ㅎㅎ

지윤 :

앗.. 부끄럽게 그 이야기는 왜..ㅠㅠ

여하튼 선배님의 말씀을 들으니, 요구사항 정리라는 게 단순히 "이런 기능 만들 거예요!"가 아니라 

진짜 왜 필요한지를 정의하고 다각도로 점검하는 과정이라는 걸 깨달았어요.

선배 :

맞아, 요구사항은 그냥 떠오른 아이디어가 아니라,

"필요에 따라 근거한 선택"이 되어야 해. 물론 처음부터 완벽할 필요는 없어.

하지만 문제 정의 > 사용자 상황 > 시나리오 > 제약사항 이 네 단계만 기억해도 흔들리지 않는

기획을 해낼 수 있어. 자, 이제 까먹기 전에 바로 한 번 해보자!

한 줄 정리

요구사항 정리는 "왜, 어떻게, 무엇을"의 순서로 사용자 중심의 문제 정의부터 시작해서

실제 구현 가능한 요구 기능 단위로 구체화하는 것이 핵심입니다.

---

온라인 공간에서 야메군이란 닉네임으로 활동 중인 25년 차 서비스 기획자. 네이버 웹/모바일 기획자 커뮤니티 웹(WWW)을 만드는 사람들에서 운영진으로 활동했으며, 딴지일보를 시작으로 아이러브스쿨, 메가엔터프라이즈, 짱공유닷컴, YES24를 거쳐 IT 원천기술 연구소 Valhalla Lab에서 Pattern recognition과 Machine learning 기반의 Natural language processing 기술의 상업적 이용방법에 대한 연구. 최근 스타트업계로 이직, 반려동물과 온라인 피트니스 분야를 경험했고 자율주행 도메인을 거쳐 현재 SaaS 기반 Monitoring 도메인에서 유일한 기획자로 재직 중. 2016년 7월, 웹/모바일 기획자의 업무능력 향상을 위한 서적 “처음부터 다시 배우는 웹 기획”(정재용, 최준호, 조영수 공저) 출간. 2008년부터 약 15년간 서비스기획자의 성장을 위한 온/오프 강의를 통해 후배 기획자를 양성 중.