답변.

요구 사항 검토, 검증 및 조정은 프로젝트 전반에 걸쳐 지속적인 과정입니다. 시스템 분석가는 요구 사항이 다음을 충족하는지 확인해야 합니다:

• 완전하고 모순이 없음
• 기술적으로 실행 가능하고 비즈니스 논리에 부합함
• 모든 참가자가 명확히 이해할 수 있음

요구 사항 검증 프로세스에는 다음이 포함됩니다:

• 비즈니스와의 공동 검토(워크숍, 데모, 인터뷰)
• 아키텍트 및 개발 팀과 요구 사항 조정
• 요구 사항을 작업, 테스트 및 릴리스로 추적(traceability)
• 수용 기준(acceptance criteria), 테스트 사례(test case) 사용
• 공식적인 확인 받기(서명, 댓글, "승인됨" 상태)

요구 사항은 제품 생애 주기의 모든 단계에서 명확해지거나 보완될 수 있으며, 이러한 요구 사항의 актуальность를 유지하고 변경 시 수정하는 것이 중요합니다.

트릭 질문들.

조정 후 요구 사항은 변경되어서는 안 됩니까?

그것은 잘못된 것입니다. 비즈니스 목표 또는 기술적 조건의 변화는 요구 사항의 지속적인 업데이트를 필요로 할 수 있습니다.

요구 사항의 검증이 비즈니스 측면에서만 충분합니까?

아닙니다. 기술적 관점에서도 요구 사항의 실행 가능성과 아키텍처 제약 조건에 대한 조정이 중요합니다.

수용 기준(acceptance criteria)은 오직 사용자 스토리에만 적용됩니까?

아닙니다. 수용 기준은 구현의 정확성을 검증하기 위해 모든 종류의 요구 사항에 적용됩니다.

일반적인 오류 및 안티 패턴

• 공식적인 수용 기준의 부재("문제가 없는 경우 작동함")
• 요구 사항 작성 시 개발 팀의 피드백 무시
• 구현된 요구 사항에 대한 피드백 부족(회고, 데모)

사례

부정적 사례: 분석가는 요구 사항을 비즈니스에만 조정하고 개발자와 논의하지 않았습니다. 최종 구현에서 심각한 기술적 어려움이 발생했으며, 일부 요구 사항은 불가능한 것으로 나타났습니다. 장점: 논의 시간 단축 — 단점: 많은 재작업, 시간 손실, 프로젝트 지연.

긍정적 사례: 요구 사항이 비즈니스와 기술 팀 모두의 검토를 거치고 모든 의견이 문서화되며, 수용 기준이 설정되고, 데모에서 모든 당사자가 요구 사항을 수용합니다. 장점: 오해 최소화, 실행 가능성에 대한 신뢰 — 단점: 준비 및 조정에 더 많은 시간 소요.