예비 프로젝트 단계에서 비즈니스 분석가는 예산, 기간, 자원, 규제 요구 사항, 기술 호환성, 회사 내부 정책 또는 시장 외부 조건과 관련된 주요 비즈니스 제약을 식별합니다. 분석가는 이러한 제약의 영향을 요구 사항 및 가능한 우회 옵션에 세밀하게 문서화합니다.
이를 기록하기 위해 요구 사항 사양의 특정 섹션을 사용합니다. 예:
**제약 사항:** - 최대 예산 — 500만 루블 - 2024년 9월 1일까지 출시 - 시스템은 기존 인프라(리눅스 서버)에서만 작동
주요 특징:
제약 사항은 비즈니스 요구 사항의 일부입니까?
아니요, 제약 사항은 요구 사항이 수행되는 외부 조건이나 프레임워크일 뿐, 요구 사항 자체가 아닙니다.
비형식적인 제약 사항을 무시할 수 있습니까?
아니요. 비형식적인 제약 사항(예: 회사의 내부 규칙조차도)을 식별하고 문서화하는 것이 매우 중요하며, 그렇지 않으면 프로젝트가 중단될 위험이 있습니다.
비즈니스 분석가는 기술 제약 사항의 정확한 기술에 대한 책임이 있습니까?
네, 분석가는 비즈니스와 기술 제약 사항 모두를 설명해야 하며, 기술 측면의 세부 사항은 아키텍트 또는 기술 전문가와의 협의에 따라 허용됩니다.
부정적 사례: 은행 프로젝트에서 데이터 저장소에 대한 법적 제약을 고려하지 않았습니다.
장점: 초기 프로세스가 더 빨리 진행됨 단점: 최종적으로 제품이 감사를 통과하지 못하고 차단되어, 회사는 급히 아키텍처를 재구성해야 했습니다.
긍정적 사례: 분석가는 첫날부터 법무팀을 논의에 포함시켜 152-FZ 준수를 위한 제약 사항을 문서화했습니다.
장점: 문제가 초기 단계에서 식별되었고, 해결책이 법률을 고려하여 즉시 설계됨 단점: 문서 검토에 더 많은 시간이 필요함