답변.

질문 배경:

비즈니스 프로세스 자동화 초기 단계에서 고객이 중요 비즈니스 규칙을 완전히 이해하지 못하거나 문서화되지 않은 중요한 부분을 놓치는 경우가 종종 있었습니다. 이러한 규칙을 명확하게 기록하지 않으면 논리적 오류, 예측할 수 없는 상황 및 비즈니스와 IT 간의 분쟁이 발생할 수 있습니다.

문제:

숨겨진 또는 암묵적인 비즈니스 규칙은 파악하기 어렵습니다: 이러한 규칙은 경험이 풍부한 직원만 알고 있으며, 종이에만 기록되어 있거나 전혀 문서화되지 않았을 수 있습니다. 이는 버그와 갈등의 위험을 증가시키고 제품의 테스트 및 구현을 복잡하게 만듭니다.

해결책:

시스템 분석가는 다음을 적용합니다:

• 주요 사용자 및 전문가와의 인터뷰
• 사건 및 비정상적인 상황 분석
• 관련 프로세스의 규정, 메시지 아카이브 및 서신 검토
• 케이스 모델링 및 BPMN/UML 다이어그램 생성을 통해 여백을 파악

규칙 수집 후, 분석가는 비즈니스 규칙 템플릿, 의사 결정 매트릭스, 상태 및 조건 다이어그램을 통해 이를 형식화합니다. 요구 사항 변경 시 문서를 지속적으로 업데이트합니다.

주요 특징:

• 발견된 규칙의 유효성을 검증하기 위해 전문가를 적극적으로 참여시킴
• 서술 형식에 템플릿 형식 사용 (예: 의사 결정 표)
• 모든 비즈니스 규칙을 고객과 합의하고 승인

함정 질문.

고객이 시작할 때 말하는 모든 규칙이 포괄적이라고 볼 수 있나요?

아니요, 종종 중요한 정보의 일부가 숨겨져 있거나 자명한 것으로 간주됩니다. 심층 분석 및 추가 작업이 필요합니다.

단지 일부 직원만 아는 규칙은 항상 프로젝트에서 고려해야 하나요?

아니요, 이러한 규칙이 비즈니스 측에서 승인되고 전략적 목표에 반하지 않는 경우에만 그렇습니다. 그렇지 않으면 모순의 원인이 될 수 있습니다.

비즈니스 규칙을 기술 문서에 단순히 문서화하는 것으로 충분한가요?

아니요, 전문가와 함께 검증하고, 예외를 설명하며, 용어를 합의하고 테스트 문서에 구현해야 합니다.

일반적인 실수 및 안티 패턴

• 놓치거나 잘못 이해한 규칙으로 인해 재작업 발생
• 사용자 시나리오와 관련 없이 비즈니스 규칙을 지나치게 기술적으로 설명
• 비즈니스 고객 측에서 문서 승인이 없는 경우

실제 사례

부정적 사례: 분석가는 고객의 입에서 비즈니스 규칙을 확인한 후 검증 질문과 피드백 없이 문서화했습니다. 운영 중에는 고려되지 않은 예외(예: 특별한 결제 방식)에 부딪혔습니다. 장점:

• 빠른 분석 문서 준비 단점:
• 많은 버그, 긴급 수정

긍정적 사례: 분석가는 전문 사용자와 세션을 진행하고 모든 케이스에 대한 의사 결정 표를 사용하여 최종 용어를 여러 이해관계자와 조정했습니다. 장점:

• 시나리오의 완전한 커버
• 구현 시 갈등 최소화 단점:
• 준비 및 조정에 대한 높은 시간 비용