답변.

문제의 역사:

기본적으로 IT 프로젝트에서 시스템 분석가는 비즈니스 요구 사항에 주로 집중했으며, 기술적 제약은 전달되거나 무시되어 작동하지 않거나 지나치게 비싼 솔루션을 초래했습니다.

문제:

기술적 제약은 항상 명시되지 않음 – 고객은 이를 알지 못하거나 개발이 고려하지 않으며 결과적으로 인프라 또는 통합 시스템의 기능과 모순됩니다.

해결책:

시스템 분석가는 아키텍트, DevOps, QA, 통합업체와 적극적으로 인터뷰합니다:

• 기술 스택, 비즈니스 및 인프라 종속성을 정의합니다.
• 요구 사항을 아키텍처 원칙과 조율합니다: SLA, 장애 내성, 확장성, 라이센스 또는 보안에 대한 제약.
• 기능 및 비즈니스의 욕구 간의 타협을 기록하고 검증합니다.
• "시나리오 기반 분석" 및 "비기능적 요구 사항" 접근 방식을 적용합니다.

주요 특징:

• 모든 책임자와의 제약 및 종속성 조기 기록.
• 타협 및 암묵적 제약 문서화.
• 회사 아키텍처와 프로젝트 솔루션의 지속적인 검토.

함정 질문.

명시적으로 언급되지 않았다면 암묵적 기술 제약을 무시할 수 있는가?

정답: 아니오. 암묵적 기술 제약(예: 통합 시간 초과, 메시지 크기 제한)은 항상 다루고 기록해야 하며, 비록 명시적으로 언급되지 않았더라도 마찬가지입니다.

분석가는 아키텍처 회의/워크숍에 참여해야 하는가?

정답: 예, 시스템 분석가는 비즈니스와 아키텍트 간의 연결 고리로서 두 쪽 모두에 요구 사항을 전달하고 결정을 기록해야 합니다.

비즈니스 요구 사항만 수집하고 상속된 제약을 분석할 필요가 없는가?

정답: 부족합니다. 상속된 코드, 라이센스, 통합(legacy)은 때때로 명시된 요구 사항보다 더 많은 제약을 요구합니다.

일반적인 오류 및 안티 패턴

• 숨겨진 제약 및 오래된 시스템의 종속성을 과소평가하기.
• "서면이 아닌" 아키텍처 규칙 무시하기.
• 기술적 실행 가능성을 고려하지 않고 비즈니스 부분만 기록하기.

실제 사례

부정적 사례: 분석가는 비즈니스 프로세스를 통한 통합을 기록했으나 인터페이스에서 데이터 전송 속도에 대한 제약을 알지 못했습니다.

장점: 사양의 빠른 구현. 단점: 시스템이 부하를 견디지 못해 비즈니스가 시간과 돈을 잃었습니다.

긍정적 사례: 분석가는 아키텍처 세션에 참여하여 제한 사항(최대 스레드 수 = 100, 통합 10초마다 1회)을 파악하고 비즈니스와 함께 절단 한계를 조율했습니다.

장점: 작업 가능한 솔루션, 안정적인 통합. 단점: 기능성을 타협적으로 줄이고 이를 고객에게 설명해야 했습니다.