응답.

문제의 역사:

IT 프로젝트의 규모와 복잡성이 증가함에 따라 비즈니스 고객이 요구 사항을 추상적인 희망 사항으로 전달하여 개발 팀에 전달될 때 완전히 다른 것으로 변환되는 상황이 반복적으로 발생했습니다. 이는 비즈니스와 IT 간의 용어, 기대 및 추상화 수준의 격차 때문입니다.

문제:

분해 단계를 잘 계획하지 않으면 요구 사항이 불완전해질 수 있습니다(중요한 세부 사항이 누락됨), 지나치게 모호해질 수 있습니다(평가 및 구현할 수 없음) 또는 어휘적 함정, 고려되지 않은 용어 및 해석 차이 때문에 왜곡될 수 있습니다.

해결책:

시스템 분석가는 각 요구 사항을 체계적으로 분해합니다: 비즈니스 용어를 형식화하고, 비즈니스 목표를 기능 및 작업으로 변환하며, 사용자 시나리오 및 시스템 동작을 설명하고, 수용 기준/테스트 케이스에 연결합니다. 모델(UML, BPMN), 용어집, 체크리스트 및 팀 간 직접 리뷰를 사용하는 것이 중요합니다.

주요 특징:

• 고객과 함께 용어집 구축
• 다이어그램 및 원자적 요구 사항 формулировка 사용
• 요구 사항을 수용 기준 및 테스트 케이스 언어로 변환

덫이 있는 질문들.

비즈니스 희망 사항을 자유 형식으로 남겨두고 개발 단계에서 추가 작업을 할 수 있습니까?

아니요, 오해와 구현 오류의 위험이 높습니다.

분석 단계에서 구현 세부 사항(예: 데이터 저장 방법)을 명확하게 해야 합니까?

아니요, 분석은 "무엇"과 "왜"에 관한 것이고, "어떻게"에 관한 것이 아닙니다. 기술적 세부 사항은 아키텍처 및 개발의 책임입니다.

항상 하나의 요구 사항 = 하나의 모듈/기능입니까?

아니요, 종종 분해가 필요하며, 큰 요구 사항이 서브 기능 및 개별 수용 기준을 가진 사용자 스토리로 나누어집니다.

전형적인 오류 및 안티 패턴

• 용어집 없이 비즈니스 언어와 기술 용어 혼합
• "모호한 희망" 형태로 요구 사항 설명
• 원자성을 위반하는 것 — 하나의 요구 사항이 여러 개의 다양한 엔티티를 포함함

실제 사례

부정적인 사례: 고객이 "사용자는 모든 판매 분석을 볼 수 있어야 한다"라는 희망 사항 목록을 전달했고, 기술 문서에 수정 없이 복사되었습니다.

장점:

• 문서 준비 속도

단점:

• 어떤 지표가 필요하고 어떤 관점에서 필요한지 불명확함
• 지속적인 추가 작업

긍정적인 사례: 분석가가 고객에게 질문하여 필요한 지표 목록을 작성하고, 사용자 역할을 정의하고, 보고서 프로토타입을 개발하고, 용어집을 합의했습니다.

장점:

• 개발 및 테스트에 대한 투명한 기준
• 추가 작업 최소화

단점:

• 더 많은 시간이 소요되며 분석 단계에서 고객의 참여가 필요함