비즈니스 분석가로서 요구 사항을 구성하는 방법

비즈니스 요구사항은 프로젝트 또는 제품에 대한 이해관계자의 요구사항을 담은 공식 문서입니다. 비즈니스 요구사항을 작성하는 데 있어 단일한 표준 형식은 없지만, 모든 버전은 제품 또는 프로젝트에 대해 충분히 상세하게 기술하여 논의, 분석, 문서화 및 검증이 가능하도록 해야 합니다.

비즈니스 요구 사항은 다음 중 어떤 방법으로든 제시될 수 있습니다.

• 테이블 또는 스프레드시트
• 다이어그램(워크플로)
• 그래프
• 모델(엔티티-관계 다이어그램)
• 프로토타입 또는 시뮬레이션
• 구조화된 문장 또는 텍스트 템플릿

비즈니스 요구 사항을 구성하고 제시하는 방법

다음은 요구사항을 작성하고 정리하는 단계입니다. 비즈니스 분석가.

단계 1) 요구사항을 분류하세요.

• 각 요구사항을 해당되는 범주에 배치하십시오.
• 기술 관련 이해관계자는 기술 요구사항 범주를, 비기술 관련 이해관계자는 비즈니스 또는 일반 요구사항 범주를 볼 수 있어야 합니다.
• 각 조직은 자체 기준에 맞는 범주를 결정해야 합니다.
• 요구사항 유형(기능적 요구사항 대 비즈니스 요구사항)을 기준으로 분류할 수도 있지만, 이러한 구분이 모든 프로젝트에 적합한 것은 아닙니다.

단계 2) 요구사항을 정리합니다.
이해관계자들이 문서를 쉽게 탐색하고 누락된 항목을 찾을 수 있도록 요구사항을 논리적인 순서로 수집하고 정리하십시오.

단계 3) 목록을 준비하세요.
승인이 필요한 이해관계자별로 요구사항 목록을 그룹화하여 검토하십시오.

예를 들어, 기술적 배경을 가진 이해관계자는 제품의 기술적 측면에만 관심을 가질 것입니다.

단계 4) 고유 식별자를 사용하세요.
If trac서로 다른 요구사항을 일치시키는 것은 어렵기 때문에 고유 식별자를 사용하여 일치시키십시오. trac더 쉽게 사용할 수 있습니다.

단계 5) 이해관계자가 선호하는 방식으로 요구사항을 제시하십시오.
이해관계자에 따라 동일한 요구사항을 서로 다른 형식으로 제시해야 할 수도 있습니다. 어떤 이해관계자는 그래픽 표현을 선호하는 반면, 다른 이해관계자는 구조화된 문장을 선호할 수 있습니다.

단계 6) 목차를 준비합니다.
모든 요구사항에 대한 목차를 만드세요. 이는 이해관계자들에게 도움이 됩니다. track를 입력하고 빠르게 찾아내세요.

단계 7) 비즈니스 분석 도구를 사용하세요.
비즈니스 분석 도구 이는 여러 릴리스에 걸쳐 요구 사항을 일관되게 제시하고 분류하는 데 도움이 됩니다.

단계 8) 프로세스 흐름에 따라 요구사항 문서를 구성합니다.
문서에서 불필요한 요구사항을 제거하고, 남은 요구사항들을 지원하는 프로세스 흐름에 따라 정리하십시오.

단계 9) 요구 사항을 매핑합니다.
수집한 각 요구사항을 프로세스 흐름의 특정 단계에 연결하여 검토자가 요구사항과 해당 요구사항이 지원하는 워크플로를 연결할 수 있도록 하세요.

단계 10) 표와 글머리 기호를 사용하세요.
복잡한 요구사항은 표를 사용하여 제시하고, 각 요구사항의 핵심 사항은 글머리 기호를 사용하여 강조하십시오.

비즈니스 요구사항 문서를 작성하고 발표할 때 유용한 팁

더 나은 표현을 위해 trac비즈니스 요구사항의 핵심인 비즈니스 분석가(BA)에게 다음 팁은 매우 유용합니다.

• 요구사항을 분류하는 것은 시간이 많이 소요되므로, 매번 새로운 분류 체계를 만드는 대신 비즈니스 분석가, 이해관계자, 전문가 및 기술 팀이 프로젝트 전반에 걸쳐 재사용할 수 있는 표준 분류 체계를 정의하십시오.
• 요구사항을 작성할 때는 대상 고객을 고려해야 합니다. 주요 관계자, 영향력 행사자, 의사 결정권자(이해관계자, 기술 담당자, 개발자 등)를 파악하십시오.
• 한 번에 하나의 요구 사항을 정의합니다. 각 요구 사항은 원자적이어야 합니다.
• 모호함을 피하십시오. 요구사항 명세서에서 "기타" 또는 "대략"과 같은 애매한 한정어를 사용하지 마십시오.
• 아직 정의되지 않은 요구사항을 참조하지 마십시오.
• 문서에서 중복되거나 모순되는 내용을 제거하십시오.
• 복잡한 요구사항을 더 작고 관리하기 쉽고 검토하기 쉬운 항목으로 나누세요.
• 설명 뭐 시스템이 알아서 할 겁니다. 방법 그렇게 될 겁니다. 구현은 설계 단계에서 이루어져야 합니다.

비즈니스 요구사항을 시각화하는 데 널리 사용되는 기법

장황한 설명은 이해관계자를 잃는 가장 빠른 방법입니다. 비즈니스 분석가는 모든 텍스트 기반 요구사항에 시각적 자료를 함께 제시하여 의도를 한눈에 명확히 전달합니다. 다음 기법들은 BABOK 가이드와 대부분의 기업 비즈니스 분석 실무에서 찾아볼 수 있습니다.

• 비즈니스 프로세스 모델 및 표기법(BPMN): 풀, 레인, 게이트웨이 및 이벤트를 사용하여 비즈니스 프로세스의 전체 과정을 다이어그램으로 나타냅니다. BPMN은 누가 무엇을 언제 하는지 보여주는 데 이상적입니다.
• 유스케이스 다이어그램 및 Descript이온 : 액터와 시스템 간의 상호작용 및 각 액터가 기대하는 결과를 포착합니다. 기능 중심의 백로그에 적합합니다.
• 승인 기준이 포함된 사용자 스토리: "…로서, 나는 …을 원한다. 그래서 …을 얻을 수 있다."와 같은 간결한 문장과 "주어진 조건-결과 조건"이 결합된 형식입니다. 애자일 팀에서 기본적으로 사용되는 형식입니다.
• 와이어프레임 및 목업: 저해상도 또는 중간 해상도의 스크린이 제작되었습니다. Figma, 발사믹, 또는 Axure 기술적인 지식이 없는 이해관계자들도 UI 요구사항을 구체적으로 이해할 수 있도록 해줍니다.
• 엔티티 관계 다이어그램(ERD): 솔루션이 저장해야 하는 데이터 엔티티와 그 엔티티 간의 관계를 보여주세요. 이는 보고 및 통합 요구 사항에 매우 중요합니다.
• 데이터 흐름도(DFD): Trac특히 분석 또는 통합 프로젝트에서 데이터가 프로세스, 저장소 및 외부 주체를 통해 어떻게 이동하는지 살펴봅니다.

대상에 맞는 기법을 사용하세요. 경영진은 프로세스 맵과 여정 다이어그램에, 개발자는 ERD와 사용자 스토리에, 최종 사용자는 와이어프레임과 프로토타입에 반응합니다.

비즈니스 요구사항 문서를 정리하는 데 사용되는 일반적인 도구

요구사항 수가 수십 개를 넘어서면 Word 문서로는 더 이상 확장이 불가능해집니다. 비즈니스 분석가들은 기준선 설정, 검토, trac안정성 및 변경 관리. 다음은 업계 전반에서 가장 널리 사용되는 방법입니다.

• Jira와 Confluence 연동: 애자일 팀의 기본 조합입니다. 요구사항은 Jira에서 에픽과 스토리로 관리되며, Confluence 페이지에는 BRD(비즈니스 요구사항 문서)의 설명과 다이어그램이 저장됩니다.
• 자마 커넥트: 요구사항 관리, 기준선 설정 및 실시간 운영에 초점을 맞춘 엔터프라이즈 플랫폼 trac의료기기 및 항공우주와 같은 규제 산업에 대한 적합성.
• IBM Engineering Requirements 경영진의 문: 국방, 자동차 및 안전 필수 시스템에서 오랫동안 사용되어 온 도구로, 모든 요구 사항을 충족해야 합니다. trac가능함.
• Modern Requirements 을 통한 Azure DevOps : 연장하다 Azure DevOps 환경에서 작업 항목에서 직접 검토, 승인, 기준선 설정 및 Word 형식의 BRD 내보내기 기능을 제공합니다.
• Miro or Lucidchart: 화이트보드 및 다이어그램 도구를 사용하여 BPMN, ERD, 사용자 여정 및 워크숍 메모를 작성하고, 이를 바탕으로 공식적인 BRD를 작성합니다.
• 발사믹과 Figma: 텍스트 대신 시각적인 방식으로 UI 요구사항을 정리할 수 있는 와이어프레임 및 프로토타입 도구.

프로젝트 규모와 감사 요구 사항에 맞는 도구 세트를 선택하세요. 소규모 프로젝트는 Confluence와 Jira로 시작할 수 있지만, 규제 대상 프로그램은 일반적으로 Jama 또는 DOORS를 사용해야 합니다. trac능력 평가.

비즈니스 요구사항을 제시할 때 흔히 저지르는 실수

아무리 철저하게 조사된 요구사항이라도 제대로 제시되지 않으면 거부될 수 있습니다. 다음은 대부분의 비즈니스 분석 사후 검토에서 공통적으로 나타나는 실수들이므로 검토 시 주의해야 합니다.

• 무엇을 어떻게 섞을까: 슬립ping 요구사항 명세서에 구현 세부 사항이 포함되면 분석이 완료되기 전에 설계 팀이 특정 솔루션에 갇히게 됩니다.
• 모호한 표현: "빠르다", "사용자 친화적이다", "유연하다"와 같은 단어는 검증할 수 없습니다. 이러한 단어 대신 측정 가능한 수용 기준을 사용하세요.
• 모든 이해관계자를 위한 단일 형식: 경영진, 개발자, 최종 사용자에게 똑같은 관점을 제시하면 대개 누구도 만족시키지 못합니다. 청중에 맞춰 형식을 조정하세요.
• 누락 trac능력: 비즈니스 목표, 설계 요소 및 테스트 케이스와 연관되지 않은 요구 사항은 변경 요청이 접수될 때 정당화될 수 없습니다.
• 우선순위 없음: MoSCoW 기법, 가중치 점수 매기기 또는 이와 유사한 틀 없이 수백 가지 요구사항을 제시하면 이해관계자들은 가치보다는 범위에 대해 논쟁하게 됩니다.
• 과부하된 문서: 모든 도표, 로그, 근거를 200페이지짜리 PDF 파일 하나에 crammed 넣으면 중요한 요구사항이 가려집니다. BRD를 논리적인 섹션으로 나누고 명확한 목차를 포함하세요.
• 건너뛰기ping 마무리 인사: 공식적인 승인 절차 없이 BRD를 제시하면 나중에 범위가 확대되거나 담당자 간에 책임 전가가 발생할 가능성이 있습니다.

Rev모든 이해관계자 회의 전에 BRD를 이 목록과 대조해 보면, 이후 단계에서 재작업을 야기하는 대부분의 문제를 파악할 수 있습니다.

자주 묻는 질문