#title 업무 요구사항 규정 [[TableOfContents]] ==== 장의 목표 ==== * 데이터 웨어하우스에 대한 요구사항을 규정하는 것이 어떻게 왜 다른지를 논의한다. * 업무 차원의 역할을 이해한다. * 정보 패키지와 요구사항 규정에서의 그 용도를 배운다. * 요구사항 수집하는 방법을 검토한다. * 공식적인 요구사항 정의 문서의 중요성을 파악한다. 데이터 웨어하우스는 정보 전달 시스템이다. 기술에 관한 것도 아니라, 사용자의 문제들을 해결하고 사용자에게 전략 정보를 제공하는 것이다. 정보를 제공하는 방법에는 집중할 필요가 없다. 패러다임도 바꾸어야 한다. 데이터 획득 모델에서 정보 전달 모델로 전환되어야 한다. ==== 차원 분석 ==== DW 시스템은 OLTP 시스템과는 다른 방법으로 요구사항을 수집해야 한다. 다음 그 차이점이다. ||'''DW System'''||'''OLTP System'''|| ||정보전달 시스템||데이터획득 시스템|| ||의사결정지원시스템||운영상의 업무요구사항 수집|| ||요구사항들을 수집할 때 정보가 무엇인지에 집중||일일 업무 운영 시스템|| ===== 예측할 수 없는 정보의 사용법 ===== OLTP의 경우 정보의 사용법이 예측될 수 있다. 하지만 데이터 웨어하우스는 사용자들의 요구사항을 명확히 규정할 수 없다. 그들은 데이터 웨어하우스로부터 정말로 원하는 정보가 무엇인지 정밀하게 규정할 수 없고, 그들은 정보를 사용거나 처리하는 방법을 표현해 낼 수 없다. ===== 업무 데이터의 차원 성질 ===== * 그들은 어떤 측정 단위가 중요한가? * 어떤 것이 그들을 성공의 정도를 나타내게 해주는가? 예를 들면, 다음과 같다. * 마케팅 부사장의 업무 차원 * 새로운 제품에 의해 산출되는 수익에 관심 * 월별, 특정 지역에, 인구통계에 의한, 판매 영업소에 의한, 이전 상품 버전에 상대적인, 그리고 계획과 비교한 수익 숫자들에 관심 * 월, 구역(division), 고객 인구통계, 판매 영업소, 제품 버전, 그리고 계획에 의해 따로 분석된 수익 숫자를 원한다. * 마케팅 관리자를 위한 업무 차원들 *제품, 제품 종류, 시간(일, 주, 월), 판매 구역, 그리고 유통 채널. * 재정 관리자를 위한 업무 차원들 * 예산 라인, 시간(월, 분기, 년), 지역(district), 그리고 구역(division). attachment:업무요구사항규정/dim_of_biz.JPG ==== 정보패키지 - 새로운 개념 ==== 정보패키지는 요구사항을 모으는 과정에서 표현되는 여러가지 통찰, 모호한 사고, 그리고 의견들에 대하여 구체적인 형식을 주는데 도움이 된다. 정보패키지는 데이터 웨어하우스의 개발을 다음 단계로 나아가게 하는 데 매우 용하다. attachment:업무요구사항규정/info_pkg.jpg 정보패키지는 다음을 가능하게 해줄 것이다. * 공통 주제 영역들을 규정짓는다 * 주요 업무 측적 규준들을 설계한다 * 데이터가 어떻게 제출되어야 하는지 결정한다 * 사용자 분석이나 질의를 위한 데이터 양을 정한다 * 데이터가 어떻게 접근될지 정한다 * 데이터 구체화정도를 수립한다 * 데이터 웨어하우스 크기를 예상한다 * 데이터 재생을 위한 횟수를 결정한다 * 어떻게 정보가 패키지로 되어져야 하는지를 확인한다 ==== 요구사항을 수집하는 방법 ==== 먼저 데이터 웨어하우스를 사용하는 사람들이 누구인가 아는 것이 중요하다. 다음은 대강의 리스트다. * 고위 임원들(후원자 포함) - 임원들은 방향과 범위의 느낌을 줄 것이다. 그들은 관심이 집중된 영역에 밀접히 관련된 사람들 * 주요 부서 관리자 - 관심 영역에서 임원들에게 보고하는 사람들 * 업무 분석가 - 임원과 관리자를 위하여 보고서와 분석을 준비하는 사람들 * DBA - 데이터 소스에 관현 정보를 주는 사람들 * 위 사람들에 의해 지명 추천된 다른 사람들 수집되어야 요구사항들 * 데이터 요소: 사실 클래스, 차원 * 시간에 관한 데이터의 기록 * 소스 시스템들로부터 데이터 추출 * 업무규칙: 속성, 범위, 도메인, 운영레코드 접근방법 * 인터뷰 * 예정하기 쉽다 * 상사함이 뒤얽힐 때 좋은 접근법 * 어떤 사용자들은 1:1 인터뷰에서만 편안하다 * 효과적이기 위해 유효한 준비가 필요하다 * 항상 사전 인터뷰 조사를 이행한다 * 또한 사용자들에게 인터뷰를 준비하게끔 장려한다. * JAD(그룹세션) * 한번에 20명 또는 더 작은 사람들의 그룹 * 요구사항의 핵심적인 이해를 얻은 후에만 사용 * 초기 데이터 수집에는 좋지 않다 * 요구사항을 확인하는데 유용하다 * 아주 잘 조직화되어야 된다는 거이 요구된다. ===== 인터뷰 기법 ===== 인터뷰 세션이 프로젝트 시간의 유효한 비율을 다 써버릴 수 있다. 그러므로 인터뷰 일정은 잘 조직되고 관리되어져야 한다. 다음은 인터뷰 전 완비되어야 하는 작업들이다. (인터뷰 준비사항) * 프로젝트 팀 일원들이 인터뷰하도록 선발하고 교육 * 각 팀 일원에게 상세한 역할 부여(인터뷰를 이끈다/필기한다) * 인터뷰 대상자들의 리스트를 준비하고 대체적인 일정 준비 * 인터뷰들의 각 세트로부터 당신의 예상되는 일들을 열거 * 사전 인터뷰 조사를 완비 * 인터뷰 질문서를 준비 * 인터뷰를 위하여 사용자들에게 준비 * 인터뷰해야 될 모든 사용자들의 첫 번째 모임을 인도 인터뷰로부터 기대되는 것들 * 고위 임원들 * 조직의 목표 * 성공의 측정단위 * 문제 식별 * 비전과 조직이 가야할 길 * DW의 사용성 예상 * 부서 관리자/업무 분석가 * 부서의 목표 * 성공 지표 * 성공을 제한하는 요인 * Key Business Issues * 제품 & 서비스 * 분석을 위한 유용한 업무 차원 * DW의 사용성 예상 * IT 부서/전문가 * 핵심 운영 소스 시스템 * 현재 정보 전달 프로세스 * 분석하는 절차의 유형 * 알고있는 품질 이슈 * 정보 요청들의 현재 IT지원 * 제안된 DW에 대한 관계 주요 조사 토픽 * 사업 단위의 역사와 현재 구조 * 사원들의 수와 그들의 역할들 그리고 책무들 * 사용자들의 위치 * 기업에서 사업 단위의 주요 목적 * 기업의 전략적 주도에 대한 사업 단위의 관계성 * 사업 단위의 부차적인 목적 * 다른 단위들과 바깥 조직들에 대한 사업 단위의 관계성 * 회사 수익과 비용에 대한 사업 단위의 기여도 * 회사의 시장 * 시장에서 경쟁 ===== 질문 유형 ===== 현재 정보 소스 * 어떤 운영 시스템들이 중요한 사업 주제 영역들에 관한 데이터를 산출하는가? * 이런 주제 영역들을 지원하는 컴퓨터 시스템들의 유형들은 무엇인가? * 어떤 정보가 현존하는 보고서들과 온라인 질의들로 현재 전달되는가? * 현존하는 정보 전달 시스템에서 상세함의 수준에 대해서는 어떤가? 주제 영역 * 어떤 주제 영역들이 분석을 위해 가장 가치가 있는가? * 업무 차원들이란 무엇인가? 이것들은 자연적인 계층들을 가지는가? * 의사 결정을 위한 사업 분할이란 무엇인가? * 여러 다양한 지역들이 의사 결정을 위해 세계적인 정보 또는 단지 지역적인 정보를 요구하는가?  무엇이 그 혼합인가? * 어떤 일정한 제품들과 서비스들이 어떤 일정한 영역들에서만 제공되는가? 주요 성과 측정규준 * 현재 측정되고 있는 사업 단위의 성과는 무엇인가? * 결정적인 성공 요인들은 무엇이고 이것들을 어떻게 추적하는가? * 어떻게 중요한 측정규준들을 더욱 강조할 것인가? * 모든 시장들을 같은 방법으로 측정할 것인가? 정보 도수 * 의사 결정을 위해 얼마나 자주 데이터를 경신시켜야만 하는가? 시간 프레임은 무엇인가? * 분석의 각 형태는 시간상으로 어떻게 측정규준들을 비교하는가? * 데이터 웨어하우스에서 정보에 관한 적시의 요구사항은 무엇인가? 인터뷰 내용 * 사용자 프로파일 * 배경과 목표 * 정보 요구사항 * 분석적인 요구사항 * 현재 사용되는 도구 * 성공 기준 * 유용한 사업 측정 규준 * 관련된 업무 차원 ===== JAD 방법론을 적응시킴 ===== JAD는 사용자와의 합동 과정이다. 이는 잘 정의된 목적을 위해 협력해야 되는 관계있는 모든 그룹들과 함께한다. JAD는 5단계 접근법으로 구성된다. 1. 프로젝트 정의 * 높은 수준의 인터뷰들을 완성한다. * 관리 인터뷰들을 집행한다. * 관리 정의 안내를 준비한다. 2. 조사 * 사업 영역과 시스템들과 친밀해진다 * 사용자 정보 요구사항을 문서로 작성한다 * 업무 프로세스들을 문서로 작성한다 * 예비 정보를 수집한다 * 세션을 위해 안건을 준비한다 3. 준비 * 이전 단계로부터 작업 문서를 만든다 * 서기를 훈련한다 * 시각적인 보조도구들을 준비한다 * 사전회의 모임을 집행한다 * 세션 개최지를 마련한다 * 목표들에 대한 점검표를 준비한다 4. JAD 세션 * 안건과 목적의 검토부터 시작한다 * 가정들을 검토한다 * 데이터 요구사항을 검토한다 * 사업 측정규준들과 차원들을 검토한다 * 모든 공개된 이슈들을 해결한다 * 행동 항목들의 리스트들로 세션을 마친다 5. 최종문서 * 작업 문서를 변환한다 * 수집된 정보를 매핑한다 * 모든 데이터 소스들을 목록으로 만든다 * 모든 사업 측정규준들을 확인한다 * 모든 업무 차원들과 계층들을 목록으로 만든다 * 문서를 짜 맞추고 편집한다 * 검토 회의를 집행한다 * 최종 승인을 얻는다 * 요구사항을 바꾸는 과정을 제정한다 JAD팀의 역할과 인원배정 * 임원급 후원자(Executive sponsor) - 자금 조달을 통제하고, 방향을 지시하고, 그리고 팀 일원들에게 힘을 주는 사람 * 조력자(Facilitator) - JAD 과정을 통하여 팀을 안내하는 사람 * 서기(Scribe) - 모든 결정들을 기록하도록 지명된 사람 * 전임 참여자(Full-time participants) - 데이터 웨어하우스에 관한 결정을 하는 데에 연계된 모든 사람들 * 호출시 참여자(On-call participants) - 프로젝트에 의해 영향을 받는 사람들, 그렇지만 특정 영역에서만 * 옵서버(Observers) - 의사 결정에 참여하지 못하면서 특정 세션에 앉아 있기를 원하는 사람들 ===== 현존하는 문서 분류 시스템의 검토 ===== 사용자 부서로부터 문서 * DW에서 사용될 수 있는 사업 영역들에서 사용자들에 의해 사용된 보고서 및 스크린 조사 * 사업 단위 기능 파악 * 사용자들에 의해 수집되는 정보, 그들이 중요하게 생각하는 정보 수집 * 현재 사용되는 보고서들의 사용처 * 사업 단위 * 업무 프로세스와 관련된 문서, 또는 업무 메뉴얼 * 이러한 문서에서 어떻게 그들의 기능을 수행하는가 면밀히 관찰한다. * 관심을 가지고 있을 가능성이 있는 유형에 대한 정보 수집 IT로부터 문서 * 운용 시스템 DBAs * 모든 자료 구조들, 개개의 데이터 요소들, 속성들, 값 영역들, 그리고 필드들과 자료 구조들 사이의 관계성들을 제공 * 소스 데이터, 소스 플랫폼, 그리고 운영 체제를 완전하게 이해 * IT 응용 전문가들 * 업무 규칙들을 제공 * 데이터 소유권과 데이터 품질을 책임지는 사람을 인지 * 어떻게 데이터가 소스 시스템들에서 수집되고 처리되는지를 배울 것이다. * 소스 시스템들을 구성하는 프로그램과 모듈을 검토 ==== 요구사항 정의: 범위와 내용 ==== Data Sources(최대한 상세한 정보이어야 한다) * 이용할 수 있는 데이터 소스들 * 데이터 소스들 내에 있는 자료 구조들 * 데이터 소스들의 위치 * 운영 체제들, 네트워크, 프로토콜들, 그리고 클라이언트 구조들 * 데이터 추출 과정들 * 이력 데이터의 이용가능성 Data Transformation * 상세한 데이터 변환 규칙을 포함하라. * 소스 데이터의 매핑에 관련된 것 * 측정규준들과 업무 차원들에 관한 데이터가 어디로부터 올 것인지 표시 Data Storage * 상세 데이터와 요약 데이터에 필요한 저장장치의 양에 대한 예비 평가 * 얼마나 많은 이력과 아카이브 데이터가 데이터 웨어하우스에 있어야 될 필요가 있는 지를 예측 Information Delivery * Drill-down analysis * Roll-up analysis * Drill-through analysis * Slicing and dicing analysis * Ad hoc reports Information Package Diagram * DW의 최선의 접근법 * DW를 위한 요구사항을 결정화 * 정보패키지가 완전하고 정확해지는 것을 확인하는데 필요한 대로 많은 시간을 사용 ===== 요구사항 문서의 개요 ===== 1. 서문 1. 프로젝트의 목적과 범위를 기술 1. 광범위하게 걸친 프로젝트 정당성을 포함 1. 다음의 각절에 대한 실행 가능한 요약을 제공 1. 일반적인 요구사항 기술 1. 검토된 소스 시스템 기술 1. 인터뷰 요약들을 포함 1. 어떤 유형의 정보 전달 방법들이 사용자들에 의해 필요한지를 넒게 기술 1. 상세한 요구상 1. 필요한 소스 데이터의 상세함을 포함 1. 데이터 변환과 저장장치 요구사항 목록 포함 1. 사용자들에 의해 필요한 정보 전달 방법들의 유형들을 기술 1. 정보패키지 1. 각 정보패키지에 요구사항을 아주 상세하게 제공 1. 패키지 다이어그램 형태로 포함 1. 다른 요구사항 1. 데이터 추출횟수 1. 데이터 적재 방법 1. 정보가 전달되어야 하는 위치 1. 기타 잡다한 요구사항 기술 1. 사용자 기대 1. 문제점과 기회에 관하여 기대를 진술 1. 사용자들이 데이터 웨어하우스를 사용하기 위하여 어떻게 기대하지는 지를 표시 1. 사용자의 참여와 승인 1. 개발 생명 주기 동안 참여가 예상되는 작업과 활동 목록 1. 일반적인 구현 계획 1. 구현을 위해 고수준의 계획을 제출 ==== Balancing Requirements and Realities ==== attachment:업무요구사항규정/kimball01.jpg Design Tip #125 Balancing Requirements and Realities 으로 온 메일의 내용이다.