79. 좋은 요구사항의 특징 및 의사소통 유의사항
성공적인 소프트웨어 신상품 개발가이드
1) 좋은 요구사항 문서의 특징
요구사항을 정의한 문서(요구사항 정의서, 요구사항 명세서, PRD(Product Requirement Document), 상품백로그 등)는 상품개발 도중 여러 사람이 참고하기 때문에 같은 의미로 이해하는 것이 중요하다. 상품개발과 관련된 이해관계자들이 요구사항을 정의한 문서를 같은 의미로 이해하고 개발하기 위해서는 다음의 조건을 갖추어야 한다.
- 고객가치가 명확한 요구사항
상품 요구사항 문서는 고객의 어떤 불편을 해결하는지 또는 어떤 혜택을 제공하는지 명확해야 한다. 커스터마이징 프로젝트 요구사항은 고객사 담당자가 정확성을 검증하지만, 신상품개발 요구사항은 상품관리자가 VOC 분석을 통해 검증해야 한다.
- (기한내) 구현이 가능한 요구사항
요구사항의 구현 가능성은 주어진 시간과 비용에 따라 달라진다. 무한대의 시간과 무한대의 비용이 주어진다면 구현 못할 요구사항이란 없다. 따라서 요구사항은 주어진 자원으로 개발기간내에 구현 가능해야 한다.
- 우선순위를 평가할 수 있는 요구사항
제한된 자원을 효율적으로 활용하기 위해서는 상품 요구사항 우선순위를 고려하여 자원을 투입해야 한다. 그러기 위해서는 상품 요구사항의 우선순위 평가가 가능해야 한다. 우선순위 평가가 어려워 대부분의 요구사항에 대해 'must'로 평가해서는 안 된다.
- 추정가능한 요구사항
상품 요구사항의 규모, 개발기간, 투입공수를 추정할 수 있어야 한다.
- 적정한 크기의 요구사항
너무 큰 요구사항은 추정이 힘들고 너무 작게 분할하면 관리비용이 증가할 수 있다. 적정한 크기는 개발팀의 역량, 사용기술에 따라 달라진다.
- 상호독립적인 요구사항
요구사항 간에 의존성이 있으면 공통기능이 있을 수 있고 그 결과 중복개발의 위험이 있다. 공통기능은 하나의 요구사항 규모 추정에만 반영하고 나머지 요구사항에서는 다른 요구사항의 기능을 활용하는 것으로 해야 한다. 또한 의존적인 요구사항은 우선순위 부여시 유의해야 한다.
- 테스트를 할 수 있는 요구사항
사람들의 판단을 흐리게 할 수 있는 형용사를 사용하면 테스트가 힘들고 종료기준이 불명확해진다. ‘사용하기 편리한’ ‘최대한’ ‘단순한’ 등과 같은 단어는 사용하지 않거나 측정 가능한 기준을 정하는 것이 좋다. 예를 들어 ‘사용자는 조회한 상품을 쉽게 주문할 수 있어야 한다’는 요구사항 대신 ‘사용자는 조회한 상품을 3초 내에 주문 완료할 수 있어야 한다’는 식으로 정의해야 한다.
- CX 및 UX를 포함한 요구사항
상세 화면 디자인은 개발을 진행하면서 결정하지만 상위수준의 고객경험, 고객 인터페이스는 상품기획 시 정의한다. 상품요구사항과 CX를 별개로 구분해서는 안 된다.
- 추적 가능한 요구사항
요구사항이 최종 상품에 정확하게 반영되었는지 확인할 수 있어야 한다.
위에서 언급한 모든 조건을 충족하는 요구사항 정의는 힘들며 상품개발 과정에서 지속적으로 업데이트 해야 한다. 예를 들어 고객가치가 명확하다면 상품개발을 진행하면서 요구사항을 상세화 할 수도 있다.
2) 상품 요구사항을 문서로 의사소통 할 때 유의사항
상품 요구사항은 문서를 기본으로 하고 와이어 프레임, 화이트보드, 그림 등을 추가로 활용할 수 있다. 상품 요구사항을 문서로 정리하는 과정에서 상품관리자의 생각을 논리적으로 정립한다.
상품 요구사항 문서를 활용하여 의사소통 할 때 유의할 사항은 다음과 같다.
- 명확한 만큼 상세화 한다.
요구사항을 문서로 잘 정의하는 것은 어렵다. 그러나 잘 정의할 수 있다면 요구사항을 상세하게 정의하는 것이 바람직하다. 상세하지만 부정확하거나 불확실한 요구사항 정의는 유의해야 한다.
- 문서화 이전에 반드시 요구사항에 대한 설명과 토의시간을 가진다..
문서 또는 토의만으로는 요구사항 이해에 한계가 있다. 요구사항 토의시 논의했던 이슈를 보완한 요구사항 문서를 공유하면 요구사항을 보다 정확하게 이해할 수 있다.
- 상품요구사항 문서는 법이 아니다.
요구사항 문서를 배포한 뒤에 요구사항 문서가 반드시 지켜야 할 법처럼 되는 것을 경계해야 한다. 요구사항 대로만 개발하면 잘하는 것이고 요구사항대로 하지 않으면 잘못이라는 분위기가 형성되면 안 된다. 이런 경우 고객가치라는 본질은 사라지고 문서로 출력된 내용이 중요해진다. 요구사항 문서가 기업과 기업 간의 계약문서가 아니고 내부 협의를 위한 문서라면 언제든지 고객가치 본질에 대한 질문을 할 수 있어야 한다. 상품개발팀에서 임의로 요구사항을 해석해서는 안되지만 다른 대안이 있는 경우 언제든지 문제를 제기하고 토론할 수 있어야 한다.
- 요구사항 문서는 싑고 명확하게 정의한다.
요구사항은 일반 사용자가 보아도 쉽게 알 수 있도록 쉬운 단어로 기술해야 한다. 상품의 우수함을 설명하기 위해 컨셉 수준에서 형용사를 사용할 수 있지만 요구사항 문서에서 형용사 사용은 부작용만 있다. 사고의 복잡성(깊이)과 표현의 복잡성을 착각해서는 안된다. 생각이 깊을수록 요구사항의 표현은 간단해진다.요구사항을 정의할 때 유의해야 할 모호한 표현과 대응방안은 아래 표와 같다
출처 칼 윌거스 2003https://brunch.co.kr/@kbhpmp/160
