비즈니스 제약은 법적, 재정적, 조직적, 기술적, 자원적, 시간적 등 미래의 솔루션에 부과되는 모든 조건, 범위 및 제약입니다. 비즈니스 제약 식별은 규제 문서 분석, 주요 이해관계자와의 인터뷰, 회사 내부 정책 검토 및 현재 비즈니스 프로세스 감사 등을 통해 이루어집니다.
제약을 설명할 때 분석가는 이를 가능한 한 구체적으로 формулирует, 요구사항에 반영합니다. 예를 들어, "시스템은 외부 서버에 개인 데이터를 저장해서는 안 됩니다" 또는 "기존 예산/조직도 내에서만 구현 가능"과 같은 형식입니다. 제약은 아키텍처 선택, 기술 스택, 통합 방법 및 프로젝트 계획에 중대한 영향을 미칩니다.
주요 특징:
편리한 인터페이스 요구사항을 비즈니스 제약으로 볼 수 있습니까?
아니요, 이것은 비기능적 요구사항이지 제약이 아닙니다. 비즈니스 제약은 항상 외부 조건(예산, 규제, 기한)입니다.
팀의 경험이 비즈니스 제약입니까?
아니요, 이는 계획에 영향을 미칠 수 있는 조직적 요소지만 직접적인 제약으로 여겨지지 않습니다.
제약이 발주자에 의해 명시되지 않았다면 이를 무시해도 됩니까?
아니요, 분석가는 스스로 조사하고 전문가를 참여시켜야 하며, 그렇지 않으면 프로젝트 실패의 위험이 높습니다.
부정적인 경우: 소프트웨어 라이센스 관련 제약이 도입이 시작된 후에야 드러났습니다. 아키텍처를 급히 변경해야 했습니다. 장점: 신속한 해결, 단점: 비용 증가, 기한 연기, 팀의 부정적 감정.
긍정적인 경우: 분석가는 사전에 보안 관련 내부 정책을 알았고, 초기 단계에서 제약 목록을 합의했습니다. 장점: 안전하고 기대에 부합한 솔루션, 벌금 및 수정 없음. 단점: 변호사 및 정보 보안 부서와 더 많은 회의가 필요했습니다.