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

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

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

프로젝트가 실패하는 이유

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

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

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

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

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

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

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

기초부터 시작합시다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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