비즈니스 요구 사항 정의

모든 비즈니스 요구 사항을 식별할 수 있는 간단한 공식은 없습니다. 소프트웨어 솔루션이 필요한 이해 관계자와의 공동 작업과 비즈니스 영역에 대한 지식 및 응용된 창조적 생각을 기반으로 요구 사항을 판별해야 합니다.

이 절은 비즈니스 요구 사항을 정의할 때 고려해야 할 몇몇 요소를 제공합니다.

비즈니스 목표 설정

비즈니스 분석은 배포 프로젝트의 목표를 명확하게 나타내야 합니다. 명확한 목표는 설계 결정에 집중할 수 있게 하며 프로젝트가 다른 길로 빠지지 않도록 합니다. 비즈니스 목표와 현재 운영을 비교하면 설계 결정을 내리는 데 도움이 될 수 있습니다.

범위

비즈니스 요구 사항에 배포 프로젝트 범위를 기술해야 합니다. 해결할 수 있는 영역을 식별하고 목표를 불명확하거나 도달할 수 없게 만드는 제한 없는 요구 사항을 방지하도록 합니다. 범위를 제대로 정의하지 못하면 비즈니스 요구 사항을 불충분하게 설명하거나 자원을 지나치게 사용하는 배포 설계가 만들어질 수 있습니다.

우선 순위

목표의 우선 순위를 지정하면 배포의 가장 중요한 요소를 먼저 달성할 수 있습니다. 자원이 제한될 경우 일부 목표를 지연하거나 수정해야 할 수 있습니다. 예를 들면 크고 복잡한 배포에는 일반적으로 솔루션의 단계적인 구현이 필요할 수 있습니다. 우선 순위를 기술하면 이해 관계자의 승인을 받기 위해 배포 설계에서 결정해야 할 사항에 대한 지침을 제공할 수 있습니다.

중요한 품질

중요한 영역을 확인하면 이해 관계자와 설계자가 가장 중요한 기준에 집중할 수 있습니다.

성장 요소

비즈니스 목표를 설정하는 경우 조직의 현재 요구를 고려할 뿐만 아니라 이러한 요구가 장기간에 걸쳐 어떻게 변경되고 커질 수 있는 지도 예측해야 합니다. 그렇지 않으면 솔루션이 너무 빨리 구식이 되어버립니다.

안전 여유분

솔루션의 설계는 이 비즈니스 분석 단계 동안 만들어지는 가정을 기반으로 합니다. 이 가정은 불충분한 데이터 판단 상의 오류 또는 예기치 못한 외부 사고와 같은 다양한 이유로 인해 정확하지 않을 수 있습니다. 설계한 솔루션이 갑작스러운 사고에 대처할 수 있도록 비즈니스 목표에서만이 아니라 계획 전반에 걸쳐서 안전을 위한 여유를 갖도록 계획을 세우십시오.

사용자 요구 이해

솔루션의 대상이 되는 사용자 유형과 그들의 요구, 기대되는 혜택을 이해할 수 있도록 필요한 연구를 하십시오. 예를 들면 다음 목록은 사용자를 범주화하는 한 방법입니다.

• 현재 직원 전용

• 현재 및 이전 직원

• 관리자

• 적극적인 고객

• 모든 고객

• 구성원 사이트

• 일반 대중

• 제한된 액세스

예상되는 혜택을 명확하게 기술하면 사용자가 설계 결정을 추진하는 데 도움이 됩니다. 예를 들면 다음은 솔루션으로 사용자가 받을 수 있는 혜택입니다.

• 회사 자원에 대한 원격 액세스

• 엔터프라이즈 공동 작업

• 일일 작업 단순화

• 원격 팀 간 자원 공유

• 생산성 향상

• 최종 사용자에 의한 자체 관리

운영 상 요구 사항 개발

운영 상 요구 사항을 목표와 직접 관련된 일련의 기술 요구 사항으로 표현하십시오. 일반적으로 영역에 대한 운영 사양은 다음과 같이 만듭니다.

• 최종 사용자 기능

• 응답 시간 감소

• 가용성 및 가동 시간

• 오류 비율 감소

• 정보 보관 및 유지

운영 상 요구 사항은 모든 이해 관계자가 이해할 수 있는 측정 가능한 용어로 표현해야 합니다. “적절한 최종 사용자 응답 시간”과 같은 모호한 언어는 피해야 합니다. 운영 상 요구 사항에 대한 예는 다음과 같습니다.

• 중단된 서비스의 10분 내 복구 기능

• 인바운드 메시지 전달에 대한 최종 시간 재생 기능

• 최고 기간 동안 60초 내 완료된 온라인 트랜잭션

• 최고 기간 동안 4초 내 완료되는 최종 사용자 인증

기존 사용 패턴 지원

기존 사용 패턴을 명확히 측정할 수 있는 목표로 표현하십시오. 다음 질문은 그러한 목표를 결정하는데 도움을 줄 수 있습니다.

• 현재 서비스가 어떻게 이용됩니까?

• 사용 패턴은 무엇입니까(예:가끔, 자주 또는 다량 사용)?

• 일반적으로 사용자가 어떤 사이트에 연결합니까?

• 일반적으로 사용자가 어떤 크기의 메시지를 보냅니까?

• 일반적으로 사용자가 하루 당 또는 한시간 당 얼마나 많은 트랜잭션을 완료합니까?

서비스에 액세스하는 사용자를 연구하십시오. 사용자가 기존 서비스에 언제 그리고 얼마나 오래 액세스하는 지와 같은 요소는 목표를 식별하는 열쇠가 됩니다. 조직의 경험이 이러한 패턴을 제공할 수 없는 경우 유사한 조직의 경험을 연구하십시오.

기업 문화 이해

요구 사항 분석은 기업 문화와 정책에 대한 다양한 요소를 고려해야 합니다. 기업 문화에 대한 주의 부족이 솔루션을 잘 받아들여지지 않게 하거나 구현하기 어렵게 만들 수 있습니다.

이해 관계자

제안된 솔루션의 성공에 따라 수익을 얻는 개인이나 조직을 식별하십시오. 모든 이해 관계자가 비즈니스 목표와 요구 사항을 정의하는 데 적극적으로 참여해야 합니다. 이해 관계자가 참여하지 않거나 계획의 변경에 대한 정보를 듣지 못한 경우 계획에 중대한 결함이 발생할 수 있습니다. 그러한 이해 관계자는 심지어 배포의 구현을 방해할 수도 있습니다.

표준과 정책

솔루션을 요청한 조직의 표준과 정책을 이해해야 합니다. 이러한 표준과 정책이 설계, 제품 선택 및 배포 방법의 기술적인 요소에 영향을 미칠 수 있습니다.

한 예로 인사 데이터의 기밀이 인사부나 부서장에 의해 소유되거나 통제될 수 있습니다. 또 다른 예는 변경 사항 관리에 대한 회사 절차입니다. 변경 사항 관리 정책은 솔루션의 승인과 구현 방법 및 시간표에 상당한 영향을 미칠 수 있습니다.

규정 요구 사항

규정 요구 사항은 비즈니스 특성에 따라 크게 다릅니다. 배포에 영향을 미칠 수 있는 모든 규정 요구 사항을 연구하고 이해해야 합니다. 많은 회사와 정부 기관은 액세스 표준의 준수를 요구합니다. 전세계적인 솔루션을 배포할 때는 외국 법과 규정을 고려해야 합니다. 예를 들어 많은 유럽 국가들의 경우 개인 정보 저장에 대해 엄격히 규제하고 있습니다.

보안

식별한 목표에 강조해야 할 보안 문제가 암시되어 있을 수 있습니다. 솔루션에 필수적인 특정 보안 목표를 생각해 보아야 합니다. 예를 들면 다음과 같습니다.

• 독점 정보에 대한 승인된 액세스

• 기밀 정보에 대한 역할 기반 액세스

• 원격 위치 간의 보안 통신

• 로컬 시스템에서 원격 응용 프로그램 호출

• 타사 비즈니스 및 조직과의 보안 트랜잭션

• 보안 정책 시행

사이트 배포

사이트의 지형적 배포 및 사이트 내 대역폭이 설계 결정에 영향을 미칠 수 있습니다. 또한 어떤 사이트는 로컬 관리가 필요할 수 있습니다.

이러한 지형적 고려가 프로젝트의 교육비와 복잡도 등을 증가시킬 수 있습니다. 사이트의 지형적 배포 결과 나타난 요구 사항을 명확히 기술해야 합니다. 설계의 성공을 위해 어떤 사이트가 중요한지 강조해야 합니다.

증분 방법 사용

일반적으로 소프트웨어 솔루션은 전체적이고 포괄적인 시스템으로 간주됩니다. 그러나 종종 전체 시스템의 배포를 정확한 단계에 따라 증분적으로 달성하기도 합니다.

증분 방법을 적용할 경우 일반적으로 최종의 포괄적인 솔루션에 이르는 이정표를 제공하는 로드맵을 설계합니다. 또한 나중에 구현하기 위해 연기된 포괄적인 솔루션 요소에 대해 단기 계획을 고려해야 할 수 있습니다.

증분 방법은 다음과 같은 장점이 있습니다.

• 비즈니스 성장에 따른 요구 사항 변경에 적응할 수 있습니다.

• 최종 배포 구현으로 전환할 때 기존 인프라를 활용할 수 있습니다.

• 자본 지출 요구 사항을 고려할 수 있습니다.

• 적은 인적 자원 공급을 활용할 수 있습니다.

• 제휴 관계 가능성을 고려할 수 있습니다.

서비스 수준 계약 이해

서비스 수준 계약(SLA)은 최소 성능 요구 사항과 해당 요구 사항 달성 실패, 제공되어야 할 고객 지원의 수준 및 범위에 대해 지정합니다. 서비스 수준 계약은 비즈니스 분석 중에 정의된 비즈니스 요구 사항을 기반으로 하며 이 요구 사항은 나중에 기술 요구 사항 단계 중 서비스 수준 요구 사항으로 정의됩니다. SLA는 프로젝트 승인 과정 동안 서명되며 배포 설계 단계에서 나타납니다.

SLA를 가동 시간과 응답 시간, 메시지 전달 시간, 재해 복구 등과 같은 영역에서 개발해야 합니다. SLA는 시스템 개요와 지원 조직의 책임 역할, 서비스 수준 측정 방법 및 요청 변경 등과 같은 항목을 고려해야 합니다. 시스템 가용성에 대한 조직의 기대를 식별하는 것이 SLA의 범위를 결정하는 열쇠입니다.