비즈니스 분석가는 모든 프로젝트 참여자(고객, 개발자 및 테스터)가 이해할 수 있도록 각 요구 사항에 대해 수용 기준(acceptance criteria)을 형식화해야 합니다. 이를 위해 Gherkin 표기법(Given-When-Then), 체크리스트 및 사용 사례(use cases)와 같은 명세 기술을 적용합니다. 분석가는 요구 사항 문서에 기준을 문서화하고 각 요구 사항에 대해 과제가 제대로 수행되었는지 명확하게 확인할 수 있는 객관적인 조건 세트를 마련해야 합니다.
주요 특징:
추가 수용 기준 없이 사용자 스토리만으로 요구 사항을 설명할 수 있습니까?
아니요, 명확한 수용 기준 없이 사용자 스토리는 너무 추상적이며 다르게 해석될 수 있습니다. 요구 사항이 올바르게 구현되었는지 이해하기 위해 기준이 필요합니다.
수용 기준에 비기능적 요구 사항(예: 성능)을 포함해야 합니까?
네, 비기능적 요구 사항도 기준으로 형식화해야 하며, 그렇지 않으면 놓치거나 불완전하게 구현될 위험이 있습니다.
수용 기준은 비즈니스 분석가만 승인해야 합니까?
아니요, 고객과 가능하면 개발 팀과 기준을 조율하여 오해를 최소화해야 합니다.
부정적인 사례: 비즈니스 분석가는 고객과 수용 기준을 협의하지 않았고, 개발자는 요구 사항을 자신들 마음대로 이해했습니다. 장점: 빠른 개발, 어떤 전화 회의도 프로세스를 지연시키지 않았습니다. 단점: 출시 후 70%의 기능이 실제 기대와 일치하지 않아 갈등이 발생했습니다.
긍정적인 사례: 분석가는 형식적인 수용 기준을 작성하고 이를 양측과 협의한 후 사용자 스토리에 첨부했습니다. 장점: 고객과 팀 간의 이해, 출시 후 버그 최소화. 단점: 시작할 때 조율에 조금 더 시간이 소요되었습니다.