78. 상품 요구사항 정의의 어려움
성공적인 소프트웨어 신상품 개발가이드
상품요구사항 문서는 상품기획의 끝인 동시에 상품개발의 시작이다. 상품 요구사항 문서는 많은 이해관계자가 참조하는 중요한 문서이다. 이번 섹션에서는 상품 요구사항을 명확하게 정의하기 힘든 이유, 좋은 요구사항 문서가 갖추어야 할 조건, 문서로 요구사항을 의사소통 할 때 유의할 사항을 설명한다.
1) 상품 요구사항을 정의하기 힘든 이유
요구사항 관점에서 신상품 개발은 상품 요구사항을 정의하고, 구체화하고, 개발하고, 검증하고, 변경하는 과정이다. 상품 요구사항 정의는 요구사항 관리의 첫 번째 단추이다. 첫 번째 단추인 상품 요구사항을 정의하기 힘든 이유는 다음과 같다.
- 상품 요구사항은 지속적으로 상세화 된다.상품관리자가 정의하는 상품 요구사항의 상세화 수준은 예를 들어 3 레벨로 구분할 수 있다. 3 레벨은 개념적인 구분이며 실제로는 4 ~ 6 레벨의 요구사항이 있을 수 있다. 애자일 방법론에서 사용하는 용어를 적용하면 1 레벨은 최상위 상품 요구사항으로 주로 로드맵에 반영하는 수준이다. 2 레벨은 1 레벨의 상품 요구사항을 분할한 것으로 ‘에픽’ 또는 ‘테마’라고 한다. 에픽은 상세화 하지 않은 상품요구사항이며, 테마는 상세화된 요구사항을 그룹핑한 것이다. 마지막 레벨은 ‘사용자 스토리’라고 한다. 피처(feature)는 상품 요구사항의 특정 레벨을 설명하는 것이 아닌, 개발하기로 결정한 상품 요구사항을 설명하는 개념인데 조직에 따라 다른 의미로 사용하기도 한다. 조직에 따라 명칭은 다를 수 있지만 상품 요구사항 레벨을 구분하는 용어가 있어야 한다. 왜냐하면 현 상품 요구사항이 어느 정도 상세화한 수준인지를 이해관계자가 알아야 하기 때문이다. 백로그는 ‘개발되지 않은 상품 요구사항 목록’인데 상세화 레벨에 따라 ‘상품 백로그 → 릴리즈 백로그 → 스프린트 백로그’로 구분한다. 상품백로그의 예는 아래 표와 같다. 스프린트 백로그는 상품백로그에서 관리하는 정보 외에 담당자, 착수일, 종료일 등을 포함할 수 있다.
<경험과 사례로 풀어낸 성공하는 애자일, 2012>에서는 다음의 사례로 ‘에픽’과 ‘사용자 스토리’를 설명한다.
- 에픽 : 사용자는 본인만 아는 정보를 활용하여 시스템에 로그인해야 한다.
(이하는 위의 에픽을 분할한 사용자 스토리)
√ 등록된 사용자는 사용자명과 패스워드로 로그인할 수 있다.
√ 신규사용자는 사용자명과 패스워드를 등록할 수 있다.
√ 등록된 사용자는 비밀번호를 변경할 수 있다.
√ 신규사용자가 단순한 비밀번호를 등록하고자 하는 경우 경고를 줄 수 있다.
√ 등록된 사용자가 3번 이상 잘못된 비밀번호를 등록하면 알람을 제공한다.
- 요구사항을 문서로 정의하는 것은 한계가 있다.
상품 요구사항을 명확하게 정의하려면 고객은 니즈를 정확하게 말하고, 상품관리자는 정확하게 이해하여 문서화해야 한다. 이 과정에서 의사소통 노이즈가 발생하며 이를 제거하기 쉽지 않다. 요구사항 문서화는 필수적이지만 문자로 표현하는 것은 한계가 있고, 오해하기도 쉽다. 예를 들어 신발 끈 매는 방법을 글로 적는다고 생각해보라. 쉽지 않은 일이다. 또한 문서화된 요구사항도 아래와 같이 오해하기 쉽다. 같은 문장을 다르게 오해할 수 있는 예는 다음과 같다. <애자일 마스터, 2012>
나는 그녀가 돈을 훔쳐갔다고 말하지 않았어요
나는 그녀가 돈을 훔쳐갔다고 말하지 않았어요 (내가 말한 게 아니에요)
나는 그녀가 돈을 훔쳐갔다고 말하지 않았어요 (아마 다른 사람이 훔쳐갔을 걸요)
나는 그녀가 돈을 훔쳐갔다고 말하지 않았어요 (그녀는 돈이 아니라 내 마음을 훔쳐갔어요)
나는 그녀가 돈을 훔쳐갔다고 말하지 않았어요 (훔쳐간 게 아니라 빌려간 거예요)
여러 사람들이 요구사항 정의의 어려움 또는 중요성을 다음과 같이 강조하고 있다.
“우수한 요구사항은 이해하기는 쉽지만 오해하기는 어렵다. “(버쿤, 2006)
“소프트웨어 명세를 모호하게 정의하는 것은 가능하지만 소프트웨어를 모호하게 만드는 것은 불가능하다.” (드마르코, 2004)
“고객이 타고 있는 배에 가까이 가기 위해서는 당신의 배가 움직이는 동안 고객의 배를 계속 주시하여야 한다. 출발 전에 보았던 고객의 배가 그대로 있다고 가정해서는 안 된다.” (케슬러, 2009)
https://brunch.co.kr/@kbhpmp/160
