2. 요구사항 및 장표수집

1. 정보 시스템 개발 단계

 기업에서 프로젝트를 준비하는 기간이 대략 1년이라고 가정할때  기간 내에 프로젝트를 완수한 실상은 30%라고 한다. 

 그럼 대부분은 실패 또는 부분실패로 돌아간다는 말인데 그 이유는 무엇인가?

 바로 '사용자의 요구사항'을 제대로 분석하지 못했기 때문이다. 사용자의 요구사항을 제대로 파악하지 못한 채로 정보시스템이 

 개발되다 보니 사용자로부터 외면을 당할 수밖에 없다. 

 해당 챕터에서는 이러한 문제점을 해결하는데 있어서 사용자의 요구사항을 어떻게 잘 수집하고 분석해 갈지에 대해서 

 소개 하고자 한다.

 1. 분석 : 수집된 장표와 인터뷰 자료들을 정리하여 개념적 데이터 모델링 작업 수행 + ERD(Entity Relation diagram)를 생성.

             DFD(Data Flow Diagram)을 통해 프로세스 모델링 작업 수행. + FHD(Function Hierlecy Diagram)을 만듦.

1. 관련문서 수집 

 데이터베이스 구축 준비 단계에서 수행해야할 첫 번째 작업이다. 

 현업에서 사용되고 있는 다양한 자료와 장표를 수집하는 일이다. 또한 수집된 자료들을 바탕으로 잘 정리해서 분석 + 설계작업을 진행한다.

 하나의 시스템이 운영되기 위해서 참조되는 모든 양식, 서식, 실체가 있는 자료, 리스트도 장표가 될 수 있다. 

 → 이 단계에서의 산출물 : 수집장표 목록

2. 사용자 면담

 프로젝트를 진행함에 있어서는 현업 담당자들의 요구사항을 충분히 듣고 수행하는 일이 중요하다. 

 여러 부서의 담당자 및 개발자, 관리자 등과 현업에서 근무하고 있는 매니저들이 함꼐 모여 프로젝트의 방향과, 

 사용자의 요구사항을 들어보는 단계이다. 이 단계에서 사용자가 1.단계에서 수집한 장표들을 전달 받고 장표의 내용을 분석하는 

 작업을 수행하기도 함. 사용자 면담은 프로젝트가 끝날 떄까지 수차례 주기적으로 발생한다. 

 → 이 단계에서의 산출물 :  사용자 요구사항 정의서 

3. 장표분석

 현업 사용자들을 통해 수집된 장표들은 사용자 면담을 통해 구체적으로 분석되고, 이렇게해서 모아진 산출물들을 분석한다. 

 이 단계에서 생성되는 산출물은 데이터베이스를 구축하기 위한 기초 필수 산출물로써 반드시 작성되어야 한다. 중요성이 높음.

 이 산출물을 기반으로 데이터 모델링 + 데이터 아키텍쳐가 구현됨.

 →  이 단계에서의 산출물 : 데이터 항목 일람표

4. 프로세스 분석

 데이터 분석 설계에 있어서 중요한 요소 중 하나가 비즈니스 룰(Business Rule)에 대한 이해와 해석이다. 데이터 모델링을 하기 위해선

 반드시 필요하다. 

 → 이 단계에서의 산출물 : 프로세스 정의서, Data Flow Diagram

5. 사용자 요구사항의 검증

 누란된 장표가 있는지를 검증하는 단계로 CDUR 매트릭스를 작성해보면 알 수 있다. 

1-1 사용자 요구사항 

 사용자 요구사항에는 새롭게 구축될 현 업무에 대한 전반적 내용을 포함하고 있으면서, 

 시스템을 구축할 때 반영하게 될 사용자의 기대와 요구사항이 포함되어있다.

 사용자의 요구사항을 얼마나 잘 이해함에 따라 향후 분석 + 설계의 과정이 달라지기 때문에 매우 중요한 과정이다. 

1-1-2. 장표 수집

 여러가지 많은 장표들을 수집할 것이기에 장표마다 구분이 될 수있는 기호나, 숫자를 매겨서 구분 지어준다.

 예를들어 기업의 재고관리 시스템을 확인한느 장표를 모은다고 한다면 ,사원정보현황 장표가 있어야 할 것이고, 부서정보 현황 장표도 필요할 

 것이다. 또한 재고현황 등등 주제에 맞는 장표들을 수집한다. 

 하나의 기업 내에서 사용되는 장표들 중에는 동일한 이름이지만 내용이 다르거나, 내용도 유사한 장표들도 볼 수 있다. 경험이 부족한  분석, 설계자는 

비슷해 보이는 장표들을 필요없는 장표라고 인식할 수 있고 수집 대상에서 누락시켜 결론적으로는 데이터베이스를 구축 할 수 없게

 되는 경우도 발생하게 될 수 있다. 

1-1-3. 수집장표 목록

위에서 수집한 장표들에 대한 총 목록과 내용에 대한 정보가 기록되며 관계형 데이터베이스 구축을 위한 분석, 설계 단계 뿐아니라 구현 단계에서 물리적 설계를 위한 기초 자료로 활용된다. 구체적이고 상세하게 작성할 것..! 

< 수집 장표 목록 >

장표번호	장표명	장표설명	담당부서	데이터 발생량	참조빈도	보관 년도
#1	사원현황	사원정보	인사팀	200명	수시로
#2	부서현황	부서정보	총무팀	10팀	년 1회
#4	재고현황	현 재고 수량정보	영업팀	200개목록	수시	5년

위와같이 만들 수 있다. 

데이터 발생량이란 해당 장표와 관련된 데이터 발생량 정보를 기록하는 것인데, 

예를 들어 해당 장표가 월 평군 1000건이 발생한다면 데이터 발생량은 월 1000건이라고 기록하면 된다. 

→ 수집 장표 목록에는 분석, 설계자가 장표수집 단계에서 조사 분석한 해당 장표에 대한 상세한 정보를 기록하게 되며 

  구현 단계에서 만들어질 테이블의 크기와 데이터베이스의 물리적 설계를 할 때 기초로 사용된다.

2-1. 장표의 분석

 기초자료(장표 수집 + 사용자 요구사항 수집 정리 한 내용)를 기반으로 현 업무에 대한 프로세스를 명확히하고 장표의 내용을 분석한다. 

  1. 수집 장표 목록을 통해 분석할 장표를 선택한다. 

  2. 위에서 선택한 장표에 표기되어있는 모든 항목들에 순번을 매긴다. 그리고 각 항목에 대한 명확한 이해를 위해 사용자와의 

     인터뷰를 요청하고 질의 + 답변을 상세히 기록한다. 

  3. 데이터 항목 일람표를 작성한다. 

< DATA 항목 일람표 >

번호	Data 항목	항목설명	Data유형	자릿수	필수여부	기타설명
1	사원번호	각 사원에게 부여되는 고유 번호	숫자 형	7자리	필수
2	사용자계정	시스템 접속시 계정	문자 형	8자리	필수	8문자범위내
3	입사일자	시원의 입사일자	숫자	7자리	옵션	YYYY/MM/DD

위와 같이 작성하면 된다. 이렇게 작성하려면, 사용자와 인터뷰시 데이터의 길이, 표시방법, 유형, 등이 어떻게 설정되어 있는지를 인터뷰 해야한다.

2-2. DFD(Data Flow Diagram)

정보시스템을 구축하는 단계에서는 프로세스에 대한 명확한 이해가 필요하다. 이해를 돕기 위해 프로세스에 대한 절차를 도형과 기호로

 체계화 시켜 놓은 산출물이 DHD이다. 

 이 것은 사용자와의 인터뷰를 통해 작성된 요구사항을 통해 만들어지며 작성시 불명확한 프로세스가 발견되면 사용자와의 인터뷰를 통해

 구체적이고 명확하게 기술해야함. 만약 분석, 설계자가 업무에 대해 명확하게 이해하고 있다면 반드시 DFD를 작성할 필요는 없다. 

2-2.1 프로세스 정의서

 전체 업무의 흐름을 절차적으로 작성하고, 사용자 요구사항 보다 더욱 구체적으로 작성한다. 하나의 단락으로 작성하고 복잡해지면 분리한다.

 여기서 하나의 단락이란 테이블로 따지면 칼럼 처럼 여러개의 하위 항목들을 담고 있는 대표 키를 말한다. 

 프로세스 정의서를 작성하는 이유는 얼마만큼 프로세스를 빠르고 쉽게 이해할 수 있도록 작성하느냐가 중요한 핵심이다. 

 프로세스 정의서에는 전체적인 업무 흐름을 절차적으로 작성해야한다. 

2.3 사용자 요구사항의 검증

 사용자 요구사항을 기반으로 작성된 프로세스 정의서에 잘못된 내용은 없는지, 누락되거나 불필요한 항목들이있는건 아닌지 등을 검증하는 

 작업이 필요하다. 

2.3.1 CDUR 매트릭스

 CDUR매트릭스는 누락된 장표와 누락된 데이터 항목, 누락된 프로세스가 존재하는지를 검증할 수 있는 것이다.

 

*사용법 : 

 1. 행과 열로 구성되는 매트릭스에는 '정보항목' 이란 영역이 있다. 앞서 수집된 장표들의 데이터 항목을 순서대로 작성한다.

 2. '기본프로세스 영역'이이 있는데 거기에는 위에서 작성한 프로세스 정의서의 '프로세스 명'들을 작성한다.

     순서는 상관 없고 프로세스 정의서에 작성된 순대로 작성하면 된다.

 3. 상관 분서 결과를 표시한다. 각 항목에 표시할 문자는 C(Create), D(Delete), U(Update), R(Reference) 4가지 문자 중 하나만 표시 가능하다.

    C의 의미 : D, U, R이 포함되어 있다.

    D의 의미 : U, R이 포함되어 있다.

    U의 의미 : R이 포함되어있다.

    R의 의미 : Reference의미 그대로 참조한다는 뜻이다.

 예를들어 한명의 사원이 입사를 하게되면 그 해당 신입 사원에게는 사원번호를 새롭게 부여하게 됨으로 

 '사원번호'라는 데이터 항목은 '사원관리' 프로세스에서 최초 생성이 발생함으로 'C'를 표시한다. 그리고 부서정보 현황의 '부서명'이라는

 데이터 항목은 부서관리 프로세스에서 최초 생성이 발생하고 이 정보를 사원정보 현황의 부서명에서는 참조만 함으로 R을 표시한다. 

*해석법 :

 1. 데이터 항목은 존재하지만, 기본 프로세스(CDUR)가 없는 경우는 해당 데이터 항목이 비즈니스 영업 범위에 포함되지 않거나 

    기본 프로세스 영역에 대한 해석을 잘못한 경우이다.

 2. 분석된 기본 프로세스 영역은 존재하지만 해당되는 데이터 항목이 존재하지 않으느 경우는 , 장표가 누락되었거나 기본 프로세스를 누락한 

    경우이다.

 3. 하나의 데이터 항목이 2개 이상의 기본 프로세스에서 생성되는 경우는 기본 프로세스가 중복되거나 하나의 기본 프로세스를

    2개 이상으로 세분화한 경우이므로 프로세스를 합병해야 한다. 

*특징 :

 1. 도출된 정보 항목을 비교 분석해서 사용자의 요구사항이 효과적으로 반영되었는지를 파악할 수 있다.

 2. 데이터 항목과 분석된 프로세스 영역의 누락 또는 중복된 내용을 확인 할 수 있다. 

 3. 기본 프로세스의 4가지 문자를 활용하여 기본프로세스를 수행하는데 필요한 정보 항목인지를 분석 가능하다.

 4. 복수의 액션이 발생하는 경우에는 C > D > U > R 순으로 표현한다. 

 5. 정보 항목의 생성은 하나의 기본 프로세스에서만 발생할 수 있으며 다른 기본 프로세스는 참조만 하게 된다. 

*