비즈니스 분석이란 무엇입니까?

비즈니스 분석은 비즈니스 요구 사항을 식별하고 엔터프라이즈 비즈니스 문제에 대한 솔루션을 결정하는 데 필요한 작업, 지식 및 기술의 집합입니다. 일반적인 정의는 비슷하지만 관행과 절차는 산업마다 다를 수 있습니다.

정보 기술 산업에서 솔루션은 종종 시스템 개발 구성 요소를 포함하지만 프로세스 개선 또는 조직 변경으로 구성 될 수도 있습니다.

비즈니스 분석은 조직의 현재 상태를 이해하거나 비즈니스 요구 사항을 식별하기위한 기초 역할을하기 위해 수행 될 수도 있습니다. 그러나 대부분의 경우 비즈니스 요구, 목표 또는 목표를 충족하는 솔루션을 정의하고 검증하기 위해 비즈니스 분석이 수행됩니다.

비즈니스 분석가는 누구입니까?

비즈니스 분석가는 조직 또는 비즈니스 도메인 (실제 또는 가상)을 분석하고 비즈니스, 프로세스 또는 시스템을 문서화하여 비즈니스 모델 또는 기술과의 통합을 평가하는 사람입니다. 그러나 조직의 직함은 분석가, 비즈니스 분석가, 비즈니스 시스템 분석가 또는 시스템 분석가와 같이 다양합니다.

비즈니스 분석가 인 이유

조직은 다음과 같은 이유로 비즈니스 분석을 사용합니다.

• 시스템을 배포 할 조직의 구조와 역학을 이해합니다.

• 대상 조직의 현재 문제를 이해하고 개선 가능성을 식별합니다.

• 고객, 최종 사용자 및 개발자가 대상 조직에 대한 공통적 인 이해를 갖도록합니다.

프로젝트의 초기 단계에서 솔루션 및 디자인 팀이 요구 사항을 해석 할 때 비즈니스 분석가의 역할은 솔루션 문서를 검토하고 솔루션 디자이너 (IT 팀) 및 프로젝트 관리자와 긴밀히 협력하여 요구 사항이 명확합니다.

일반적인 대규모 IT 조직, 특히 개발 환경에서는 위에서 언급 한 역할을 가진 온 사이트 및 해외 배송 팀을 찾을 수 있습니다. 두 팀을 연결해야하는 핵심 담당자 역할을하는 "비즈니스 분석가"를 찾을 수 있습니다.

때때로 그는 비즈니스 사용자 및 때로는 기술 사용자와 상호 작용하고 마지막으로 프로젝트의 모든 이해 관계자와 상호 작용하여 문서를 진행하기 전에 승인을 받고 최종 고개를 끄덕였습니다.

따라서 BA의 역할은 모든 프로젝트의 효과적이고 성공적인 시작에 매우 중요합니다.

IT 비즈니스 분석가의 역할

비즈니스 분석가의 역할은 조직의 비즈니스 영역을 정의하고 범위를 정한 다음 요구 사항을 도출하고, 요구 사항을 분석 및 문서화하고, 이러한 요구 사항을 적절한 이해 관계자와 전달하고, 올바른 솔루션을 식별하고, 솔루션을 검증하여 요구 사항이 예상 표준을 충족합니다.

다른 직업과 어떻게 다른가요?

비즈니스 분석은 재무 분석, 프로젝트 관리, 품질 보증, 조직 개발, 테스트, 교육 및 문서 개발과는 다릅니다. 그러나 조직에 따라 비즈니스 분석가는 이러한 관련 기능의 일부 또는 전부를 수행 할 수 있습니다.

소프트웨어 시스템 개발에 대해서만 작업하는 비즈니스 분석가는 IT 비즈니스 분석가, 기술 비즈니스 분석가, 온라인 비즈니스 분석가, 비즈니스 시스템 분석가 또는 시스템 분석 가라고 할 수 있습니다.

비즈니스 분석에는 이해 관계자, 개발 팀, 테스트 팀 등 간의 연락 작업도 포함됩니다.

소프트웨어 개발 수명주기

SDLC (Software Development Life Cycle)는 소프트웨어 조직 내에서 소프트웨어 프로젝트에서 따르는 프로세스입니다. 특정 소프트웨어를 개발, 유지, 교체, 변경 또는 향상하는 방법을 설명하는 세부 계획으로 구성됩니다. 소프트웨어 품질과 전체 개발 프로세스를 개선하기위한 방법론을 정의합니다.

• SDLC는 고객과 실제 요구 사항을 모두 충족하는 고품질 소프트웨어 시스템을 개발하거나 재 설계하기 위해 IT 분석가가 사용하는 프로세스입니다.

• 소프트웨어 테스트, 분석 및 사후 프로세스 유지 관리와 관련된 모든 측면을 고려합니다.

SDLC의 중요한 단계는 다음 그림에 나와 있습니다.

계획 단계

모든 활동은 계획으로 시작해야합니다. 계획에 실패하면 실패 할 계획입니다. 계획의 정도는 모델마다 다르지만 시스템 사양을 작성하여 구축 할 내용을 명확하게 이해하는 것이 매우 중요합니다.

단계 정의

이 단계에서는 시스템 구조를 분석하고 정의합니다. 아키텍처, 구성 요소 및 이러한 구성 요소가 함께 작동하여 작동하는 시스템을 생성하는 방법을 정의합니다.

디자인 단계

시스템 설계에서는 화면 레이아웃, 비즈니스 규칙, 프로세스 다이어그램 및 기타 문서를 포함하여 설계 기능 및 작업이 자세히 설명됩니다. 이 단계의 출력은 새 시스템을 모듈 또는 하위 시스템의 모음으로 설명합니다.

건물 단계

이것이 개발 단계입니다. 시스템에 생명을 불어 넣기 위해 컴파일러, 인터프리터, 디버거를 사용하여 시스템 설계를 기반으로 코드 생성을 시작합니다.

이행

구현은 구축 단계의 일부입니다. 이 단계에서는 컴파일러, 인터프리터, 디버거를 사용하여 시스템 설계를 기반으로 코드 생성을 시작하여 시스템에 생명을 불어 넣습니다.

테스트 단계

시스템의 다른 부분이 완성됨에 따라; 일련의 테스트를 거칩니다. 제품이 요구 사항 단계에서 해결 된 요구 사항을 실제로 해결하는지 확인하기 위해 요구 사항에 대해 테스트됩니다.

• 테스트 계획 및 테스트 사례는 버그를 식별하고 시스템이 사양에 따라 작동하는지 확인하는 데 사용됩니다.

• 이 단계에서는 단위 테스트, 수동 테스트, 승인 테스트 및 시스템 테스트와 같은 다양한 유형의 테스트가 수행됩니다.

테스트에서 결함 추적

소프트웨어 테스트 보고서는 실행 된 테스트 계획의 결과를 전달하는 데 사용됩니다. 이 경우 보고서에는 테스트중인 현재 시스템과 관련된 모든 테스트 정보가 포함되어야합니다. 보고서의 완성도는 연습 세션에서 확인됩니다.

프로젝트 테스트는 두 가지 주요 목표를 달성하려고합니다.

• 시스템의 오류 및 결함을 감지합니다.

• 요구 사항과 구현 간의 불일치를 감지합니다.

다음 순서도는 Defect Tracking Process −

주요 목표를 달성하기 위해 제안 된 시스템의 테스트 전략은 일반적으로 네 가지 테스트 수준으로 구성됩니다.

이들은 단위 테스트, 통합 테스트, 수락 테스트 및 회귀 테스트입니다. 다음 하위 섹션에서는 이러한 테스트 수준, 개발 및 실행을 담당하는 개발 팀 역할 및 완성도를 결정하는 기준에 대해 설명합니다.

전개

테스트 단계가 끝나면 시스템이 해제되고 프로덕션 환경으로 들어갑니다. 제품이 테스트되고 배포 될 준비가되면 적절한 시장에 공식적으로 출시됩니다. 때때로 제품 배포는 조직의 비즈니스 전략에 따라 단계적으로 이루어집니다.

제품은 제한된 세그먼트로 먼저 출시되고 실제 비즈니스 환경에서 테스트 될 수 있습니다 (UAT- 사용자 승인 테스트). 그런 다음 피드백을 기반으로 제품을있는 그대로 또는 타겟팅 시장 부문에서 제안 된 개선 사항과 함께 출시 할 수 있습니다.

SDLC 이후 프로세스

제품이 시장에 출시되면 기존 고객 기반에 대한 유지 관리가 수행됩니다.

프로덕션 환경에 들어가면 감지되지 않은 버그 또는 기타 예기치 않은 이벤트로 인해 시스템이 수정됩니다. 시스템을 평가하고 시스템 유지 관리를 위해주기를 반복합니다.

SDLC 프로세스 중 비즈니스 분석가의 역할

아래 다이어그램에서 볼 수 있듯이 BA는 비즈니스 요구 사항을 추진하고이를 솔루션 요구 사항으로 변환하는 데 관여합니다.

그는 솔루션 기능을 소프트웨어 요구 사항으로 변환하는 데 관여합니다. 그런 다음 분석 및 설계 단계를 이끌고 코드 개발을 지시 한 다음 버그 수정 중 테스트 단계를 따라 프로젝트 팀의 변경 에이전트로 수행하고 궁극적으로 고객 요구 사항을 충족합니다.

비즈니스 분석-역할

IT 프로젝트에서 비즈니스 분석가의 역할은 다양 할 수 있습니다. 프로젝트 팀 구성원이 여러 역할과 책임을 가질 수 있습니다. 일부 프로젝트에서 BA는 제한된 리소스가있을 때 비즈니스 인텔리전스 분석가, 데이터베이스 디자이너, 소프트웨어 품질 보증 전문가, 테스터 및 / 또는 트레이너의 역할을 맡을 수 있습니다.

프로젝트 코디네이터, 애플리케이션 개발 책임자 또는 개발자가 특정 프로젝트에서 비즈니스 분석가의 역할을 맡을 수도 있습니다.

비즈니스 분석은 평소와 같이 작동하고 작동 방식을 최적화하기 위해 비즈니스 요구 사항 분석과 많이 겹칩니다. 비즈니스 분석의 몇 가지 예는 다음과 같습니다.

• 비즈니스 아키텍처 만들기
• 비즈니스 사례 준비
• 위험 평가 수행
• 요구 사항 추출
• 비즈니스 프로세스 분석
• 요구 사항 문서

BA의 주요 역할

대부분의 비즈니스 분석가의 핵심 역할은 비즈니스와 기술 개발자 간의 연락입니다. 비즈니스 분석가는 비즈니스 클라이언트와 협력하여 시스템 또는 프로세스의 요구 사항을 수집 / 정의하여 생산성을 향상시키는 동시에 기술 팀과 협력하여 시스템 / 프로세스를 설계하고 구현합니다.

기여자로서

BA의 주요 책임은 비즈니스 문제, 요구 사항 및 기능을 식별하는 데있어 비즈니스 사용자 / 주요 사용자의 개발에 기여하고, 개선 기회를 식별하기위한 이해 관계자의 우려와 요구 사항을 이해하고, IT를위한 비즈니스 사례 개발을위한 비즈니스 입력에 기여하는 것입니다. 시스템 개발 프로젝트.

촉진자로서

비즈니스 분석가는 또한 요구 사항의 도출 및 분석을 촉진 / 조정하고 이해 관계자와 협력 및 의사 소통하며 그들의 기대와 요구를 관리하고 요구 사항이 완전하고 모호하지 않으며 실시간 비즈니스 요구에 매핑되도록해야합니다. 조직의.

분석가로서

또 다른 중요한 역할은 시스템 구현을 위해 제안 된 시스템 및 조직의 준비 상태를 평가하고 사용자에게 지원을 제공하고 IT 직원과 협력하는 것입니다.

비즈니스 관점에서 제안 된 IT 시스템의 설계에 대한 입력을 검토하고 제공하기 위해, 이해 관계자들 간의 문제 / 충돌을 해결하고, 사용자가 테스트 사례를 개발할 수 있도록 지원하여 포괄적이고 양질의 UAT를 구성하고, 비즈니스 요구 사항과 요구 사항을 충족하고 예상되는 이점을 실현할 수있는 IT 시스템을 배포했습니다.

범위 개발을위한 비즈니스 분석 활동 계획 및 모니터링, IT 시스템 개발 프로젝트에 대한 비즈니스 분석 관련 활동 수행을위한 일정 및 접근 방식, 진행 상황 모니터링, 내부 프로젝트 관리자와의 조정 및 수익, 수익성, 위험 및 문제보고 적당한.

비즈니스 분석가의 주요 책임

비즈니스 분석가의 책임 세트는 프로젝트의 여러 단계에서 다른 임무를 수행하도록 요구하며 아래에 설명되어 있습니다.

시작 단계

이 단계는 새 프로젝트의 시작을 표시하고 비즈니스 분석가는 다음과 같은 책임을 변경합니다.

• 프로젝트의 비용 편익 분석 수행을 지원합니다.
• 비즈니스 사례를 이해합니다.
• 솔루션 / 프로젝트 / 제품의 실행 가능성을 확인합니다.
• 프로젝트 헌장 작성에 도움이됩니다.
• 프로젝트의 이해 관계자를 식별합니다.

계획 단계

이 단계에는 요구 사항 수집 및 계획, 프로젝트 실행 및 관리 방법이 포함됩니다. 그의 책임에는 다음과 같은 기능이 포함됩니다.

• 요구 사항 유도
• 요구 사항을 분석, 구성 및 문서화합니다.
• 사용 사례, RTM, BRD, SRS 등을 만들어 요구 사항을 관리합니다.
• 제안 된 솔루션을 평가합니다.
• 이해 관계자와 연락하고 커뮤니케이션을 강화합니다.
• 프로젝트 관리 계획 수립을 지원합니다.
• 프로젝트의 범위, 제약, 가정 및 위험을 찾는 데 도움이됩니다.
• 솔루션의 사용자 경험 설계를 지원합니다.

실행 단계

이 단계는 수집 된 요구 사항에 따라 솔루션 개발을 표시합니다. 책임은 다음과 같습니다-

• IT / 개발 팀에 요구 사항을 설명합니다.

• 개발할 제안 된 솔루션에 대한 의심과 우려를 명확히합니다.

• 프로젝트 범위 변경에 대해 논의하고 우선 순위를 정하고 동의를 얻습니다.

• 초기 테스트를위한 베타 테스트 스크립트를 만듭니다.

• 이해 관계자와 개발 모듈을 공유하고 피드백을 요청합니다.

• 마감일을 준수하고 이해 관계자의 기대치를 관리합니다.

• 갈등을 해결하고 프로젝트 팀과의 커뮤니케이션을 관리합니다.

모니터링 및 제어 단계

이 단계에서는 초기 계획에서 벗어난 부분이 있는지 프로젝트를 측정하고 제어합니다. 이 단계는 실행 단계까지 동시에 실행됩니다.

• 테스트 스크립트를 개발하고 포괄적 인 모듈 및 통합 테스트를 수행합니다.

• UAT (수락 테스트 사용) 수행 및 테스트 보고서 작성.

• 클라이언트로부터 결과물을 수락 / 승인합니다.

• 개발 팀에 변경 요청을 설명하십시오.

• 변경 요청의 개발을 모니터링하고 프로젝트의 목표에 따라 구현을 확인합니다.

결산 단계

이 단계는 프로젝트 종료를 표시합니다. 책임은-

• 완성 된 프로젝트를 고객에게 제시하고 승인을 얻습니다.

• 사용자 교육 매뉴얼, 기능 자료 및 기타 지침 가이드를 만듭니다.

• 프로덕션 환경에서 정교한 통합 테스트를 수행합니다.

• 최종 제품 문서를 만들고 프로젝트 교훈을 문서화합니다.

BA는 무엇을 제공 할 것으로 예상됩니까?

비즈니스 분석가는 비즈니스 사용자와 기술 IT 인력 간의 다리 역할을합니다. 그들의 존재는 IT 프로젝트의 성공에 크게 기여할 것입니다. 전담 비즈니스 분석가가 있으면 많은 이점이 있습니다. 전담 비즈니스 분석가는-

• 비즈니스 관점에서 명확한 프로젝트 범위를 제공합니다.

• 건전한 비즈니스 사례를 개발하고 리소스 및 비즈니스 이점에 대한보다 현실적인 추정치를 개발합니다.

• 특히 대규모 IT 프로젝트의 경우 비용 및 일정 측면에서 프로젝트 범위 지정, 계획 및 관리에 대한 더 나은 보고서를 준비합니다.

• 명확하고 간결한 요구 사항을 생성하여 IT 프로젝트를 아웃소싱하는 경우 더 명확하고 정확한 요구 사항을 제공합니다.

• 사용자로부터 실제 비즈니스 요구를 도출하고 사용자 기대치를 효과적으로 관리합니다.

• 제안 된 IT 시스템의 설계 품질을 개선하여 사용자 요구 사항을 충족합니다.

• 검토 및 승인을 위해 최종 사용자에게 전달하기 전에 개발 된 시스템의 품질을 보장합니다.

• 제공된 시스템에 대한 포괄적 인 품질 테스트를 준비하고 기술 IT 직원에게 피드백을 제공합니다.

비즈니스 분석-도구 및 기술

비즈니스 분석가는 BA 모자를 쓰고있을 때 다양한 분석 도구 및 관련 기술에 익숙해야합니다. 내 말은, 당신이이 위치를 유지하고 있다면.

앞서 이미 배웠 듯이 비즈니스 분석은 비즈니스 기업을 이해하고 기회, 문제 영역, 문제를 식별하고 CEO, VP, 이사 및 책임자와 같은 다양한 역할과 책임을 가진 광범위한 사람들을 만나는 프로세스입니다. 비즈니스 요구 사항을 이해합니다.

기본적으로 다음과 같이 분류 할 수있는 3 가지 유형의 비즈니스 분석이 있습니다.

• Strategic Analysis− 전략적 비즈니스 분석은 프로젝트 전 작업을 다룹니다. 비즈니스 문제를 식별하고 비즈니스 전략, 목표 및 목표를 고안하여 최고 경영진을 돕는 방법 또는 프로세스입니다. 효과적인 의사 결정 프로세스를위한 관리 정보보고를 제공합니다.

• Tactical Analysis − 적절한 프로젝트에 적시에 적용 할 특정 비즈니스 분석 기술에 대한 지식이 포함됩니다.

• Operational Analysis− 이러한 유형의 비즈니스 분석에서는 정보 기술을 활용하여 비즈니스 측면에 초점을 맞추고 있습니다. 또한 비즈니스 개선 기회를 식별하기 위해 운영 시스템을 연구하는 프로세스이기도합니다.

각 유형의 분석에 대해 시장에서 사용할 수 있고 조직의 요구 사항 및 요구 사항에 따라 사용할 수있는 도구 세트가 있습니다.

그러나 비즈니스 요구 사항을 이해할 수있는 정보로 구체화하기 위해 좋은 BA는 일상 활동에서 사실 찾기, 인터뷰, 문서 검토, 질문 서, 샘플링 및 연구 기술을 활용합니다.

기능 및 비 기능 요구 사항

요구 사항을 기능 및 비 기능 요구 사항과 같은 두 가지 주요 유형으로 나눌 수 있습니다.

모든 기술 프로젝트의 경우 기능 및 비 기능 요구 사항을 분리하고 별도로 분석해야합니다.

적절한 도구와 적절한 기술을 정의하는 것은 어려운 일이 될 수 있습니다. 새로운 응용 프로그램을 수행하거나 기존 응용 프로그램을 변경하는지 여부. 기능적 과정에 대한 올바른 기술을 고려하는 것은 그 자체로 예술입니다.

현재 시장에서 널리 사용되는 비즈니스 분석 기술의 개요-

프로세스	기법	프로세스 결과물 (성과)
기능 및 비 기능 요구 사항을 확인하려면	JAD 세션 시나리오 및 사용 사례 조직 모델링 범위 모델링 기능적 분해 Interviews 관찰 (Job Shadowing) 포커스 그룹 수락 및 평가 시퀀스 다이어그램 사용자 스토리 Brainstorming Storyboarding Prototyping 구조화 된 워크 스루 이벤트 분석 비즈니스 규칙 분석 요구 사항 워크숍 위험도 분석 근본 원인 분석	Business Requirements Documents − 비즈니스 및 기능 요구 사항 비 기능적 요구 사항 비즈니스 규칙 요구 사항 추적 성 매트릭스 Common Template − 비즈니스 요구 사항 문서

도구 및 프로세스의 적용 가능성

비즈니스 분석가가 사용할 수있는 도구와 절차는 다양하지만 모두 조직의 현재 관행과 사용 방법에 따라 다릅니다.

예를 들면 root-cause analysis 특정 중요한 영역이나 기능에 더 깊이 들어가야 할 때 사용됩니다.

그러나 비즈니스 요구 사항 문서는 요구 사항을 문서 형식으로 만드는 가장 널리 사용되는 방법입니다.

다음 장에서는 위의 기술 중 일부에 대해 심도있게 논의 할 것입니다.

비즈니스 분석-JAD 세션

JAD (Joint Application Development)는 회사를위한 새로운 정보 시스템을 개발하는 동안 비즈니스 요구 사항을 수집하는 데 사용되는 프로세스입니다. JAD 프로세스에는 사용자 참여를 높이고 개발을 촉진하며 사양의 품질을 개선하기위한 접근 방식도 포함될 수 있습니다. JAD 세션의 목적은 주제 전문가 / 비즈니스 분석가 또는 IT 전문가를 모아 솔루션을 제공하는 것입니다.

비즈니스 분석가는 전체 그룹과 상호 작용하고 정보를 수집하고 분석하고 문서를 가져 오는 사람입니다. 그는 JAD 세션에서 매우 중요한 역할을합니다.

JAD 세션 사용

JAD 세션은 단기간에 고품질 결과물을 생성하기 위해 고객 의사 결정권자와 IT 직원을한데 모으는 고도로 구조화되고 촉진 된 워크숍입니다.

즉, JAD 세션을 통해 고객과 개발자는 프로젝트의 기본 범위, 목표 및 사양에 대해 신속하게 합의에 도달하거나 합의에 도달하지 못한 경우 프로젝트를 재평가해야합니다.

간단히 말해서 JAD 세션은

• Simplify − 수개월 간의 회의와 전화 통화를 구조화 된 워크숍으로 통합합니다.

• Identify − 문제 및 참가자

• Quantify − 정보 및 처리 요구

• Clarify − 세션에서 합의 된 모든 요구 사항을 구체화하고 명확히합니다.

• Unify − 한 개발 단계의 출력이 다음 단계로 입력됩니다.

• Satisfy− 고객이 시스템을 정의합니다. 그러므로 그것은 그들의 시스템입니다. 공유 참여는 결과에 대한 공유를 가져옵니다. 그들은 시스템 성공에 전념하게됩니다.

JAD 세션 참가자

JAD 세션에 참여하는 참가자는 다음과 같습니다.

경영진 후원자

경영진 후원자는 프로젝트를 주도하는 사람, 즉 시스템 소유자입니다. 그들은 일반적으로 더 높은 위치에 있으며 결정을 내리고 필요한 전략, 계획 및 방향을 제공 할 수 있습니다.

주제 전문가

성공적인 워크샵을 위해 필요한 비즈니스 사용자 및 외부 전문가입니다. 주제 전문가는 JAD 세션의 중추입니다. 그들은 변화를 주도 할 것입니다.

진행자

그는 회의를 주재합니다. 그는 회의의 일부로 해결할 수있는 문제를 식별합니다. 진행자는 회의에 정보를 제공하지 않습니다.

주요 사용자

주요 사용자 또는 수퍼 유저라고도하는 경우에 따라 상호 교환이 가능하며 회사마다 여전히 다릅니다. 주요 사용자는 일반적으로 IT 프로젝트에보다 밀접하게 연계되어 있고 프로젝트 중에 팀 구성원의 프로필 구성을 담당하는 비즈니스 사용자입니다.

예 : John이 주요 사용자이고 Nancy, Evan이 SAP 시스템 사용자라고 가정합니다. 이 경우 Nancy와 Evan은 기능과 프로필을 변경할 수있는 권한이 없지만 John이 키 사용자 인 경우 더 많은 권한이있는 프로필을 편집 할 수 있습니다.

JAD 접근 방식은보다 전통적인 관행과 비교하여 클라이언트가 개발 프로세스 전체에 참여하기 때문에 개발 시간이 단축되고 클라이언트 만족도가 향상되는 것으로 생각됩니다. 이에 비해 시스템 개발에 대한 전통적인 접근 방식에서 개발자는 시스템 요구 사항을 조사하고 일련의 인터뷰로 구성된 클라이언트 입력을 사용하여 애플리케이션을 개발합니다.

요구 사항 수집 기법

기술은 특정 상황에서 작업이 수행되는 방식을 설명합니다. 작업에는 관련 기술이 없거나 하나 이상있을 수 있습니다. 기술은 적어도 하나의 작업과 관련되어야합니다.

다음은 잘 알려진 요구 사항 수집 기법 중 일부입니다.

브레인 스토밍

브레인 스토밍은 요구 사항 수집에 사용되어 그룹의 사람들로부터 가능한 한 많은 아이디어를 얻습니다. 일반적으로 문제에 대한 가능한 해결책을 식별하고 기회의 세부 사항을 명확히하는 데 사용됩니다.

문서 분석

기존 시스템의 문서를 검토하면 AS–IS 프로세스 문서를 작성할 때 도움이 될뿐만 아니라 마이그레이션 프로젝트 범위 지정을위한 격차 분석을 유도 할 수 있습니다. 이상적인 세상에서 우리는 현재 요구 사항을 문서화하기위한 출발점 인 기존 시스템의 생성을 주도한 요구 사항을 검토 할 수도 있습니다. 많은 정보가 요구 사항 완전성을 검증하는 과정에서 질문을하는 데 도움이되는 기존 문서에 종종 묻혀 있습니다.

포커스 그룹

포커스 그룹은 피드백을 받기 위해 제품의 사용자 또는 고객을 대표하는 사람들의 모임입니다. 요구 사항 / 기회 / 문제에 대한 피드백을 수집하여 요구 사항을 식별하거나 이미 유도 된 요구 사항을 검증하고 개선하기 위해 수집 할 수 있습니다. 이러한 형태의 시장 조사는 특정 참가자가 관리하는 프로세스라는 점에서 브레인 스토밍과는 다릅니다.

인터페이스 분석

소프트웨어 제품의 인터페이스는 인간 또는 기계 일 수 있습니다. 외부 시스템 및 장치와의 통합은 또 다른 인터페이스입니다. 사용자 중심 설계 접근 방식은 사용 가능한 소프트웨어를 만드는 데 매우 효과적입니다. 인터페이스 분석 – 사용자에게 즉시 표시되지 않는 요구 사항을 간과하지 않도록 다른 외부 시스템과의 접점을 검토하는 것이 중요합니다.

회견

이해 관계자와 사용자의 인터뷰는 훌륭한 소프트웨어를 만드는 데 중요합니다. 사용자와 이해 관계자의 목표와 기대를 이해하지 못하면 우리는 그들을 만족시킬 가능성이 거의 없습니다. 우리는 또한 각 인터뷰 대상자의 관점을 인식하여 그들의 의견을 적절하게 평가하고 해결할 수 있어야합니다. 경청은 훌륭한 분석가가 일반 분석가보다 인터뷰에서 더 많은 가치를 얻는 데 도움이되는 기술입니다.

관측

사용자를 관찰함으로써 분석가는 프로세스 흐름, 단계, 문제점 및 개선 기회를 식별 할 수 있습니다. 관찰은 수동적이거나 능동적 일 수 있습니다 (관찰하는 동안 질문하기). 수동 관찰은 프로토 타입에 대한 피드백을받는 데 더 효과적이며 (요구 사항을 구체화하기 위해) 기존 비즈니스 프로세스를 이해하는 데 능동적 관찰이 더 효과적입니다. 두 방법 모두 사용할 수 있습니다.

프로토 타이핑

프로토 타이핑은 요구 사항을 수집하기위한 비교적 현대적인 기술입니다. 이 접근 방식에서는 솔루션의 초기 버전 인 프로토 타입을 빌드하는 데 사용하는 예비 요구 사항을 수집합니다. 이를 고객에게 보여 주면 고객이 추가 요구 사항을 제공합니다. 응용 프로그램을 변경하고 클라이언트와 함께 순환합니다. 이 반복적 인 프로세스는 제품이 중요한 비즈니스 요구 사항을 충족하거나 합의 된 반복 횟수를 충족 할 때까지 계속됩니다.

요구 사항 워크숍

워크숍은 요구 사항을 수집하는 데 매우 효과적 일 수 있습니다. 브레인 스토밍 세션보다 더 구조화 된 관련 당사자가 협력하여 요구 사항을 문서화합니다. 협업을 캡처하는 한 가지 방법은 도메인 모델 아티팩트 (예 : 정적 다이어그램, 활동 다이어그램)를 작성하는 것입니다. 워크샵은 한 명보다 두 명의 분석가가 더 효과적입니다.

리버스 엔지니어링

마이그레이션 프로젝트가 기존 시스템의 충분한 문서에 액세스 할 수없는 경우 리버스 엔지니어링은 시스템이 수행하는 작업을 식별합니다. 시스템이 수행해야하는 작업을 식별하지 않으며 시스템이 잘못된 작업을 수행 할 때 식별하지 않습니다.

설문 조사 / 설문지

많은 사람들로부터 정보를 수집 할 때 (예산 및 시간 제약으로 인터뷰하기에는 너무 많음) 설문 조사 또는 설문지를 사용할 수 있습니다. 설문 조사를 통해 사용자는 선택 항목에서 선택하거나 항목을 평가 ( "강하게 동의, 동의 ...")하거나 자유 형식 응답을 허용하는 개방형 질문을 할 수 있습니다. 설문 조사 디자인은 어렵습니다. 질문은 응답자를 편향시킬 수 있습니다.

기능 요구 사항 문서

기능 요구 사항 문서 (FRD)는 응용 프로그램의 기능 요구 사항에 대한 공식적인 설명입니다. 계약과 동일한 목적으로 사용됩니다. 여기에서 개발자는 지정된 기능을 제공하는 데 동의합니다. 고객은 제품이 FRD에 명시된 기능을 제공하는 경우 만족스러운 제품을 찾는 데 동의합니다.

기능적 요구 사항은 시스템의 의도 된 동작을 캡처합니다. 이 동작은 시스템이 수행하는 데 필요한 서비스, 작업 또는 기능으로 표현 될 수 있습니다. 문서는 특정 프로젝트의 필요에 맞게 조정되어야합니다. 그들은 시스템 계산, 데이터 조작 및 처리, 사용자 인터페이스 및 응용 프로그램과의 상호 작용과 같은 것을 정의합니다.

기능 요구 사항 문서 (FRD)에는 다음과 같은 특징이 있습니다.

• 이는 애플리케이션이 향후 몇 년 동안 비즈니스 목표 및 비즈니스 프로세스 측면에서 가치를 제공함을 보여줍니다.

• 여기에는 애플리케이션에 대한 완전한 요구 사항 세트가 포함되어 있습니다. FRD에 명시되지 않은 것을 가정 할 여지가 없습니다.

• 솔루션 독립적입니다. ERD는 애플리케이션의 작동 방식이 아니라 애플리케이션이 수행해야하는 작업에 대한 설명입니다. FRD는 개발자에게 디자인을 맡기지 않습니다. 따라서 특정 기술의 사용에 대한 언급은 FRD에서 전적으로 부적절합니다.

기능 요구 사항은 다음을 포함해야합니다.

• 설명 data 시스템에 입력

• 설명 operations 각 화면에서 수행

• 설명 work-flows 시스템에서 수행

• 설명 system reports 또는 기타 출력

• 누가 들어갈 수 있습니까? data 시스템에?

• 시스템이 적용 가능한 것을 충족시키는 방법 regulatory requirements?

기능 사양은 일반 사용자가 읽을 수 있도록 설계되었습니다. 독자는 시스템을 이해해야하지만이 문서를 이해하기 위해 기술적 지식이 필요하지 않습니다.

기능적 요구 사항 결과물

BRD (비즈니스 요구 사항 문서)는 다음으로 구성됩니다.

• Functional Requirements− 개발중인 시스템에 대한 세부 요구 사항이 포함 된 문서. 이러한 요구 사항은 시스템이 보유해야하는 기능적 특징과 기능을 정의합니다. 비즈니스 사례에서 확인 된 모든 가정과 제약이 여전히 정확하고 최신 상태인지 확인하십시오.

• Business Process Model − 프로세스의 현재 상태 모델 ( "있는 그대로"모델) 또는 프로세스가되어야하는 개념 ( "모델이 될"모델)

• System Context Diagram − 컨텍스트 다이어그램은 시스템 경계, 시스템과 상호 작용하는 외부 및 내부 개체, 이러한 외부 및 내부 개체 간의 관련 데이터 흐름을 보여줍니다.

• Flow Diagrams (as-is or to-be)− 다이어그램은 비즈니스 프로세스에 대한 작업 순서 또는 데이터 이동을 그래픽으로 묘사합니다. 모델의 복잡성에 따라 하나 이상의 흐름도가 포함됩니다.

• Business Rules and Data Requirements − 비즈니스 규칙은 비즈니스의 일부 측면을 정의하거나 제한하며 데이터 제약, 기본값, 값 범위, 카디널리티, 데이터 유형, 계산, 예외, 필수 요소 및 데이터의 관계 무결성을 정의하는 데 사용됩니다.

• Data Models − 엔티티 관계 다이어그램, 엔티티 설명, 클래스 다이어그램

• Conceptual Model − 비즈니스 기능에 대한 다양한 엔티티와 이들이 서로 관련되는 방식에 대한 높은 수준의 표시.

• Logical Model − 비즈니스 기능과 관련된 특정 엔티티, 속성 및 관계를 설명하고 비즈니스, 기술 또는 개념적 환경에서 데이터의 모든 정의, 특성 및 관계를 나타냅니다.

• Data Dictionary and Glossary − 데이터베이스 또는 유사한 데이터 관리 시스템의 기반이되는 데이터 모델을 구성하는 데이터 요소, 필드, 테이블 및 기타 엔티티에 대한 자세한 정보 모음.

• Stakeholder Map− 제안 된 변경 사항 및 요구 사항에 대한 영향 / 권한 수준의 영향을받는 모든 이해 관계자를 식별합니다. 이 문서는 프로젝트 관리 방법론 (PMM)의 시작 단계에서 개발되었으며 프로젝트 관리자가 소유하지만 프로세스 전반에 걸쳐 신규 / 변경된 이해 관계자가 식별되면 프로젝트 팀에서 업데이트해야합니다.

• Requirements Traceability Matrix − 개별 기능 요구 사항과 기타 기능 요구 사항, 사용 사례 / 사용자 스토리, 아키텍처 및 디자인 요소, 코드 모듈, 테스트 사례 및 비즈니스 규칙을 포함한 기타 유형의 시스템 아티팩트 간의 논리적 링크를 보여주는 표.

소프트웨어 요구 사항 사양

SRS (Software Requirements Specification)는 고객 간의 통신 매체로 사용되는 문서입니다. 가장 기본적인 형태의 소프트웨어 요구 사항 사양은 고객과 개발자 간의 소프트웨어 요구 사항을 전달하는 데 사용되는 공식 문서입니다.

SRS 문서는 WHAT 수행해야하며 신중하게 솔루션을 피합니다 (how to do). 개발 팀과 고객 간의 계약 역할을합니다. 이 단계의 요구 사항은 최종 사용자 용어를 사용하여 작성됩니다. 필요한 경우 나중에 공식 요구 사항 사양이 개발됩니다.

SRS는 개발할 시스템의 동작에 대한 완전한 설명이며 사용자가 소프트웨어를 사용할 수있는 상호 작용을 설명하는 일련의 사용 사례를 포함 할 수 있습니다.

SRS의 목적

SRS는 고객 / 클라이언트, 비즈니스 분석가, 시스템 개발자, 유지 관리 팀 간의 커뮤니케이션 도구입니다. 구매자와 공급 업체 간의 계약일 수도 있습니다.

• 디자인 단계에 대한 확고한 기반을 제공합니다.
• 프로젝트 관리 및 제어 지원
• 시스템 제어 및 발전에 도움

소프트웨어 요구 사항 사양은 완전하고, 일관성 있고, 추적 가능하고, 명확하고, 검증 가능해야합니다.

다음은 시스템 사양에서 다루어야합니다-

• 시스템의 기능 정의
• 하드웨어 / 소프트웨어 기능 분할 정의
• 성능 사양 정의
• 하드웨어 / 소프트웨어 성능 분할 정의
• 안전 요구 사항 정의
• 사용자 인터페이스 정의 (사용자 설명서)
• 설치 도면 / 지침 제공
• 소프트웨어 요구 사항 사양 템플릿

개정 내역

데이트	기술	저자	코멘트
<날짜>	<버전 1>	<당신의 이름>	<1 차 수정>

문서 승인

다음 소프트웨어 요구 사항 사양은 다음에 의해 승인 및 승인되었습니다.

서명	인쇄 이름	표제	데이트
	<당신의 이름>	Lead Software Eng.
	데이비드	강사

비즈니스 분석-사용 사례

UML의 9 개 다이어그램 중 하나는 유스 케이스 다이어그램입니다. 이는 중요 할뿐만 아니라 소프트웨어 프로젝트에 필요한 요구 사항입니다. 기본적으로 소프트웨어 수명주기에서 사용됩니다. 우리가 알고 있듯이 개발주기에는 다양한 단계가 있으며 사용 사례에 가장 많이 사용되는 단계는 요구 사항 수집 단계입니다.

유스 케이스 란 무엇입니까?

유스 케이스는 행위자에게 가치를 제공하는 시스템이 수행하는 일련의 작업을 설명합니다. 사용 사례는 이해 관계자 중 한 사람의 요청에 응답 할 때 다양한 조건에서 시스템의 동작을 설명합니다.primary actor.

행위자는 시스템의 누가, 즉 최종 사용자입니다.

소프트웨어 및 시스템 엔지니어링에서 사용 사례는 목표를 달성하기 위해 일반적으로 역할 (UML에서 "액터"로 알려짐)과 시스템 간의 상호 작용을 정의하는 단계 목록입니다. 배우는 인간 또는 외부 시스템 일 수 있습니다.

사용 사례는 시스템의 이벤트 흐름을 지정합니다. 일련의 작업을 수행하기 위해 시스템에서 수행하는 작업에 더 관심이 있습니다.

사용 사례의 이점

사용 사례는 다음과 같은 이점을 제공합니다.

• 사용자에게 부가되는 가치에 초점을 맞추어 기능적 요구 사항을 포착하는 쉬운 수단입니다.

• 사용 사례는 기존 요구 사항 방법에 비해 상대적으로 쓰기 및 읽기가 쉽습니다.

• 사용 사례는 개발자가 최종 사용자 관점에서 생각하도록합니다.

• 사용 사례는 사용자가 요구 사항 프로세스에 참여하도록합니다.

사용 사례의 구조

이름 : 사용 사례의 목적을 설명하는 이름입니다.

설명 : 사용 사례가 몇 개의 문장에서 수행하는 작업을 설명합니다.

Actor : 유스 케이스에 참여하는 모든 액터를 나열합니다.

전제 조건 : 사용 사례를 시작하기 전에 충족해야하는 조건입니다.

이벤트 흐름 : 시스템과 행위자 간의 상호 작용에 대한 설명.

사후 조건 : 사용 사례가 과정을 실행 한 후 시스템 상태를 설명합니다.

사용 사례 템플릿에 대한 지침

이 장의 끝에 제공된 템플릿을 사용하여 각 사용 사례를 문서화합니다. 이 섹션에서는 사용 사례 템플릿의 각 섹션에 대한 설명을 제공합니다.

사용 사례 식별

• Use-Case ID− 각 사용 사례에 계층 적 형식으로 고유 한 숫자 식별자를 제공합니다. XY 관련 사용 사례를 계층 구조로 그룹화 할 수 있습니다. 기능 요구 사항은 레이블이 지정된 사용 사례로 거슬러 올라갈 수 있습니다.

• Use-Case Name− 사용 사례에 대한 간결하고 결과 지향적 인 이름을 명시하십시오. 이는 사용자가 시스템을 사용하여 수행 할 수 있어야하는 작업을 반영합니다. 동작 동사와 명사를 포함합니다. 몇 가지 예-

  • 부품 번호 정보를 봅니다.

  • 하이퍼 텍스트 소스를 수동으로 표시하고 대상에 대한 링크를 설정합니다.

  • 업데이트 된 소프트웨어 버전으로 CD를 주문하십시오.

사용 사례 기록

여기서는 유스 케이스 문서의 이해 관계자들의 이름에 대해 언급합니다.

• Created By −이 사용 사례를 처음 문서화 한 사람의 이름을 제공하십시오.

• Date Created − 사용 사례가 처음 문서화 된 날짜를 입력합니다.

• Last Updated By − 사용 사례 설명에 가장 최근 업데이트를 수행 한 사람의 이름을 제공합니다.

• Date Last Updated − 사용 사례가 가장 최근에 업데이트 된 날짜를 입력합니다.

사용 사례 정의

다음은 Use-Case의 핵심 개념에 대한 정의입니다.

배우

행위자는 시스템과 상호 작용하고 작업을 수행하기 위해 사용 사례를 수행하는 지정된 소프트웨어 시스템 외부의 사람 또는 기타 엔티티입니다. 다른 행위자는 종종 제품을 사용할 고객 커뮤니티에서 식별 된 다른 사용자 클래스 또는 역할에 해당합니다. 이 사용 사례를 수행 할 액터의 이름을 지정합니다.

기술

이 사용 사례의 이유와 결과에 대한 간략한 설명 또는 작업 순서와 사용 사례 실행 결과에 대한 높은 수준의 설명을 제공합니다.

전제 조건

유스 케이스를 시작하기 전에 발생해야하는 활동 또는 참이어야하는 조건을 나열하십시오. 각 전제 조건에 번호를 매 깁니다.

Examples

• 사용자의 신원이 인증되었습니다.
• 사용자의 컴퓨터에는 작업을 시작하는 데 사용할 수있는 충분한 여유 메모리가 있습니다.

포스트 조건

사용 사례 실행이 끝날 때 시스템 상태를 설명합니다. 각 게시물 조건에 번호를 매 깁니다.

Examples

• 문서에 유효한 SGML 태그 만 포함되어 있습니다.
• 데이터베이스의 항목 가격이 새로운 값으로 업데이트되었습니다.

우선 순위

이 사용 사례를 실행하는 데 필요한 기능 구현의 상대적 우선 순위를 나타냅니다. 사용되는 우선 순위 체계는 소프트웨어 요구 사항 사양에 사용 된 것과 동일해야합니다.

사용 빈도

적절한 시간 단위당 액터가이 사용 사례를 수행 할 횟수를 추정합니다.

일반 이벤트 과정

정상적인 예상 조건에서 사용 사례를 실행하는 동안 발생할 사용자 작업 및 시스템 응답에 대한 자세한 설명을 제공합니다. 이 대화 순서는 궁극적으로 사용 사례 이름 및 설명에 명시된 목표를 달성하는 데 도움이됩니다. 이 설명은 "어떻게 <사용 사례 이름에 명시된 작업을 수행합니까>?"라는 가상의 질문에 대한 답으로 작성 될 수 있습니다. 이는 액터가 수행 한 작업의 번호가 매겨진 목록으로 수행되며 시스템에서 제공하는 응답과 번갈아 가며 수행됩니다.

대안 코스

이 사용 사례 내에서 발생할 수있는 다른 합법적 인 사용 시나리오를이 섹션에서 별도로 문서화합니다. 대체 과정을 설명하고 발생하는 단계 순서의 차이점을 설명합니다. Use-case ID를 접두사로 사용하여 각 대체 코스에 번호를 매기고 "대체 코스"를 나타 내기 위해 "AC"가 뒤 따릅니다. 예 : XYAC.1.

예외

유스 케이스 실행 중에 발생할 수있는 예상 오류 조건을 설명하고 시스템이 이러한 조건에 응답하는 방법을 정의합니다. 또한 예상치 못한 이유로 사용 사례 실행이 실패하는 경우 시스템이 응답하는 방법을 설명합니다. 사용 사례 ID를 접두사로 사용하여 각 예외에 번호를 매기고 그 뒤에 "예외"를 나타 내기 위해 "EX"를 붙입니다. 예 : XYEX.1.

포함

이 사용 사례에 포함 된 ( "호출") 다른 사용 사례를 나열합니다. 여러 사용 사례에 나타나는 공통 기능은 해당 공통 기능이 필요한 기능에 포함 된 별도의 사용 사례로 분리 될 수 있습니다.

특별 요구 사항

설계 또는 구현 중에 해결해야 할 사용 사례에 대한 비 기능적 요구 사항과 같은 추가 요구 사항을 식별합니다. 여기에는 성능 요구 사항 또는 기타 품질 속성이 포함될 수 있습니다.

가정

이 사용 사례를 제품 설명에 수용하고 사용 사례 설명을 작성하도록 이끈 분석에서 만들어진 모든 가정을 나열합니다.

참고 및 문제

이 사용 사례 또는 해결해야하는 남아있는 미해결 문제 또는 미정 (미정)에 대한 추가 의견을 나열합니다. 각 문제를 해결할 사람, 기한 및 궁극적으로 해결 방법을 식별합니다.

변경 관리 및 버전 제어

버전 제어는 문서, 대규모 웹 사이트 및 기타 정보 모음의 변경 사항을 관리하는 것입니다. 변경 사항은 일반적으로 개정 번호 또는 개정 수준이라고하는 숫자 또는 문자 코드로 식별됩니다. 각 개정은 타임 스탬프 및 변경하는 사람과 연결됩니다.

사용 사례 다이어그램

UML (Unified Modeling Language)의 중요한 부분은 사용 사례 다이어그램을 그리는 기능입니다. 사용 사례는 프로젝트의 분석 단계에서 시스템 기능을 식별하고 분할하는 데 사용됩니다. 그들은 시스템을 행위자와 사용 사례로 분리합니다. 액터는 시스템 사용자가 수행 할 수있는 역할을 나타냅니다.

이러한 사용자는 사람, 다른 컴퓨터, 하드웨어 또는 다른 소프트웨어 시스템 일 수 있습니다. 유일한 기준은 유스 케이스로 분할되는 시스템 부분의 외부에 있어야한다는 것입니다. 그들은 시스템의 해당 부분에 자극을 공급해야하며, 시스템에서 출력을 받아야합니다.

유스 케이스는 목표를 추구하기 위해 액터가 시스템의 도움을 받아 수행하는 활동을 나타냅니다. 사용자 (액터)가 시스템에서 무엇을 필요로하는지 정의해야합니다. 사용 사례는 사용자의 요구와 목표를 반영해야하며 행위자가 시작해야합니다. 비즈니스 유스 케이스에 참여하는 비즈니스, 행위자, 고객은 연관별로 유스 케이스에 연결되어야합니다.

사용 사례 다이어그램 그리기

아래 그림은 유스 케이스가 UML 도식 형식과 같은 모습을 보여줍니다. 사용 사례 자체는 타원형처럼 보입니다. 배우들은 작은 막대기 모양으로 그려져 있습니다. 액터는 선으로 유스 케이스에 연결됩니다.

Use-case 1 − 영업 담당자가 항목을 확인합니다.

• 고객이 카운터에 항목을 설정합니다.
• «사용»스 와이프 UPC 리더.
• 시스템은 품목 설명 및 가격을 조달하는 데이터베이스에서 UPC 코드를 조회합니다.
• 시스템에서 경고음이 울립니다.
• 시스템은 음성 출력을 통해 품목 설명과 가격을 알려줍니다.
• 시스템은 현재 송장에 가격 및 품목 유형을 추가합니다.
• 시스템은 정확한 세금 소계에 가격을 추가합니다.

따라서«uses»관계는 함수 호출 또는 서브 루틴과 매우 유사합니다.

이러한 방식으로 사용되는 유스 케이스는 자체적으로 존재할 수 없지만 다른 유스 케이스에서 사용해야하기 때문에 추상 유스 케이스라고합니다.

예 ─ 철수 유스 케이스

현금 자동 판매기 (ATM)와 관련된 고객의 목표는 돈을 인출하는 것입니다. 그래서 우리는Withdrawal사용 사례. 자판기에서 돈을 인출하려면 거래를 수행하기 위해 은행이 필요할 수 있습니다. 그래서 우리는 또 다른 액터를 추가하고 있습니다.Bank. 유스 케이스에 참여하는 두 행위자는 연관에 의해 유스 케이스에 연결되어야합니다.

현금 자동 판매기는 고객 및 은행 행위자에게 인출 사용 사례를 제공합니다.

액터와 사용 사례 간의 관계

사용 사례는 다음 관계를 사용하여 구성 할 수 있습니다.

• Generalization
• Association
• Extend
• Include

사용 사례 간 일반화

액터가 유사한 사용 사례와 관련된 경우가있을 수 있습니다. 이러한 경우 하위 사용 사례는 상위 사용의 속성과 동작을 상속합니다. 따라서 우리는 기능의 상속을 보여주기 위해 액터를 일반화해야합니다. 큰 중공 삼각형 화살촉이있는 실선으로 표시됩니다.

사용 사례 간의 연결

행위자와 유스 케이스 간의 연관은 유스 케이스 다이어그램에서 실선으로 표시됩니다. 유스 케이스에서 설명하는 상호 작용에 액터가 관련 될 때마다 연관이 존재합니다.

넓히다

선택적으로 트리거되는 몇 가지 기능이 있습니다. 이러한 경우 확장 관계가 사용되고 확장 규칙이 첨부됩니다. 기억해야 할 점은 확장 사용 사례가 호출되지 않더라도 기본 사용 사례가 자체적으로 기능을 수행 할 수 있어야한다는 것입니다.

확장 관계는 확장 사용 사례에서 확장 (기본) 사용 사례로 향하는 열린 화살촉이있는 파선으로 표시됩니다. 화살표는«확장»키워드로 레이블이 지정됩니다.

포함

여러 사용 사례에서 중복되는 사용 사례 조각을 추출하는 데 사용됩니다. 또한 여러 유스 케이스로 분할하여 대규모 유스 케이스를 단순화하고 둘 이상의 유스 케이스 동작의 공통 부분을 추출하는 데 사용됩니다.

기본 사용 사례에서 포함 된 사용 사례까지의 열린 화살촉이있는 파선 화살표로 표시되는 사용 사례 간의 관계를 포함합니다. 화살표는«포함»키워드로 레이블이 지정됩니다.

사용 사례는 시스템의 기능적 요구 사항 만 다룹니다. 비즈니스 규칙, 서비스 품질 요구 사항 및 구현 제약과 같은 기타 요구 사항은 별도로 표현해야합니다.

아래에 표시된 다이어그램은 모든 요소가 표시된 간단한 사용 사례 다이어그램의 예입니다.

사용 사례의 성공적인 적용을위한 기본 원칙

• 이야기를 통해 간단하게 유지
• 완벽하지 않은 생산성
• 큰 그림 이해
• 사용 사례에 대한 재사용 기회 식별
• 가치에 집중
• 조각으로 시스템 구축
• 증분 단위로 시스템 제공
• 팀의 요구 사항에 맞게 조정

사용 사례 템플릿

여기에서는 기술 팀이 프로젝트에 대한 정보를 확인하는 데 유용 할 수 있도록 비즈니스 분석가가 채울 수있는 사용 사례의 샘플 템플릿을 보여줍니다.

사용 사례 ID :
사용 사례 이름 :
작성자 :		마지막 업데이트 자
생성 일자:		마지막 업데이트 날짜
배우:
기술:
전제 조건 :
포스트 조건 :
우선 순위:
사용 빈도:
일반 이벤트 과정 :
대체 코스 :
예외 :
다음을 포함합니다 :
특별 요구 사항 :
가정 :
참고 및 문제 :

비즈니스 분석-요구 사항 관리

소프트웨어 요구 사항 수집은 전체 소프트웨어 개발 프로젝트의 기초입니다. 비즈니스 요구 사항을 요청하고 수집하는 것은 모든 프로젝트의 중요한 첫 번째 단계입니다. 비즈니스 요구 사항과 기술 요구 사항 간의 격차를 해소하기 위해 비즈니스 분석가는 주어진 컨텍스트 내에서 비즈니스 요구 사항을 완전히 이해하고 이러한 요구 사항을 비즈니스 목표에 맞추고 이해 관계자와 개발 팀 모두에게 요구 사항을 적절히 전달해야합니다.

주요 이해 관계자는 누군가가 고객 / 고객 요구 사항을 평이한 영어로 설명 할 수 있기를 바랍니다. 이것이 높은 수준의 가치를 이해하는 데 도움이 될까요? 요구 사항과 BA가 가능한 최선의 방식으로 통신 할 수있는 방법을 문서에 매핑하려고 시도하기 때문에 이것이 주요 초점 영역이 될 것입니다.

프로젝트가 실패하는 이유

프로젝트가 실패하는 이유는 여러 가지가 있지만 공통 영역 중 일부는 다음과 같습니다.

• 시장 및 전략 실패
• 조직 및 계획 실패
• 품질 실패
• 리더십 및 거버넌스 실패
• 기술, 지식 및 역량 실패
• 참여, 팀 작업 및 커뮤니케이션 실패

문제의 핵심은 프로젝트가 점점 더 복잡해지고 변화가 일어나며 커뮤니케이션이 어렵다는 것입니다.

성공적인 팀이 요구 사항 관리를 수행하는 이유

요구 사항 관리는 팀 유지에 관한 것입니다. in-sync 및 제공 visibility 프로젝트 내에서 일어나는 일에.

전체 팀이 무엇을 구축하고 있으며 그 이유를 이해하는 것은 프로젝트의 성공에 매우 중요합니다. 이것이 우리가 요구 사항 관리를 정의하는 방법입니다. "이유"는 요구 사항에 대한 목표, 피드백 및 결정에 대한 컨텍스트를 제공하기 때문에 중요합니다.

이를 통해 미래의 성공과 잠재적 인 문제에 대한 예측 가능성이 높아져 팀이 문제를 신속하게 해결하고 제 시간에 예산 내에서 프로젝트를 성공적으로 완료 할 수 있습니다. 시작점으로, 관련된 모든 사람이 요구 사항이 무엇인지, 요구 사항을 관리하는 방법을 기본적으로 이해하는 것이 중요합니다.

기초부터 시작합시다

요구 사항은 이해 관계자가 문제를 해결하거나 목표를 달성하는 데 필요한 조건 또는 기능입니다. 시스템 또는 시스템이 충족하거나 소유해야하는 조건 또는 기능입니다. 계약, 표준, 사양 또는 기타 공식적으로 부과 된 문서를 충족하는 구성 요소입니다.

요구 사항은 텍스트, 스케치, 세부 모형 또는 모델로 표현할 수 있습니다. 어떤 정보를 구축할지 엔지니어와 테스트 할 내용을 QA 관리자에게 가장 잘 전달하는 정보가 무엇이든간에 표현할 수 있습니다. 개발 프로세스에 따라 요구 사항을 캡처하기 위해 다른 용어를 사용할 수 있습니다.

높은 수준의 요구 사항은 때때로 간단히 needs 또는 goals. 소프트웨어 개발 관행 내에서 요구 사항은 "사용 사례", "기능"또는 "기능적 요구 사항"이라고 할 수 있습니다. 보다 구체적으로 애자일 개발 방법론 내에서 요구 사항은 종종 다음과 같이 캡처됩니다.epics 과 stories.

팀에서 부르는 이름이나 사용하는 프로세스에 관계없이 요구 사항은 모든 제품의 개발에 필수적입니다. 요구 사항을 명확하게 정의하지 않으면 불완전하거나 결함이있는 제품을 생산할 수 있습니다. 프로세스 전반에 걸쳐 요구 사항을 정의하는 데 많은 사람이 참여할 수 있습니다.

이해 관계자는 제품이 문제 해결에 가치를 제공하는 방법을 설명하는 기능을 요청할 수 있습니다. 디자이너는 사용성 또는 사용자 인터페이스 관점에서 최종 제품의 모양이나 성능에 따라 요구 사항을 정의 할 수 있습니다.

비즈니스 분석가는 특정 기술 또는 조직 제약을 준수하는 시스템 요구 사항을 만들 수 있습니다. 오늘날의 정교한 제품과 소프트웨어 애플리케이션을 구축하려면 프로젝트 또는 릴리스의 범위를 충분히 정의하는 데 수백 또는 수천 개의 요구 사항이 필요한 경우가 많습니다. 따라서 요구 사항은 개발 프로세스 중에 시간이 지남에 따라 자연스럽게 변경되고 진화하므로 팀이 각 요구 사항에 액세스하고, 공동 작업하고, 업데이트하고, 완료 할 때까지 테스트 할 수 있어야합니다.

이제 높은 수준에서 요구 사항 관리의 가치를 정의 했으므로 모든 팀 구성원과 이해 관계자가 이해를 통해 이점을 얻을 수있는 네 가지 기본 사항에 대해 자세히 살펴 보겠습니다.

• 좋은 요구 사항 계획 : "우리가 무엇을 구축하고 있습니까?"
• 협업 및 바이 인 : "이미 사양을 승인하십시오!"
• 추적 성 및 변경 관리 : "잠깐, 개발자가 변경 사항을 알고 있습니까?"
• 품질 보증 : "안녕하세요, 이걸 테스트 한 사람 있나요?"

모두가 우리가 무엇을 만들고 있으며 그 이유를 알고 있습니까? 이것이 요구 사항 관리의 가치입니다.

이해 관계자의 협업 및 바이 인

모두가 루프에 있습니까? 앞으로 나아 가기위한 요구 사항에 대한 승인이 있습니까? 이러한 질문은 개발주기 중에 발생합니다. 모든 사람이 요구 사항에 동의 할 수 있다면 좋겠지 만 많은 이해 관계자가있는 대규모 프로젝트에서는 일반적으로 발생하지 않습니다. 모든 사람의 동의를 얻으려고하면 결정이 지연되거나 더 나빠질 수 있습니다. 모든 결정에 대해 합의를 얻는 것이 항상 쉬운 것은 아닙니다.

실제로는 반드시 "합의"를 원할 필요는 없으며 그룹의 "구매"및 관리 대상의 승인을 원하므로 프로젝트를 진행할 수 있습니다. 합의를 통해 모든 사람이 타협하고 결정에 동의하도록하려는 것입니다. 바이 인 (buy-in)을 통해 사람들이 최상의 솔루션을 지원하고 현명한 결정을 내리고 앞으로 나아가는 데 필요한 작업을 수행하도록하려는 것입니다.

모든 사람이 결정이 최선이라는 데 동의 할 필요는 없습니다. 결정을 지원할 모든 사람이 필요합니다. 팀 공동 작업은 의사 결정에 대한 지원을 받고 좋은 요구 사항을 계획하는 데 도움이 될 수 있습니다.

협업 팀은 모든 사람이 프로젝트에 대한 이해 관계를 갖고 피드백을 제공하도록 열심히 노력합니다. 협업 팀은 지속적으로 아이디어를 공유하고, 일반적으로 더 나은 의사 소통을하며, 프로젝트 목표에 대한 헌신과 이해가 공유되기 때문에 내린 결정을 지원하는 경향이 있습니다.

개발자, 테스터 또는 기타 이해 관계자가 의사 소통 문제가 발생하고 사람들이 좌절감을 느끼고 프로젝트가 지연되는 "루프에서 벗어났습니다"라고 느낄 때입니다. 모든 사람이 작업 범위에 동의 한 후에는 요구 사항을 명확하고 잘 문서화해야합니다. 모든 요구 사항을 추적하는 것은 문제가되는 부분입니다.

완료하기 위해 여러 사람과 협력해야하는 1 마일 길이의 할 일 목록이 있다고 상상해보십시오. 그 모든 항목을 어떻게 똑바로 유지 하시겠습니까? 한 항목의 변경이 프로젝트의 나머지 부분에 어떤 영향을 미치는지 어떻게 추적 하시겠습니까? 추적 성과 변경 관리가 가치를 더하는 곳입니다.

좋은 요구 사항 계획

그렇다면 좋은 요구 사항은 무엇입니까? 좋은 요구 사항은 가치 있고 실행 가능해야합니다. 솔루션에 대한 경로를 제공 할뿐만 아니라 필요를 정의해야합니다. 팀원 모두가 그 의미를 이해해야합니다. 요구 사항은 복잡성에 따라 다릅니다.

• 좋은 요구 사항 문서는 하위 요구 사항으로 분류 된 높은 수준의 요구 사항이있는 그룹의 일부가 될 수 있습니다.

• 또한 최종 제품의 동작 또는 구성 요소를 설명하는 기능 요구 사항 집합을 포함하는 매우 상세한 사양을 포함 할 수 있습니다.

• 좋은 요구 사항은 간결하고 구체적이어야하며 "우리에게 무엇이 필요합니까?"라는 질문에 답해야합니다. 대신“우리는 어떻게 필요를 충족합니까?”

• 좋은 요구 사항은 모든 이해 관계자가 계획에서 자신의 부분을 이해하도록 보장합니다. 부품이 불분명하거나 잘못 해석되면 최종 제품에 결함이 있거나 고장날 수 있습니다.

요구 사항이 발전함에 따라 프로세스 전반에 걸쳐 팀으로부터 지속적으로 피드백을 받으면 요구 사항의 실패 또는 오해를 방지 할 수 있습니다. 모든 사람과의 지속적인 협업과 동의는 성공의 열쇠입니다.

요구 사항 수집 및 분석

요구 사항은 이해 관계자가 문제를 해결하거나 조직 목표를 달성하는 데 필요한 조건 또는 기능입니다. 시스템이 충족하거나 소유해야하는 조건 또는 기능.

소프트웨어 엔지니어링의 요구 사항 분석 은 다양한 이해 관계자의 가능한 상충 요구 사항을 고려하고 소프트웨어 또는 시스템 요구 사항을 분석, 문서화, 검증 및 관리하여 새롭거나 변경된 제품에 대해 충족해야 할 요구 사항 또는 조건을 결정하는 작업을 다룹니다.

요구 사항은-

• Documented
• Actionable
• Measurable
• Testable
• Traceable

요구 사항은 식별 된 비즈니스 요구 또는 기회와 관련되어야하며 시스템 설계에 충분한 세부 수준으로 정의되어야합니다.

비즈니스 분석가는 기존 시스템 관찰, 기존 절차 연구, 고객 및 최종 사용자와의 토론을 통해 정보를 수집합니다. 분석가는 또한 작동하는 시스템이 없을 때 상상력과 창의력을 가져야합니다. 누락 된 링크를 찾기 위해 수집 된 요구 사항을 분석하는 것이 요구 사항 분석입니다.

접근 유도

목표를 도출하려면 비즈니스 전문가, 개발 관리자 및 프로젝트 후원자에게 다음 질문을 요청하십시오.

• 이 프로젝트가 달성하는 데 도움이되는 회사의 비즈니스 목표는 무엇입니까?

• 우리가 지금이 프로젝트를하는 이유는 무엇입니까?

• 나중에하면 어떻게 될까요?

• 우리가 전혀하지 않으면 어떨까요?

• 이 프로젝트의 혜택은 누구에게 있습니까?

• 그것으로부터 혜택을받을 사람들은 이것이 현재 가능할 수있는 가장 중요한 개선이라고 생각합니까?

• 대신 다른 프로젝트를해야합니까?

가능한 목표는 비용 절감, 고객 서비스 개선, 작업 흐름 단순화, 구식 기술 교체, 새로운 기술 파일럿 및 기타 많은 것입니다. 또한 제안 된 프로젝트가 명시된 목표를 달성하는 데 어떻게 도움이되는지 정확히 이해해야합니다.

다양한 유형의 요구 사항

비즈니스 분석가가 관심을 갖는 가장 일반적인 유형의 요구 사항은 다음과 같습니다.

비즈니스 요구 사항

비즈니스 요구 사항은 솔루션 독립적 인 상태를 유지하면서 조직의 목표를 충족하기 위해 수행해야하는 기업의 중요한 활동입니다. BRD (비즈니스 요구 사항 문서)는 고객 요구 사항 및 기대 사항에 대한 문서를 포함하여 프로젝트에 대한 비즈니스 솔루션을 자세히 설명합니다.

사용자 요구 사항

사용자 요구 사항은 사용자가 소프트웨어 프로젝트에서 구성 될 소프트웨어에서 기대 / 원하는 특정 요구 사항을 지정해야합니다. 사용자 요구 사항은 검증 가능하고, 명확하고, 간결하고, 완전하고, 일관성 있고, 추적 가능하고, 실행 가능해야합니다.

사용자 요구 사항 문서 (URD) ​​또는 사용자 요구 사항 사양은 사용자가 소프트웨어가 수행 할 수있을 것으로 기대하는 작업을 지정하는 소프트웨어 엔지니어링에서 일반적으로 사용되는 문서입니다.

시스템 요구 사항

시스템 요구 사항은 응용 프로그램의 최적 기능을 제공하기 위해 컴퓨터에 설치해야하는 소프트웨어 리소스 요구 사항 및 전제 조건을 정의합니다.

기능 요구 사항

기능 요구 사항은 개발중인 시스템의 특정 의도 된 동작을 캡처하고 지정합니다. 시스템 계산, 데이터 조작 및 처리, 사용자 인터페이스 및 응용 프로그램과의 상호 작용, 사용자 요구 사항을 충족하는 방법을 보여주는 기타 특정 기능 등을 정의합니다. 각 요구 사항에 고유 한 ID 번호를 할당합니다.

비 기능적 요구 사항

비 기능적 요구 사항은 특정 행동보다는 시스템의 작동을 판단하는 데 사용할 수있는 기준을 지정하는 요구 사항입니다. 시스템 아키텍처는 비 기능적 요구 사항을 구현하기위한 계획을 말합니다.

비 기능적 요구 사항은 시스템이 어떻게 생겼는지에 대해 말하거나 "시스템이 될 것"과 같이 언급 될 수 있습니다. 비 기능적 요구 사항을 시스템의 품질이라고합니다.

전환 요건

전환 요구 사항은 기업의 현재 상태에서 원하는 미래 상태로 쉽게 전환하기 위해 솔루션이 충족해야하는 기능을 설명하지만 전환이 완료되면 필요하지 않습니다.

이는 항상 일시적이고 기존 솔루션과 새로운 솔루션이 모두 정의 될 때까지 개발할 수 없기 때문에 다른 요구 사항 유형과 구별됩니다. 일반적으로 기존 시스템의 데이터 변환, 해결해야하는 기술 격차 및 원하는 미래 상태에 도달하기위한 기타 관련 변경 사항을 다룹니다. 솔루션 평가 및 검증을 통해 개발 및 정의됩니다.

추적 성 및 변경 관리

요구 사항 추적 성은 초기 아이디어 생성에서 테스트 단계에 이르기까지 모든 요구 사항을 구성, 문서화 및 추적하는 방법입니다.

요구 사항 추적 능력 매트릭스 (RTM)는 개발 프로세스를 통해 기능 요구 사항 및 구현을 추적하는 방법을 제공합니다. 각 요구 사항은 관련 섹션 번호와 함께 매트릭스에 포함됩니다.

프로젝트가 진행됨에 따라 RIM은 각 요구 사항의 상태를 반영하도록 업데이트됩니다. 제품이 시스템 테스트 준비가되면 매트릭스에 각 요구 사항,이를 해결하는 제품 구성 요소 및 올바르게 구현되었는지 확인하는 테스트가 나열됩니다.

RTM에 다음 각 항목에 대한 열 포함-

• 요구 사항 설명
• FRD의 요구 사항 참조
• 확인 방법
• 테스트 계획의 요구 사항 참조

Example− 프로젝트 내 항목 간의 관계를 식별하기 위해 점을 연결합니다. 일반적인 하류 흐름의 연결기입니다.

아이디어 요구 사항 디자인 테스트 비즈니스 목표

각각의 요구 사항을 원래의 비즈니스 목표까지 추적 할 수 있어야합니다.

요구 사항을 추적하여 파급 효과 변경 사항을 식별하고 요구 사항이 완료되었는지 여부와 제대로 테스트되고 있는지 확인할 수 있습니다. 추적 가능성 및 변경 관리는 관리자에게 문제를 예측하고 지속적인 품질을 보장하는 데 필요한 가시성과 마음의 평화를 제공합니다.

품질 보증

요구 사항을 처음에 올바르게 제공하면 제품에 대한 품질 향상, 개발주기 단축 및 고객 만족도 향상을 의미 할 수 있습니다. 요구 사항 관리는 올바른 목표를 달성하는 데 도움이 될뿐만 아니라 팀이 개발 프로세스 전반에 걸쳐 비용과 많은 골칫거리를 절약하는 데 도움이됩니다.

간결하고 구체적인 요구 사항은 수정하는 데 훨씬 더 많은 비용이 드는 나중에가 아니라 조기에 문제를 감지하고 수정하는 데 도움이 될 수 있습니다. 또한 비용은 최대100 times 코딩 후 개발 프로세스 후반에 결함을 수정하는 것이 요구 사항을 조기에 수정하는 것보다 더 많습니다.

요구 사항 관리를 품질 보증 프로세스에 통합함으로써 팀의 효율성을 높이고 재 작업을 제거 할 수 있습니다. 또한 재 작업은 대부분의 비용 문제가 발생하는 곳입니다.

즉, 개발 팀은 처음에 올바르게 수행되지 않은 노력에 예산의 대부분을 낭비하고 있습니다. 예를 들어 개발자는 나중에 해당 기능에 대한 요구 사항이 변경되었음을 알기 위해 이전 사양 문서를 기반으로 기능을 코딩합니다. 효과적인 요구 사항 관리 모범 사례를 통해 이러한 유형의 문제를 방지 할 수 있습니다.

요약하면 요구 사항 관리는 복잡한 규율처럼 들릴 수 있지만 간단한 개념으로 요약하면 팀이 "우리가 구축하고있는 내용과 그 이유를 모두 이해합니까?"라는 질문에 답하는 데 도움이됩니다. 비즈니스 분석가, 제품 관리자 및 프로젝트 리더에서 개발자, QA 관리자 및 테스터, 관련 이해 관계자 및 고객에 이르기까지 프로젝트 실패의 근본 원인은 프로젝트 범위에 대한 오해입니다.

모든 사람이 협업하고 프로젝트 라이프 사이클 전반에 걸쳐 요구 사항과 관련된 토론, 결정 및 변경 사항에 대한 전체 컨텍스트 및 가시성을 확보 할 때, 즉 성공이 일관되게 발생하고 지속적인 품질을 유지합니다. 또한 프로세스는 관련된 모든 사람에게 마찰과 불만이 적어 더 부드럽습니다.

Note− 연구에 따르면 프로젝트 팀은 요구 사항을 효과적으로 관리하여 프로젝트 결함의 50-80 %를 제거 할 수 있습니다. Carnegie Mellon 소프트웨어 엔지니어링 연구소에 따르면 "소프트웨어 개발 비용의 60-80 %가 재 작업에 있습니다."

요구 사항 사인 오프 얻기

요구 사항 사인 오프는 문서화 된대로 요구 사항의 내용과 표현이 정확하고 완전하다는 프로젝트 이해 관계자의 동의를 공식화합니다. 공식적인 합의는 구현 중 또는 이후에 이해 관계자가 새로운 (이전에 만나지 않은) 요구 사항을 도입 할 위험을 줄입니다.

요구 사항 사인 오프를 얻으려면 일반적으로 각 프로젝트 이해 관계자와 함께 문서화 된 요구 사항을 직접 대면하여 최종 검토해야합니다. 검토가 끝날 때마다 이해 당사자는 검토 된 요구 사항 문서를 공식적으로 승인해야합니다. 이 승인은 물리적 또는 전자적으로 기록 될 수 있습니다.

요구 사항 사인 오프를 얻는 것은 일반적으로 Requirements Communication 내에서 마지막 작업입니다. 비즈니스 분석가는 검토 과정에서 제기 된 의견이나 이의 제기의 수용을 포함하여 공식 요구 사항 검토의 결과를 요구합니다.

비즈니스 분석-모델링

비즈니스 모델은 지원 텍스트 및 다른 구성 요소와의 관계와 함께 그래픽 구성 요소를 종종 포함하는 비즈니스 또는 솔루션의 표현으로 정의 할 수 있습니다. 예를 들어, 회사의 비즈니스 모델을 이해해야한다면 다음과 같은 영역을 연구하고 싶습니다.

• 회사의 핵심 가치
• 무엇을 제공합니까?
• 세트는 무엇입니까?
• 주요 자원
• 주요 관계
• 배달 채널

모델링 기술의 도움으로 기업에서 사용하는 기존 및 제안 된 조직 구조, 프로세스 및 정보에 대한 완전한 설명을 작성할 수 있습니다.

비즈니스 모델은 개발 될 최종 제품의 청사진과 같은 구조화 된 모델입니다. 계획을위한 구조와 역학을 제공합니다. 또한 최종 제품의 토대를 제공합니다.

비즈니스 모델링의 목적

비즈니스 모델링은 기업의 현재 및 미래 상태를 설계하는 데 사용됩니다. 이 모델은 비즈니스 분석가와 이해 관계자가 기업의 현재 "현상태대로"모델을 정확하게 이해하고 있는지 확인하는 데 사용됩니다.

이해 관계자가 제안 된 "솔루션이 될 것"에 대한 이해를 공유하고 있는지 확인하는 데 사용됩니다.

요구 사항 분석은 비즈니스 모델링 프로세스의 일부이며 핵심 초점 영역을 형성합니다. 기능 요구 사항은 "현재 상태"중에 수집됩니다. 이러한 요구 사항은 미래 상태에서 설계 될 원하는 기능을 설명하는 비즈니스 프로세스, 데이터 및 비즈니스 규칙과 관련하여 이해 관계자가 제공합니다.

GAP 분석 수행

비즈니스 요구 사항을 정의한 후 현재 상태 (예 : 현재 비즈니스 프로세스, 비즈니스 기능, 현재 시스템의 기능 및 제공되는 서비스 / 제품 및 시스템이 응답해야하는 이벤트)를 식별하여 사람, 프로세스 및 기술, 구조를 이해해야합니다. 아키텍처는 IT 직원 및 비즈니스 소유자를 포함한 기타 관련 이해 관계자의 의견을 구함으로써 비즈니스를 지원하고 있습니다.

그런 다음 식별 된 현재 상태를 원하는 결과와 비교하여 비즈니스 요구 사항을 달성하는 데 방해가되는 간격이 있는지 평가하기 위해 간격 분석을 수행합니다.

차이가없는 경우 (즉, 현재 상태가 비즈니스 요구 사항과 원하는 결과를 충족하기에 적합 함) IT 프로젝트를 시작할 필요가 없을 것입니다. 그렇지 않으면 격차를 해소하기 위해 해결해야하는 문제 / 문제를 식별해야합니다.

SWOT (강점, 약점, 기회 및 위협) 분석 및 문서 분석과 같은 기술을 사용할 수 있습니다.

제안 된 시스템을 평가하려면

BA는 IT 프로젝트 팀이 제안 된 IT 시스템을 평가하여 비즈니스 요구 사항을 충족하고 이해 관계자에게 제공되는 가치를 극대화하도록 지원해야합니다. BA는 또한 원활한 시스템 구현을 보장하기 위해 제안 된 IT 시스템으로의 전환을 지원하기위한 조직의 준비 상태를 검토해야합니다.

BA should help the IT project team to determine whether the proposed system option and the high-level system design could meet the business needs and deliver enough business value to justify the investment. If there are more than one system options, BA should work with the IT staff to help to identify the pros and cons of each option and select the option that delivers the greatest business value.

Guiding Principles for Business Modelling

The primary role of business modelling is mostly during inception stage and elaboration stages of project and it fades during the construction and transitioning stage. It is mostly to do with analytical aspects of business combined with technical mapping of the application or software solution.

• Domain and User variation − Developing a business model will frequently reveal areas of disagreement or confusion between stakeholders. The Business Analyst will need to document the following variations in the as-is model.

• Multiple work units perform the same function − Document the variances in the AS-IS model. This may be different divisions or geographies.

• Multiples users perform the same work − Different stakeholders may do similar work differently. The variation may be the result of different skill sets and approaches of different business units or the result of differing needs of external stakeholders serviced by the enterprise. Document the variances in the AS-IS model.

• Resolution Mechanism − The Business Analyst should document whether the ToBe solution will accommodate the inconsistencies in the current business model or whether the solution will require standardization. Stakeholders need to determine which approach to follow. The To-Be model will reflect their decision.

Example of BA role in Modelling ERP Systems

A Business analyst is supposed to define a standard business process and set up into an ERP system which is of key importance for efficient implementation. It is also the duty of a BA to define the language of the developers in understandable language before the implementation and then, utilize best practices and map them based on the system capabilities.

A requirement to the system is the GAAP fit analysis, which has to balance between −

• The need for the technical changes, which are the enhancements in order to achieve identity with the existing practice.

• Effective changes, which are related to re-engineering of existing business processes to allow for implementation of the standard functionality and application of process models.

Functional Business Analyst

Domain expertise is generally acquired over a period by being in the “business” of doing things. For example,

• A banking associate gains knowledge of various types of accounts that a customer (individual and business) can operate along with detailed business process flow.

• An insurance sales representative can understand the various stages involved in procuring of an Insurance policy.

• A marketing analyst has more chances of understanding the key stakeholders and business processes involved in a Customer Relationship Management system.

• A Business Analyst involved in capital markets project is supposed to have subject matter expertise and strong knowledge of Equities, Fixed Income and Derivatives. Also, he is expected to have handled back office, front office, practical exposure in applying risk management models.

• A Healthcare Business Analyst is required to have basic understanding of US Healthcare Financial and Utilization metrics, Technical experience and understanding of EDI 837/835/834, HIPAA guidelines, ICD codification – 9/10 and CPT codes, LOINC, SNOMED knowledge.

Some business analysts acquire domain knowledge by testing business applications and working with the business users. They create a conducive learning environment though their interpersonal and analytical skills. In some cases, they supplement their domain knowledge with a few domain certifications offered by AICPCU/IIA and LOMA in the field of Insurance and financial services. There are other institutes that offer certification in other domains.

Other Major Activities

Following a thorough examination of current business processes, you can offer highly professional assistance in identifying the optimal approach of modelling the system.

• Organizing the preparation of a formalized and uniform description of business processes in a manner ensuring efficient automation in the system.

• Assistance to your teams in filling out standard questionnaires for the relevant system as may be furnished by the developers.

• Participation in working meetings requirements towards the developers are defined.

• Check and control as to whether the requirements set by you have been properly “reproduced” and recorded in the documents describing the future model in the system (Blueprints).

• Preparation of data and assisting for prototyping the system.

• Assistance in preparation of data for migration of lists and balances in the format required by the system.

• Review of the set-up prototype for compliance with the requirements defined by the business process owners.

• Acting as a support resource to your IT teams in preparing data and actual performance of functional and integration tests in the system.

In the next section, we will discuss briefly about some of the popular Business Modelling Tools used by large organizations in IT environments.

Tool 1: Microsoft Visio

MS-Visio is a drawing and diagramming software that helps transform concepts into a visual representation. Visio provides you with pre-defined shapes, symbols, backgrounds, and borders. Just drag and drop elements into your diagram to create a professional communication tool.

Step 1 − To open a new Visio drawing, go to the Start Menu and select Programs → Visio.

Step 2 − Move your cursor over “Business Process” and select “Basic Flowchart”.

The following screenshot shows the major sections of MS-Visio application.

Let us now discuss the basic utility of each component −

A − the toolbars across the top of the screen are like other Microsoft programs such as Word and PowerPoint. If you have used these programs before, you may notice a few different functionalities, which we will explore later.

Selecting Help Diagram Gallery is a good way to become familiar with the types of drawings and diagrams that can be created in Visio.

B − The left side of the screen shows the menus specific to the type of diagram you are creating. In this case, we see −

• Arrow Shapes
• Backgrounds
• Basic Flowchart Shapes
• Borders and Titles

C − The center of the screen shows the diagram workspace, which includes the actual diagram page as well as some blank space adjacent to the page.

D − The right side of the screen shows some help functions. Some people may choose to close this window to increase the area for diagram workspace, and re-open the help functions when necessary.

Tool 2: Enterprise Architect

Enterprise architect is a visual modeling and design tool based on UML. The platform supports the design and construction of software systems, modeling business processes and modeling industry based domains. It is used by business and organizations to not only model the architecture of their systems. But to process the implementation of these models across the full application development life cycle.

The intent of Enterprise architect is to determine how an organization can most effectively achieve its current and future objectives.

Enterprise architect has four points of view which are as follows −

• Business perspective − The Business perspective defines the processes and standards by which the business operates on day to day basis.

• Application Perspective − The application perspective defines the interactions among the processes and standards used by the organization.

• Information Perspective − This defines and classifies the raw data like document files, databases, images, presentations and spreadsheets that organization requires in order to efficiency operate.

• Technology Prospective − This defines the hardware, operating systems, programming and networking solutions used by organization.

Tool 3: Rational Requisite Pro

The process of eliciting, documenting organizing tracking and changing Requirements and communicating this information across the project teams to ensure that iterative and unanticipated changes are maintained throughout the project life cycle.

Monitoring status and controlling changes to the requirement baseline. The Primary elements are Change control and Traceability.

Requisite Pro is used for the above activities and project administration purposes, the tool is used for querying and searching, Viewing the discussion that were part of the requirement.

In Requisite Pro, the user can work on the requirement document. The document is a MS-Word file created in Reqpro application and integrated with the project database. Requirements created outside Requisite pro can be imported or copied into the document.

In Requisite Pro, we can also work with traceability, here it is a dependency relationship between two requirements. Traceability is a methodical approach to managing change by linking requirements that are related to each other.

Requisite Pro makes it easy to track changes to a requirement throughout the development cycle, so it is not necessary to review all your documents individually to determine which elements need updating. You can view and manage suspect relationships using a Traceability Matrix or a Traceability Tree view.

Requisite Pro projects enable us to create a project framework in which the project artifacts are organized and managed. In each project the following are included.

• General project information
• Packages
• General document information
• Document types
• Requirement types
• Requirement attributes
• Attribute values
• Cross-project traceability

Requisite Pro allows multiple user to access the same project documents and database simultaneously hence the project security aspect is to very crucial. Security prevents the system use, potential harm, or data loss from unauthorized user access to a project document.

It is recommended that the security is enabled for all RequisitePro projects. Doing so ensures that all changes to the project are associated with the proper username of the Individual who made the change, thereby ensuring that you have a complete audit trail for all changes.