DA가이드 2과목 데이터 요건 분석

📚 시리즈: DA가이드

• ① DA가이드 1과목
• ② DA가이드 2과목
• ③ DA가이드 3과목
• ④ DA가이드 4과목-1
• ⑤ DA가이드 4과목-2
• ⑥ DA가이드 5과목
• ⑦ DA가이드 6과목

 

DA 가이드 읽으시기전에

↑ 눌러주세요

 

[ 2과목 ] 데이터 요건 분석

 

2.1 정보 요구 사항 개요

 

(DA가이드 2.1.1) 정보 요구 사항

 

정의

정보 요구 사항이란 사용자가 일상적으로 수행하는 업무의 개선 사항이나 신규 개발 사항으로 시스템을 통해 기능상의 목적을 달성하기 위해 요청하는 내용이다. 이러한 정보 요구 사항들은 현행 시스템 분석, 사용자 요구 사항 수집, 제안 요청서, 사업 수행 계획서 등을 이용하여 수집 가능하다. 사용자의 정보 요구 사항을 정해진 일정과 비용 범위 내에서 사용자가 원하는 시스템으로 개발하기 까지는 많은 어려움이 존재한다.

현실적인 개발 환경에서 프로젝트의 성공을 위해서는 불완전하고 애매모호하게 정의된 정보 요구 사항, 현실성을 배제한 이상적인 정보 요구 사항, 특정 사용자만을 위한 정보 요구 사항들은 프로젝트 초기 단계부터 정확한 요건 분석이 이루어져야 한다. 잘못 분석되고 설계된 정보로 시스템을 개발 한다면 사용자 요구 사항을 만족하지 못하는 시스템이 되고, 이는 사용자가 사용하지 않기 때문에 처음부터 다시 설계하고 개발해야 하는 위험과 추가적인 비용을 지불하게 된다.

Standish Group 조사 결과에 의하면 사용자 정보 요구 사항에 대한 중요성을 확인할 수 있다. 일반적으로 성공했다고 이야기하는 프로젝트와 실패했다고 이야기하는 프로젝트 모두 사용자 정보 요구 사항에 대한 철저한 분석 및 변화 관리가 주요한 요인으로 작용했다. 전체 프로젝트의 29%만이 계획된 예산 내에서 납기를 준수하고, 원하는 기능과 요구 사항을 달성했다. 프로젝트의 18%는 프로젝트 완료 전에 또는 사용자들이 사용해 보기도 전에 취소되는 경우이고, 53%의 프로젝트는 표면상으로는 성공하였으나 내면적인 부분을 살펴보면 납기가 지연되거나 예산이 늘어나거나 기능 및 품질에 문제가 있어 실질적인 성공으로 보기 어렵다.

 

 

[그림 2-1-1]의 3가지 사례를 초래한 각 프로젝트의 원인을 다시 한 번 살펴보면 공통적으로 사용 자의 정보 요구 사항에 대한 중요도를 알 수 있다. 따라서 현업 사용자들이 이야기하는 정보 요구 사 항을 IT 업무 담당자들은 처음부터 철저하게 이해하고, 무슨 내용이며 어떤 기능들을 요구하는지 정 확하게 분석하기 위해 많은 시간과 노력을 집중해야 한다.

 

 

더욱 구체화되고 다양화되는 사용자 정보 요구 사항과 복잡해진 정보시스템의 현행을 정확하게 분석하고 이해할 수 있는 능력이 데이터아키텍처 전문가에게 필요하다.

 

정보 요구 사항 생명주기 모형(Life Cycle)

정보 요구 사항의 생명주기 모형은 [그림 2-1-3]과 같이 정보 요구 사항 수집, 정보 요구 사항 분석 및 정의, 정보 요구 사항 상세화, 정보 요구 사항 검증으로 구성된다. 생명주기 모형을 반복적으로 수행하여 사용자 정보 요구 사항이 정보시스템에 누락 없이 반영되어야 한다.

 

 

 

정보 요구 사항 수집

사용자의 정보 요구 사항을 수집하는 단계로서 사용자 인터뷰, 설문서, 워크숍, 현행 시스템 분석 등을 통해 수집한다.

 

정보 요구 사항 분석 및 정의

사용자로부터 수집된 정보 요구 사항을 정리하고 방법론에서 제시하는 다양한 기법을 이용하여 분석해서 정보 요구 사항을 정의하는 단계이다.

 

정보 요구 사항 상세화

확정된 정보 요구 사항의 개별 사항에 대하여 세밀하게 분석하고 기록하는 단계이다. 향후 사용자의 정보 요구 사항이 정보시스템에 정확하게 반영될 수 있도록 상세하게 작성한다.

 

정보 요구 사항 검증

사용자의 정보 요구 사항을 비즈니스 관점, 조직 관점, 애플리케이션 관점과 상관분석을 통해 누락 없이 반영되었는지를 검증하는 단계이다.

 

정보 요구 사항 유형

사용자의 정보 요구 사항을 유형별로 4가지로 나누어 보면 기능 개선 요건, 성능 개선 요건, 외부 인터페이스 요건, 보안 개선 요건 등으로 구분할 수 있으며, 신규 업무에 대한 추가 및 기존 업무에 대한 개선 사항이 대부분의 요구 사항으로 도출되는 점을 감안할 때 기능 개선 및 성능 개선 요건이 많은 비중을 차지한다. 각각의 종류별 정의, 관리 기준, 관리 방법 측면에서 정리해 보면 [표 3-1-1] 과 같다.

[표 3-1-1] 정보 요구 사항 유형

유형	구분	기대효과
외부 인터페이스 요건	정의	시스템의 모든 입·출력에 관한 요건으로서 대외기관으로부터 수신 및 대외기관으로 송신하는 입출력 방식이 추가 및 변경되었을 경우와 각종 제도 및 기준 등이 변경되었을 경우에 발생하는 요건이다.
	관리기준	중복성	기존에 동일한 형태의 인터페이스가 존재하는지 체크한다.
		표준 준수도	인터페이스와 관련된 국제 표준 및 국가 표준이 존재할 경우, 그에 적합한 형태로 제공해야 한다.
	관리방법	항목 이름, 목적 설명, 입력의 원천 및 출력의 방향, 유효 범위, 시간, 다른 입/출력과의 관계, 데이터 포맷, 최종 메시지 등이 포함되어 관리되어야 한다.
기능 개선 요건	정의	시스템에서 입력을 받아들여 처리하고 출력을 만들어 내는 주요 활동 및 프로세스에 대한 요건이다.
	관리기준	불가변성	기능 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안을 요청해야 한다.
		범용성	많은 사용자가 편리하게 사용할 수 있는 요건을 우선적으로 요청해야 한다.
	관리 방법	입력에 대한 유효 체크, 정확한 처리 순서, 비정상 상태에 대한 반응(오버플로우, 통신 장비, 에러 처리), 매개변수의 기능, 출력과 입력의 관계, 입출력 순서, 입력을 출력으로 변환하는 공식 등이 포함되어 관리되어야 한다.
성능 개선 요건	정의	사용자가 원하는 성능 개선 사항으로는 동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소요 시한 등이 있다.
	관리기준	실현 가능성	해당 성능 개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시되어야 한다.
		측정 가능성	측정이 불가능한 모호한 형태로 요건이 제시되면 안 된다.
	관리방법	각 기관의 서비스 특성을 고려하여 정적, 동적 기준을 마련하고 해당 기준에 맞게 서비스되고 있는지를 모니터링 작업을 통해 항시 관리해야 한다.
보안 개선 요건	정의	중요 데이터에 대한 훼손, 변조, 도난, 유출에 대한 물리적 접근 통제(제한구역, 통제구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건을 말한다.
	관리기준	불가변성	보안 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안을 요청해야 한다.
		실현 가능성	해당 보안 개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시되어야 한다.
	관리방법	가장 먼저 보안 관리가 필요한 정보에 대한 등급 관리가 필요하며, 해당 등급별로 접근 가능한 이용자 등급 관리가 필요하며 접근 방식에 있어서의 접근 통제 기준 및 사용 통제 기준이 제시되어야 한다. 해당 기준에 따라 모니터 작업을 통해 안정적인 서비스가 제공될 수 있도록 관리해야 한다.

 

 

 

(DA가이드 2.1.2) 정보 요구 사항 관리

 

정의 및 관리 목적

정보 요구 사항을 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를 수집하고 분류하여 반영하는 작업 절차를 말한다. 정보 요구 사항을 종합적으로 검토, 확인함으로써 요건에 맞는 정보시스템을 개발하여 사용자의 만족도를 높인다.

정보 요구 사항 관리는 데이터, 애플리케이션, 비즈니스 등의 요구 사항을 전부 포함하는 통합 관리 프로세스를 정립해야 한다.

 

정보 요구 사항 관리 프로세스

업무흐름 프로세스

사용자로부터 정보 요구 사항을 접수하고, 반영 여부를 결정하여 통보하고, 최종적으로 시스템 개 발로 완료되는 전체적인 업무 흐름 프로세스는 [그림 2-1-4]와 같다.

 

 

요구 사항 발송

사용자가 정보시스템을 활용하면서 발생하는 불편 사항이나 신규 개발 사항 등의 요건을 정보 요 구 사항 정의서 양식에 기록하여 정보시스템 담당자에게 발송한다. 정보 요구 사항 정의서는 [그림 2-1-5]와 같이 구성할 수 있다.

 

요구 사항 수렴

사용자로부터 접수한 정보 요구 사항 정의서를 수집하여 규칙에 맞게 정확하게 정의했는지 확인하 고, 해당 요건을 검토할 처리 담당자를 지정하여 이송한다.

 

요구 사항 검토

요청된 정보 요구 사항과 관련된 자료 및 작성 기준, 구성요소, 원칙 등을 확인해서 반영 여부를 판단한다. 반영이 가능한 경우는 개발 물량, 협조 담당자, 관련자 등의 영향도 분석을 한다. 반영이 불가능한 경우는 미반영 사유와 함께 요건을 발송한 담당자에게 재전달하여 결과를 알 수 있게 한다.

 

영향도 분석

요청된 내역을 토대로 신규 개발 및 변경에 따른 영향이 얼마나 되며, 이로 인해 영향을 받는 설계서, 기존 애플리케이션, 데이터베이스 등을 파악해서 영향도 분석을 마무리한다.

 

공식화

영향도 분석 후 관련되는 담당자를 소집하여 의견을 공유하고, 담당자들과의 협의를 통해 반영 유형을 결정한다. 반영 유형은 규모 및 기간, 시급성에 따라 결정되며 처리 방법은 신규 시스템 개발 또는 기존 시스템 변경에 의해 발생한다.

 

반영 작업 계획 수립

영향 분석 결과를 근거로 업무 영역 및 관련 담당자들과의 미팅 후 반영 계획을 수립한다. 작업 일정 계획에는 표준과 설계서 변경, 데이터베이스 및 애플리케이션 수정, 테스트, 이관 등의 작업이 명시되어야 한다.

 

수행 조직 및 수행 업무

사용자 정보 요구 사항을 반영하기 위해 필요한 역할별 담당 업무는 [표 3-1-2]과 같다.

[표 2-1-2] 역할별 담당 업무

역할	담당업무
사용자	- 정보 요구 사항 정의 및 상세화 - 정보 요구 사항 변경 요청 - 정보 요구 사항 반영을 위한 미팅 - 정보 요구 사항 반영 여부 확인 - 미결 사항에 대한 의사결정 실시
담당자	- 사용자 정보 요구 사항 접수 - 사용자 정보 요구사항에 대한 기본적인 검토 - 반영 여부 결정을 위한 사용자와 1차 미팅 - 접수 요건에 대한 처리 방식 및 처리 기한 결정 - 관련 부서별 담당자 수집 및 요건 협의 주도 - 사용자 정보 요구 사항 반영 - 테스트 및 검증 - 사용자 반영 결과 통보
데이터 아키텍처 전문가	- 사용자 정보 요구 사항에 대한 표준/ 데이터베이스/ 애플리케이션 차원에 대한 영향도 분석 및 보고 - 접수된 요구 사항에 대한 표준 준수 여부 체크 - 영향도 분석을 통한 수정 및 변경 계획 수립 - 표준 제시 및 준수 여부 검토

 

 

 

2장. 정보 요구 사항 조사

(DA가이드 2.2.1) 정보 요구 사항 수집

 

정보 요구 사항 수집 형태

 

사용자 정보 요구 사항을 파악하기 위한 방법은 다양하다. 사용자와의 인터뷰를 통한 직접적인 수 집도 가능하지만 현업 사용자가 업무에 대한 기준이나 절차를 알아보기 위해 사용하는 업무 매뉴얼을 통해서도 요구 사항을 도출할 수 있으며, 정보시스템을 사용하기 위한 전산 처리 매뉴얼, 기 존 정보시스템의 산출물 등 다양한 형태의 자료로부터 현행 정보시스템 및 사용자 요구에 대한 정 보를 수집할 수 있다.

 

사용자 정보 요구 사항 수집을 위한 다양한 소스 형태

• 관련 문서 수집
• 사용자 면담을 통한 수집
• 워크샵을 통한 수집
• 현행 업무 처리 매뉴얼을 통한 수집
• 현행 정보시스템 관련 산출물을 통한 수집

 

관련 문서 수집

관련 문서에는 업종에 대한 이해에 도움이 되는 자료, 기업에 대한 전체적인 상황 이해 시 도움이 되는 자료, 사용자가 업무 처리를 위해 참고로 하는 상세한 업무 매뉴얼, 업무 처리시 활용하는 정보 처리 매뉴얼, 정보시스템으로부터 산출되는 보고서 및 각종 장표, 처리 화면 등이 포함되며 본 자료를 수집하고 체계적으로 분석해서 정리함으로써 사용자 정보 요구 사항을 파악한다.

 

 

 

문서수집 목적 구현 시스템의 대상과 범위를 좀더 명확하게 정의하고 기업과 업종에 대해 잘 이해하기 위하여 업종, 경영 전략, 정보시스템 등에 대한 과거 실적 자료 및 향후 계획 등의 자료를 수집한다.

 

문서 수집 자료

정보 요구 사항에 도움이 되는 자료의 종류 중 대표적인 자료는 다음과 같다.

 

  경영 계획에 대한 자료

예) 중장기 경영 전략, 향후 3년에 대한 경영 계획서

 

  정보시스템에 대한 자료

예) 현행 발행 보고서, 전산 처리 의뢰서

 

  과거 수행한 컨설팅 보고서  

 

  전산처리 업무 매뉴얼  

 

  현업부서 업무 자료

예) 실무 교육 자료

 

문서수집 원칙

• 문서는 기존에 보유하고 있는 문서를 변형하지 않고 수집하고, 정보시스템에 대한 자료는 별도의 정리 양식을 이용하여 작성한다.
• 수집된 문서를 바탕으로 경영 및 정보시스템 현황에 대한 요약표를 작성하여 그 내용을 숙지한다.
• 수집된 문서들은 계획 수립 기간, 문서 관리자를 지정하여 운영한다.
• 유형별 문서를 향후 활용을 위하여 문서 분류 방식을 결정한 후에 일정한 장소에 보관한다.
• 수집된 문서는 통상 대외비의 성격이 강하므로 개인별로 보관하는 것을 통제하고 문서 보안 관리에 주의한다.

 

사용자 면담

면담은 분석가가 특정 관점에서의 업무 요건이나 업무 절차를 조사하기 위하여 일반적으로 한 명 (혹은 두 명)의 실무자와 대면하여 질의와 응답을 통해 정보를 수집하는 방법이다. 특히 프로세스와 프로시저에 대한 이해를 얻기 위한 준비 단계 또는 워크숍 진행을 돕기 위한 준비 단계에 유용하다. 실무자와의 개별적인 면담은 워크숍보다 훨씬 융통성이 있으며 진행 측면에 있어서도 유연한 진행이 가능하다. 또한 전체 프로젝트의 범위를 커버하는 측면에 있어서도 면담이 워크숍보다 뛰어나다. 참여자에게 적은 시간을 할당함으로써 일정 수립이 용이하여 누락된 부분이 발견되었을 때 추가적인 면담의 계획 및 준비가 쉽게 이루어질 수 있다.

 

  사용자 면담 진행

사용자로부터 중요한 업무 내용을 수집하며 사용자들로 하여금 시스템 개발에 대한 관심과 신임을 고조시키고, 시스템 개발에 필요한 분야의 전문가와 대화를 통해서 필요한 정보를 수집하기 위해 면담을 진행한다.

 

 

계획 및 준비

가) 면담 주제 선정

·                  면담 주제는 수행 대상 작업과 면담 대상자의 책임 수준에 따라 결정한다. 면담 대상자 및 대상 작업별로 면담 주제에 따라 면담 요지를 작성한다. 면담 요지를 통하여 면담 대상자는 적절한 답변을 미리 준비할 수 있다. 상상에 의한 답변을 최소화할 수 있으며, 면담 시간도 절약할 수 있다.

·                  질문 항목은 면담을 통해 얻고자 하는 것이 무엇인지를 명확히 선정하며, 면담 대상자가 이해하기 쉽고 질문 항목에 따라 자유로운 의사개진을 할 수 있도록 구성한다. 면담 요지는 면담 개시 1주일 전에 미리 면담 대상자에게 배포하여 면담 대상자가 답변 내용이나 관련 자료 등을 미리 준비할 수 있도록 한다.현업 부서용 면담 요지는 다음과 같은 내용을 포함하도록 한다.

·                  면담의 취지, 목적, 수행 방법, 시간 등

·                  프로젝트의 개요: 목표, 범위, 기간, 조직

·                  업무의 향후 수행 방향에 대한 의견

·                  면담 대상자가 소속된 부서의 업무 현황 및 개선 요구 사항

·                  현재 사용하는 정보시스템에 관한 의견

·                  프로젝트에 관한 의견 : 요구 사항, 프로젝트 참여 방안 등

전산 부서용 면담 요지는 다음과 같은 내용을 포함하도록 한다.

·                  면담의 취지, 목적, 수행 방법, 시간 등

·                  프로젝트의 개요 : 목표, 범위, 기간, 조직

·                  기획 분야 현황 및 계획 : 전산 부서 조직 및 인력, 연혁, 계획, 문제점, 과제 등

·                  시스템 분야 현황 및 계획 : 조직 및 인력, 시스템 구성, 네트워크 구성, 시스템 운영 절차, 향후 계획, 문제점 및 과제 등

·                  애플리케이션 분야 현황 및 계획 : 조직 및 인력, 애플리케이션 구성, 데이터베이스 구성, 진행 중인 개발 업무, 개발 및 유지보수 계획, 문제점 및 과제 등

 

나) 면담 진행 팀 구성

각 면담 진행 팀은 2명 이상의 프로젝트팀 구성원으로 구성한다. 한 명은 면담자로서 면담을 주도적으로 진행하고, 다른 한 명은 기록자로서 면담 내용을 대상자가 말한 그대로 상세하게 기록한다. 필요한 경우 관찰자가 면담에 참여할 수도 있다.

 

[표 2-2-1] 면담자별 역할

모델	활용 방안
면담자	- 면담을 진행한다. - 면담의 취지를 설명하고 면담 대상자에게 질문한다.
기록자	- 면담 대상자의 답변 내용을 기록한다. (내용을 요약하지 말고 표현 그대로를 기록해야 한다) - 면담 대상자의 답변 내용을 충분히 이해하고 기록하기 위하여 면담 대상 업무에 대한 사전 지식이 있어야 한다. - 면담 종료 시에 기록 내용 중 주요 사항(수치, 업무 분장 및 책임소재 조직 등에 대한 내용)을 확인한다.
관찰자	- 면담이 수행 의도대로 진행되고 있는가를 관찰한다. - 면담이 주제의 범위를 벗어나는 경우, 주의를 환기시킨다. - 면담자가 놓치는 부분에 대하여 보충 질문을 한다. - 최종적으로 면담의 종료에 대해 판단한다.

면담 진행팀은 면담 대상자에 대한 사전 준비에서 면담 수행, 정리, 분석까지의 작업을 공동으로 수행한다. 면담 진행 요원들이 업무 영역 분석에 대한 면담 경험이 없는 경우에는 실제 면담 수행전에 사전 교육이 필요하다. 이 활동을 통하여 면담자가 찾아야 하는 정보와 면담 대상자를 대하는 방법, 결과를 기록하는 공통 유형 등을 개발하는 데에 도움을 준다.

 

다) 면담 대상자 선정

·                  수행 작업에 따라 면담 대상을 선정한다. 면담 대상자는 업무에 대한 명확한 이해를 가능하게 해줄 수 있는 사람을 선정해야 한다.

·                  적절한 대상을 선택하기 위하여 전체 조직 구성도와 프로젝트 범위를 검토하고, 프로젝트 후원자나 사용자측으로부터 추천을 받는 것이 좋다. 선정된 대상자의 전문 분야와 책임 분야에는 프로젝트의 범위가 포함되어 있어야 한다.

·                  여러 명의 사용자나 조직들이 유사한 업무를 수행하고 있는 경우에는 차이점 파악을 위하여 해당 업무에 대하여 적어도 두 명 이상의 면담 대상자를 선정한다. 동일한 업무를 수행하더라도 정보화에 대한 의견은 다를 수 있기 때문이다.

·                   

라) 면담 일정 수립

·                  면담 실시가 공표되고 프로젝트 후원자의 지원을 얻은 후 선정된 면담 대상자들에게 프로젝트의 목적과 범위를 통보하고 사용 가능한 관련 문서 자료를 요청한다.

·                  면담은 초기 단계에서 일정(전체 일정)이 정해져 있어야 하며, 면담 개시 최소 1주일 전에 면담 대상자별로 세부 일정을 확정한다. 또한 가능하면 하향식(상위 관리자나 경영층으로부터 현장 실무자 순)으로 일정을 수립한다.

·                  면담 시간은 1.5시간(상위 관리자)에서 3시간(실무자)을 초과하지 않도록 하며, 필요시 집단 면담을 수행할 수도 있다. 또한 하루에 3회 이상의 면담은 진행하지 않는다. 세부일정 수립시에는 담당 면담 진행팀도 함께 참여한다.

·                   

마) 면담 준비

·                  면담 수행 전에 모든 이용 가능한 자료를 활용하여 면담 대상자가 담당하는 업무 활동을 검토하는 것이 중요하다. 또한 면담 대상자의 신상명세, 경력, 개인적 성향 등도 파악하고, 면담 대상자의 역할, 기능, 경력 등에 대해서도 알아 두어야 한다.

·                  면담 대상자의 업무에 대한 태도나 해당 업무 종사 기간, 경험 등을 알아 두는 것도 좋다. 면담 시나리오를 준비한다. 면담 시나리오에는 면담 대상자에게 설명할 프로젝트의 목적과 범위, 면담자 소개, 면담 진행 요령, 면담 종료시 수칙 등을 미리 작성하여 실제 면담 진행시 활용할 수 있도록 한다. 이 면담 시나리오는 면담 대상자에게 배포하지는 않는다.

·                  도표를 이용할 경우 면담의 효율성을 높일 수 있다. 면담 수행 전에 상세한 면담 주제목록을 중간 관리자와 실무 관리자에게 배포하여 면담 진행자들을 미리 소개하고, 사용 가능한 관련 문서 자료도 함께 요청한다. 면담 진행순서를 준비한다. 이는 면담 규모와는 상관없이 필수적이다.

·                  면담 수행 직전 30분 동안에는 수행될 면담에 관한 최종 준비 상황을 확인한다. 면담 장소는 별도의 프로젝트 면담 장소와 같이 업무나 기타 요인으로부터의 방해를 피할 수 있는 장소가 좋다.

 

 

면담

면담은 면담 시작과 면담 주제 토의로 구성된다.

 

가) 면담 시작

• 면담 시작 30분 전에 다른 면담 진행팀과 함께 필요한 정보 요구와 진행 순서를 점검하고, 면담 진행팀원들 각자의 역할을 확인한다.
• 면담은 정시에 시작하도록 한다. 면담이 시작되면 면담자는 면담 대상자에게 면담 진행팀을 소개하고, 프로젝트의 목적, 범위, 일정 등을 먼저 설명한 후 면담의 목적과 주요 질문 및 진행 방식, 예정 시간, 면담 진행팀원들의 역할을 설명한다. 또한 질문에 대하여 현상, 계획, 바람직한 상황 등을 구분하여 대답해 줄 것을 당부하고, 필요한 경우 면담 주제나 질문사항을 수정한다.
• 면담은 복수의 팀에서 수행될 수 있으므로 면담 진행팀들 간의 수행 방식을 통일하기 위하여 모든 절차가 면담 지침에 세세한 문구까지 모두 반영되어 있어야 한다.

  나) 면담 주제 토의

• 면담자는 준비된 면담 요지에 따라 면담을 진행하고 면담 내용은 모두 면담 기록지에 기록한다.
• 질문 시에는 개방적 질문을 사용하며 면담 주제나 질문지의 순서와 범위를 벗어나지 않도록 노력하고 대화의 흐름이 끊기지 않도록 주의한다.
• 기록자는 토의된 내용을 가능한 한 모두 기록한다. 추가적인 내용의 기록을 위하여 충분한 여백을 두고 논의한 말을 그대로 기록한다. 토의된 내용이 여담일지라도 중요한 정보일 경우가 있으므로 반드시 기록한다.
• 모든 면담 결과의 후속 분석 작업을 위한 공통의 기준으로 사용될 수 있는 표준 기록 양식이 있어야 한다. 면담에서 제기되는 이슈는 면담자와 기록자 모두 기록한다.
• 토의가 진행되는 동안 면담 대상자의 주요 책임 업무를 명확히 정의하고 면담 대상자의 각 업무가 시간과 같은 논리적인 순서에 따라 진행되는지를 확인한다.

 

 

면담 결과 분석

잘 정리된 면담 결과 모음은 후속 업무 분석 작업의 수행에 중요한 기반이 된다. 따라서 결과를 정리할 때에는 간결하면서도 수집된 정보를 빠뜨리지 않도록 주의하여 작성한다.

• 면담 진행팀은 기록된 내용과 면담 중의 응답에 대한 개인적 의견을 고려하여 면담 결과를 정리 한다. 면담 결과의 정리는 면담이 종료된 직후 면담 진행팀 전원이 참석하여 주요 이슈를 정리하는 것이 바람직하다.
• 기존의 업무 모델을 틀로서 사용할 수 있으나 현재 업무와의 사이에 발생하는 차이점에 주의하고, 가능하면 면담 대상자의 업무 용어를 사용한다. 분석 결과의 정리를 위한 별도의 양식은 정해져 있지 않으나 면담 대상자가 수행하는 업무 활동과 각 업무 활동의 수행 목적, 생성 정보, 필요 정보 등을 구분하여 정리하는 것이 좋다.
• 의문 사항이나 추가 사항이 있으면 즉시 면담 대상자에게 확인을 하고, 필요한 경우에 추가 면담을 실시할 수도 있다. 분석된 면담?간을 할애하여 프로젝트 팀원이 상세하게 분석하도록 한다.

 

 

분석 결과 피드백

분석, 정리한 면담 내용에 대하여 면담 대상자로부터 확인을 받는다.

• 별도의 정리 내용이 없거나, 필요한 경우 면담 기록지 내용 전체에 대하여 확인을 받을 수도 있다. 간혹 면담 대상자가 면담 결과에 대하여 상반된 의견을 제시하는 경우가 있으므로 본인에게 승인을 받는 것은 매우 중요하다.
• 또한 이 과정에서 면담 대상자는 정리된 내용에 대한 수정 사항을 제시할 수도 있다. 기록 내용에 대해서는 면담 대상자의 의견을 기입해 두는 것이 좋다.
• 일정상 개인별로 결과에 대한 피드백이 곤란한 경우에는 현업실무자 전원을 대상으로 워크숍을 진행할 수도 있다. 이 경우에는 부서 간의 이해관계에 따라 이견이 발생할 수도 있으므로, 민감한 사안에 대해서는 사전 조정 작업이 필요하다.

면담 수행시 고려 사항

 

  면담 시간 준수

면담 시간이 초과되지 않도록 하며 면담 시작 전에 예상 시간을 확인하고, 면담 종료 10분 전에 얼마나 많은 내용을 진행했는지 확인하고, 추가적인 시간이 요구되는 경우 향후의 추가 면담 일정을 문의한다.

 

  비밀보장

일반적으로 계획 단계나 분석 단계의 면담에서는 업무에 관한 기밀사항이 없다. 그러나 면담 대상자가 원하는 사항에 대해서는 비밀보장을 약속한다. 면담을 시작할 때 면담 대상자에게 외부에 누출되거나 특정인에게 알려지면 안 되는 사항들을 지적해 줄 것을 요청한다.  기대수준 설정

어떤 면담 대상자는 현재 프로젝트가 종료되면 새로운 정보시스템이 개발되는 것처럼 생각하는 경우도 있다. 현재 프로젝트의 관심은 기존의 요구 또는 잠재적인 요구의 파악에 있으며, 시스템의 설계는 후속적으로 이루어질 것이라는 것을 주지시킨다.

 

   면담 범위 준수

면담 진행 중에 면담 대상자의 업무 범위 밖의 안건을 토의할 수도 있다. 토의가 다른 업무 범위를 다룰 경우에는 면담 주제로 돌아가기에 앞서 토의 사항을 명확히 한 후 향후 해당 업무 부서와의 면담시에 확인하도록 한다.

 

  적절한 대상자 선정

때때로 면담 진행 중에 면담 대상자가 잘못 선정되었다고 판단될 경우가 있다(해당 업무 범위 밖의 업무를 담당하거나 상세한 지식이 없는 경우). 이러한 경우에는 정중한 사과와 함께 면담을 종료하고 더 이상의 시간을 낭비하지 말아야 한다. 면담에 적절한 사람을 결정한 후 면담을 종료한다. 

 

  응답 유도

가장 힘든 상황은 응답자가 대답하지 않거나 협조하지 않는 경우일 것이다. 면담자는 재빨리 잘못된 부분을 지적하고 개방적인 질문으로 응답을 유도한다. (예:업무 수행시 가장 큰 문제점은 무엇입니까?)

 

  면담 내용 문서화

기록자는 면담 내용을 가능한 한 완전하게 기록하고 추가적인 내용을 기록하기 위한 충분한 여백을 확보한다. 면담 기록지는 기록자 혼자서만 보는 것이 아니라는 것을 명심한다.

 

잘못된 선입견의 배제

현재 갖고 있는 선입견들이 문제를 유발할 수 있으면 이를 버리고, 업무에 대한 면담 대상자의 관점에 대하여 다시 질문한다.

 

전형적인 질문의 예

• 업무 활동의 중요한 유형을 말씀하여 주십시오.
• 이 업무 활동이 종료되면 무슨 일이 일어납니까? 또 그 다음에는 무슨 일이 일어납니까? 일반적 결과는 무엇입니까? 어떤 것이 잘못될 수 있습니까? 잘못되면 어떻게 조치합니까?
• 업무를 트리거(Trigger)하게 하는 것은 무엇입니까? 언제 무엇을 합니까(월말과 같은 특정 시 점)? 그 밖에 하는 것은 무엇이 있습니까?
• 어떤 정보를 보냈습니까? 이들로 어떤 작업을 실행했습니까?
• 업무에 필요한 정보에는 어떤 것들이 있습니까? 이들 정보로 무엇을 합니까? 적당한 상세화 수 준은 어느 정도입니까?

 

워크숍

 

워크숍 개요 및 목적

워크숍은 어떠한 목적을 달성하기 위하여 전문 진행자의 진행 아래 프로젝트의 현업 부서 측과 전산 부서 측의 주요 구성원들이 함께 참여하는 회의이다. 정치적이거나 개인적인 요소들의 영향을 피하고, 다양한 정보의 원천으로부터 정보의 빠른 추출이나 공유를 필요로 하는 경우나 단순한 회의나 토론 이상의 무언가를 요구하는 상황 등에 사용될 수 있다. 중요한 것은 서로 관련 있는 부서들을 대상으로 워크숍을 실시하는 것이며 특정 주제에 대한 결론의 도출을 위해서도 유용하다. 워크숍의 주요 목적을 3가지 정도 들 수 있다.

• 경영층 또는 현업 부서장의 공통된 의견을 도출한다.
• 유사한 업무 또는 관련된 업무 등을 수행하는 부서에 대한 면담에 드는 노력을 절감한다.
• 전문가들의 판단력을 이용하여 최적의 결론을 도출한다.

워크숍 준비

워크숍을 통해 달성해야 할 목표와 구체적인 논의 사항들을 도출하기 위해 사전 준비가 필요하다.

• 워크숍 과제 선정과 계획 수립
• 참가 대상자 선정
• 참가 대상자에 대한 사전 브리핑 및 교육 훈련
• 킥오프 모임 수행
• 워크숍 자료 준비
• 설비와 물품 준비
• 워크숍 장소 선정
• 워크숍 기간 선정 프로그램 준비

워크숍의 수행

프로젝트 관리자와 현업 책임자는 워크숍이 공정하게 진행될 수 있도록 노력하며 워크숍의 산출물에 이해관계를 가지고 있기 때문에 워크숍 진행자가 되어서는 안 된다. 또한 올바른 의사소통과 투명성을 위하여 전문 용어의 사용은 가능한 자제하고 사용자 입장의 언어를 사용하도록 한다.

 

1) 워크숍 개시

• 워크숍의 시작을 알리고 간략한 인사의 말을 한다.
• 부수적인 항목들(휴게실 위치, 흡연구역 등)에 대해서 공지한다.
• 일정을 확인한다.

 

2) 워크숍 수행 준비

• 워크숍의 목적과 접근방법의 개요를 설명한다.
• 사용자로 하여금 워크숍의 목적을 재확인한다.
• 워크숍 기간 동안 작업을 수행하기 위하여 필요한 기법들을 습득한

3) 워크숍 수행

• 구체적인 워크숍 수행 방식은 형태나 특정 목적에 따라 다르게 수행한다.
• 워크숍의 목적에 맞게 진행될 수 있도록 조정하고 관찰한다.
• 세부적인 진행 방법 등은 기법을 이용한다.

  4) 워크숍 종료

• 종료할 때는 진행 일정을 확인하고 진행 사항을 요약한다.
• 워크숍 과정에서 도출된 요구 사항을 공유할 수 있도록 요약하고, 책임자가 전체에게 공유하여 1차적으로 검토 받을 수 있도록 한다.

 

현행 업무조사서

 

업무조사는 전체 부서에 대하여 동일한 기준으로 조사하는 것을 원칙으로 한다. 업무 표준화가 부진 하여 각 지점이나 부서마다 다르게 업무를 수행하는 경우가 발생할 수 있고, 회사 전체의 업무 수행 빈도와 데이터 수신, 발신량을 조사하기 위해서는 전수조사가 필요하기 때문이다.

• 동일한 업무를 수행하는 부서 혹은 지점이 여러 개인 경우에는 표본 추출 또는 발췌 조사도 가능하다.
• 업무 조사서의 양식은 단순하고 이해하기 쉬워야 하며, 양식의 작성 방법과 작성된 표본을 첨부하여 배포하는 것이 효과적이다.
• 업무조사서가 잘 작성된 경우에도 잘못 작성되거나 내용이 불충분한 경우가 발견되므로 업무조사서를 1차 수거한 후에 반송하여 다시 작성하는 경우가 발생할 수 있다. 이러한 상황도 일정 계획 수립에 반영하여야 한다.
• 사용자가 처리하고 있는 업무 기능을 정리된 양식으로 기록하여 향후 작업에 도움이 되도록 한다.

현행 프로그램/데이터 관련 문서

현행 시스템에 대한 자료 수집은 향후 사용자 요구 사항을 좀더 세부적으로 진행하기 위한 사전 단계로서 반영되어야 할 현행 시스템의 업무요건을 빠짐없이 파악하기 위한 작업이다.

• 현행 시스템 프로세스(프로그램)의 구조는 프로세스 계층도와 유사하게 계층적 구조로 표현하며, 이러한 현행 시스템 프로세스(프로그램)계층도는 향후에 업무 모델의 완전성을 검증하기 위한 비교자료로 활용된다.
• 현행 시스템의 데이터에 대한 분석은 현행 시스템에서 사용되는 현행 데이터 저장소의 구조를 파악함으로써 현행의 업무 프로세스에서 사용되는 데이터 구조를 이해한다.
• 현행 데이터 저장소의 구조는 현행 시스템 데이터 목록 및 세부 내역을 분석함으로써 현행 시스템의 데이터에 대한 업무 요건 및 업무 규칙은 현행 데이터 저장소의 구조와 화면, 양식, 보고서 레이아웃 등을 이해한다.

 

 

(DA가이드 2.2.2) 정보 요구 사항 정리

 

정보 요구 사항 정리

사용자 면담 정리

사용자 면담 시 제공된 자료의 샘플이나 관련 문서를 체계적으로 정리 기록한다. 정리가 완료되면 주요한 관점(업무 흐름, 수치, 주관 부서, 책임 부서 등)의 내용에 대해서는 다시 한 번 기록된 부분 의 오류가 있는지를 사용자에게 확인 받도록 한다.

 

 

업무 조사서 정리

회사 차원에서 활용하는 업무 문서 및 팀에서 사용하는 업무 문서를 포함하여 전체 리스트를 파악 할 수 있도록 체계적인 양식으로 정리한다.

[표 2-2-2] 업무 조사서에 포함되는 유형

모델	정리항목
수행 중인 프로세스 목록	- 대/중/소 분류별 프로세스명 - 프로세스 설명 및 수행 빈도 - 전산화 정도 / 전산화 필요성
프로세스의 업무 흐름	- 정보시스템을 포함하여 관련 부서 간의 업무 흐름을 시스템 흐름도 형태로 도식화
타부서 또는 외부 기관으로부터 받은 문서	- 문서명 및 설명 - 접수 부서(기관) - 접수 주기, 접수 수단 - 활용 형태 / 단위 문서량
사용 중인 시스템	- 시스템명 - 사용 범위, 사용 방법, 사용 빈도 - 유용성 - 편리성

 

 

워크숍 정리

사용자 워크숍을 통해 도출된 요구 사항이나 해결 과제들을 명백하고 간결한 문장으로 정리한 후 사후 대처할 수 있도록 한다. 해결과제에 대해서는 별도의 ID를 부여하여 관리한다. 워크숍 결과 정리시에는 다음 사항을 포함한다.

• 워크숍의 목적
• 워크숍 진행 내용
• 해결과제에 대한 상태
• 기타 특이사항

 

기타 기법 정리

관련 문서에 대한 정리 양식과 현행 프로그램 및 데이터에 대한 정리 양식은 일반적인 표준 양식을 정의하기가 어려워 제3장 정보 요구 사항 분석에서 사례를 들어 설명하기로 한다.

 

 

정보 요구 우선순위 분석

사용자로부터 수집된 모든 정보 요구 사항을 전부 시스템에 반영할 수 없다면, 필요한 기법을 동원 하여 우선순위를 부여하고 부여된 우선순위에 맞게 절차적으로 진행될 수 있어야 한다. 이를 위해 적용할 수 있는 기법으로 화폐가치 산출 방법과 상대적 중요도 산정 방법이 있다. 이를 이용하여 우선 순위를 평가함으로써 단위시스템의 개발 우선순위를 산정하는 기준으로 활용할 수 있다. 별도의 기법을 적용하지 않고 고유상황에 맞게 우선순위를 부여하고 진행하는 경우도 고려할 수 있다.

현재는 요구 사항에 대한 우선순위, 중요도, 소요 비용, 기대 효과 등을 고려한 비교적 판단이 용이 한 방법으로 약식 형태로 판단하고 있으며, 본 분석 방법은 실제에서는 보편적으로 사용하기에 시간 과 노력이 많이 소요되는 관계로 적용에 일정 부분 어려움이 존재한다.

 

화폐가치 산출 방법

화폐가치 산출 방법은 최종적으로 구해진 가치가 높을수록 우선순위가 있다. 그러나 최종 순위는 산출된 수치에 의존하지 않고 고유의 상황에 따라 다르게 적용될 수 있다.

• 정보 요구 사항을 전부 나열한다.
• 각각의 정보 요구 사항에 대하여 기업 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여한다.
• 각각의 정보 요구 사항에 대하여 시스템 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여한다.
• 각각의 정보 요구 사항이 다른 정보 요구 사항에 대해 얼마나 도움을 주는가를 평가하여 1점부터 5점까지의 점수를 부여한다.
• 앞서 부여한 세 가지 점수를 모두 곱한다.
• 전체 정보 요구 사항에 대하여 앞서 계산된 점수를 더하고, 점수 합계를 100으로 하여 각각의 정보 요구 사항 가치를 백분율(%)로 환산한다.
• 회사 전체의 이익에 앞에서 구한 백분율을 곱하여 각각의 정보 요구 사항 가치를 금액으로 환산한다.
• 가치가 높은‘정보 요구 사항2’,‘ 정보 요구 사항1’의 순으로 우선순위를 부여하는 방법이다.

 

상대적 중요도 산정 방법

상대적 중요도 산정 방법은 정보 요구 사항이 무엇을 지원하느냐에 따라 점수를 부여하고 이를 가 중치에 따라 계산하여 중요도를 산정하는 방식이다. 상대적 중요도 산정 방법 역시 다소 복잡하여 적 용에 한계를 가지며, 각기 부여된 가중치에 이해를 달리 할 수 있는 여지가 있다.

• 정보 요구 사항이 업무에 기여하는 수준에 따라 1점부터 5점까지의 점수를 부여한다. 예를 들어 목적을 지원하면 5점, 목표를 지원하면 4점, 전략을 지원하면 3점 등의 방법으로 업무를 분류한 체계에 따라 결정한다.
• 정보 요구 사항 대 정보 요구 사항 매트릭스를 작성하여, 각각의 정보 요구 사항이 다른 정보 요구 사항에 얼마나 관련되어 있는가를 계산한다. 가장 관련이 큰 정보 요구 사항에 9점을 부여하고, 나머지 정보 요 정보시스템이 각각의 정보 요구 사항을 얼마나 충족하는가에 대하여 1점에서 3점까지의 점수를 부여한다. 예를 들어 만족스러운 경우에는 3점, 보통인 경우에는 2점, 지원하지 않는 경우에는 1점 등의 방식으로 부여한다.
• 앞서 부여한 세가지 점수에 대하여 가중치를 결정한다. 예를 들어 업무 지원 정도는 50%, 다른 정보 요구 사항과의 관련도는 20%, 현행 시스템 지원 정도는 30% 등의 방법으로 정하되, 정보 전략계획을 수립하는 대상 기업의 특성을 감안하여 결정한다.
• 가중치에 따라 앞에서 계산한 세 가지 요인의 가중 평균을 구하여 각각의 정보 요구 사항에 대한 중요도를 평가한다.

 

 

(DA가이드 2.2.3) 정보 요구 사항 통합

 

정보 요구 사항 목록 검토

 

전사 관점에서 동일한 정보 요구 사항을 여러 부서 및 사용자가 제시했는지를 검토하기 위하여 별도의 양식으로 취합 조정한 후 중복 도출 여부를 검토한다.

 

 

정보 요구 사항 목록 통합/분할

취합된 전체 정보 요구 사항을 대상으로 최종 분석할 정보 요구 사항을 도출한다. 우선 동일 부서 내 정보 요구 사항을 기준으로 중복성 검토를 진행하여 유일한 정보 요구 사항을 도출하고, 도출된 정보 요구 사항이 다른 부서의 정보 요구 사항에 포함되어 있는지를 확인한다.

 

 

동일 부서 내 중복 요구 사항 검토

• 부서 내 정보 요구 사항 목록을 작성한다.
• 정보 요구 사항 제목을 기준으로 부서 내 동일 요건의 요구 사항이 존재하는지를 파악한다.
• 정보 요구 사항의 세부 요청 내용을 기준으로 세밀하게 중복 여부를 파악한다
• 부서 내 동일 요건이 도출된 경우 관리대상 요구 사항에 통합할 정보 요구 번호를‘비고’란에 기입 한다.
• 동일 부서 내 중복성을 배재한 요구 사항 목록을 완성한다.
•  

서로 다른 부서간 중복 요구 사항 검토

• 부서 내 정리된 정보 요구 사항 목록과 부서간에 동일한 정보 요구 사항이 존재하는지를 파악한다.
• 정보 요구 사항의 세부 내용을 세밀하게 검토하여 중복여부를 파악한다.
• 부서 간에 동일 요건이 도출된 경우 관리 대상 요구 사항에 통합할 정보 요구 번호를 기입하여 관리한다.
• 최종적으로 전사 관점의 검토된 정보 요구 사항 목록을 작성한다.

 

 

3장. 정보 요구 사항 분석

(DA가이드 2.3.1) 분석 대상 정의

 

사용자로부터 수집한 정보 요구 사항을 바탕으로 업무 현황을 파악한다. 이를 근간으로 관련 업무 및 시스템의 문서를 조사, 수집 및 파악함으로써 현행 업무 및 현행 시스템에 대한 분석 대상을 정의한다. 사용자의 정보 요구 사항을 구체화하고 상세화하는 작업의 효율성을 이루고자 한다.

 

현행 업무 분석 대상 정의

분석 대상 자료

현행 업무를 파악하여 필요한 정보 요구 사항을 도출하기 위해 필요한 관련 자료를 확보하여야 하며, 이에 해당되는 업무 자료는 다음과 같은 자료를 활용한다.

• 현행 업무 흐름도
• 현행 업무 설명서
• 현행 업무 분장 기술서
•  

분석 대상 업무 영역 선정

수집된 사용자의 정보 요구 사항을 바탕으로 현행의 업무흐름 및 관련 데이터를 파악하여 분류기준에 따라 분석 대상 현행 업무 목록을 작성한다. 작성된 분석 목록을 가지고 정보 요구 사항 분석을 위한 대상으로 선정할 것인지 결정을 하고 분석 대상 업무 목록표에 표기한다. 분류기준이란 통상적으로 현행 업무 기능 분해도의 단위 업무 또는 업무 분장상의 구분 등을 말한다. 분석 대상 현행 업무 목록의 예는 [그림 3-3-1]과 같다.

 

 

현행 시스템 분석 대상 정의

분석 대상 현행 시스템 선정

정리된 정보 요구 사항에 대해서 업무 영역별 분석 대상 현행 시스템을 선정하기 위하여 업무 영역/현행 시스템 매트릭스를 작성한다. 이를 작성하기 위해서는 업무 분석 프로젝트의 수행 범위를 정확히 파악하는 것이 선행되어야만 업무 영역별로 대상 현행 시스템을 선정하는 작업이 가능하다. 업무 영역/현행 시스템 매트릭스의 예는 [그림 3-3-2]과 같다.

 

 

업무 영역/현행 시스템 매트릭스를 바탕으로 업무 영역별 분석 대상 시스템 목록을 작성한다. 분석 대상 시스템 목록의 예시는 [그림 3-3-3]과 같다.

 

 

 

분석 대상 현행 시스템 관련 자료

현행 시스템과 관련된 문서를 조사 및 수집하고 이를 현행 시스템 수집 문서 목록에 정리한다. 현행 시스템 관련 수집 대상 문서는 다음과 같다.

• 현행 시스템 구성도
• 현행 시스템의 분석, 설계 및 개발 보고서
• 화면, 장표 및 보고서 레이아웃
• 현행 시스템 테이블 목록 및 테이블 정의서
• 프로그램 목록
• 사용자 및 운영자 지침서
• 시스템 지원 및 유지보수 이력
• 시스템 개선 요구 사항 등
•  

현행 시스템 수집 문서 목록의 예는 [그림 3-3-4] 과 같다.

 

 

수집된 문서의 평가는 다음의 기준으로 수행하고 보완 여부 항목에 표기함으로써 보완 작업을 종료한다.

• 유용성 : 문서의 활용 가능성 여부
• 완전성 : 문서의 내용에 누락된 부분이 없는지 여부
• 정확성 : 문서의 내용이 현재의 시스템과 일치하는지 여부
• 유효성 : 문서가 최신의 내용을 반영하고 있는지 여부

  추가적인 분석 대상

현행 데이터 측면의 업무 요건 혹은 업무 규칙을 보다 상세하게 분석하기 위하여 사용자 뷰도 분석 대상에 포함한다. 데이터 뷰는 전체적인 정보 중에서 일부를 바라보는 관점을 나타내며, 이러한 사용 자 뷰가 종합되어 나타나는 것이 화면, 수작업 파일, 수작업/전산 양식, 보고서 등의 레이아웃이다.

 

 

 

(DA가이드 2.1.1) 정보 요구 사항 상세화

 

정보 요구 사항 분석 대상이 정의된 현행 업무 영역 관련 자료 및 현행 시스템 관련 자료에 대하여 분 석을 하고, 분석 결과인 분석 산출물을 토대로 사용자의 정보 요구 사항을 보완하고 비기능적 정보 요 구 사항을 포함하여 문서 작업을 통한 정보 요구 사항 정의서를 보완한다.

 

  비기능적 정보 요구 사항

• 시스템이 만족시켜야 하는 제약 조건(기술적 제약 조건, H/W, S/W와 관련된 제약 조건)
• 시스템이 반드시 만족시켜야 하는 주요 성능 척도(반응 시간, 저장 능력, 동시 처리 능력)
• 신뢰성, 확장성, 이식성, 보안

 

프로세스 관점의 정보 요구 사항 상세화

프로세스는 실제로 업무가 수행되는 행위를 뜻한다. 프로세스는 기본 기능이 분해되면서 나타나 다시 프로세스로 분해된다. 업무 기능은 기업의 목표달성을 위하여 지속적으로 수행되기 때문에 시작 시점과 종료 시점이 명확히 구분되지 않는다. 하지만 프로세스는 시작 시점과 종료 시점이 명확하고 실행 횟수를 셀 수 있는 업무 활동을 의미한다. 프로세스는 업무를 어떻게 수행하는가 보다는 어떤 업무가 수행되는지를 나타낸다. 따라서 입력(Input)과 출력(Output)이 있으며 입력을 출력으로 바꾸는 변환과정을 포함한다. 프로세스를 분해하다 보면 더 이상 분해되지 않는 최소 단위의 업무를 찾게 되는 데 이를 기본 프로세스라 부른다.

 

  수행 절차

• 프로세스 중심으로 정리된 프로세스 목록, 프로세스의 업무 흐름도 내용을 수반하는 업무 조사서를 바탕으로 프로세스 계층도, 프로세스 정의서를 작성한다.
• 도출된 기본 프로세스를 기준으로 기본 프로세스에서 필요로 하는 정보 항목과 산출되는 정보 항목을 정리하고, 산출되는 정보 항목 중 기본 로직이 필요한 경우 기본 로직을 정리한다.
• 표준화 과정을 통하여 해당 정보 항목에 대해서 통합성/분리성 여부를 검토한 후 최종적으로 사용자의 정보 요구 사항을 충족하는 정보 항목 목록을 정의한다.

 

  수행 작업 내용

 

[표 2-3-1] 프로세스 관점의 정보 요구 상세화

수 행 작 업	수 행 작 업 내 용
프로세스 분해/상세화	- 단위 업무 기능별 하향식으로 프로세스를 분해 및 도출 - 프로세스 계층도 및 프로세스 정의서를 작성
정보 항목 도출 및 표준화	- 기본 프로세스별 정보 항목을 정리 - 정보 항목에 대한 표준화 정리 - 정보 항목 목록 정의
정보 항목별 통합성, 분리성 여부 검토	- 프로세스별로 관리되는 정보 항목을 분류 - 정보 항목별 동음이의, 이음동의 존재 여부 파악 - 통합/분리 여부 검토 후 최종 정보 항목 목록 정의

 

  수행 작업 지침

1) 프로세스 분해 / 상세화

가) 프로세스의 분해

• 프로세스의 분해는 단위 업무 기능으로부터 출발하여 점진적으로 수행한다. 단위 업무 기능은 하위에 더 이상 업무 기능을 포함하지 않고, 프로세스만으로 구성된 업무 기능을 의미한다.
• 단위 업무 기능별로 상세하게 프로세스를 분해하지 않고, 해당 업무 영역의 전체 단위 업무 기능 에 대하여 프로세스의 분해 수준을 맞추어 점진적으로 분해한다.
• 업무 기능 계층도가 단위 업무 기능 수준까지 분해되지 않았을 경우에는 단위 업무 기능 수준까지 더 분해한 후 프로세스를 도출한다.

 

나) 프로세스 분해 깊이

• 프로세스 분해시 업무적인 특성을 고려하여 분해의 수준은 3차 수준까지 분해한다.
• 3차 수준까지 프로세스를 도출하는 과정에서 기본 프로세스 수준까지 도출되는 경우도 있으며 업무 활동 분해의 근본적인 목적은 최종적으로 기본 프로세스의 도출에 있다.
• 그러나 초기 작업에서는 도출된 프로세스가 기본프로세스 인지는 중점을 두지는 않으며 대상 범위의 모든 프로세스를 균형 있게 분해하는 데에 주의를 기울인다.
• 도출할 프로세스의 대상은 일반적으로 데이터의 상태를 변화시키는(생성, 수정, 삭제) 것만을 프로세스로 정의한다. 하지만 업무적으로 중요한 의미를 가지는 조회용 프로세스 또는 수작업 프로세스는 필요에 따라 명명규칙을 달리하여 도출하는 것도 바람직하다.

 

다) 프로세스 명칭

프로세스의 명칭은 명명규칙을 준수하여 명명하되 업무 용어를 그대로 사용하고 이름만으로도 개략적인 수행 내용의 파악이 가능하도록 함축적이며 유일한 이름을 부여하는 것이 중요하다.

라) 프로세스 계층도

• 프로세스 계층도를 작성하는 목적이 기본 프로세스의 도출에 있으며, 추후 업무적으로 기술한 프로세스 정의서를 바탕으로 작업을 수행하게 되므로 이에 대한 상세한 내용이 반영된다.
• 프로세스 계층도는 높은 응집도(Cohesion) 및 낮은 결합도(Coupling)를 유지하도록 모듈성을 확보하는 것이 중요하다. 이러한 원칙에 따라 분석하면 분석의 복잡도와 모호성이 감소되고 분석의 집중력이 향상되어 프로젝트 관리 및 프로세스 유지보수가 용이하다. 일반적으로 상위 프로세스에 포함되는 하위 프로세스가 7개를 초과하면 상위 프로세스를 분리하는 것을 고려한다. 프로세스 계층도의 예는 [그림 3-3-5]과 같다.

 

• 프로세스별 정의(설명)는 업무를 구체적으로 이해할 수 있는 수준으로 상세하게 작성한다. 프로세스 정의서는 프로세스와 기본 프로세스를 함께 기술하는 양식으로서, 프로세스 정의서 양식의 데이터 사용 항목은 모든 프로세스에 대해 기술할 필요는 없다. 그러나 기본 프로세스의 경우에는 반드시 작성하도록 한다. 프로세스 정의서는 [그림 3-3-6]과 같다.

 

• 이미 작성된 프로세스 계층도를 재검토해 해당 업무 영역에 포함되는 모든 업무 요건 및 업무 규칙이 반영되었는지를 확인하고, 프로세스 계층도를 조정한다.

 

• 현 수준의 프로세스 계층도를 더욱 상세하게 분해하여 업무의 최소 단위인 기본 프로세스까지 도출한다.

 

 

 

 

2) 정보 항목 도출 및 표준화

• 프로세스 분해 및 상세화에서 도출한 기본 프로세스별로 등록(C), 조회(R), 변경(U), 삭제(D) 기능을 구분하여 기술한다.
• 기능에 따라 구분된 프로세스별로 정보 요구 분석에서 정의된 정보 요구 사항 정의서 및 업무 조사서 상의 내용을 파악하여 관리하고자 하는 정보 항목을 도출한다. 서술식으로 표현된 자료에서 정보 항목을 도출하기 위해서 ‘명사형’ 으로 표현된 단어를 파악하면, 이러한 단어들이 정보 항목의 대상이 되는 경우가 많다.
• 도출한 정보 항목은 명명규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하며, 명사형으로 기술한다.

 

• 해당 도출된 정보 항목에 대해서 그룹핑하여 정보 항목군으로 구분하고. 정보 항목 목록을 작성 한다. 정보 항목 정의는 [그림 3-3-8] 로 정리한다.

 

3) 정보 항목별 통합성 검증

• 정보 유형별 및 정보 항목별로 전사 관점에서의 통합/분리여부를 검토한다.
• 동일한 정보 항목에 대해서 통합시 다음과 같은 장점이 존재한다. - 통합 정보 항목으로 도출 시 정보 항목의 관리가 용이함 - 동일한 유형의 정보 항목이 존재 시 통합 정보 유형으로 수용 가능
• 단, 아래와 같은 단점도 존재한다. - 무리한 통합 작업으로 인한 정보 항목의 애매모호성 존재 - 통합 정보 항목에 대한 관리 부족으로 통합의 의미 상실 가능성 존재
• 통합 작업 후 해당 정보 항목 목록에 대한 통합성 여부를 기재하고 최종 정보 항목 목록을 작성 한다.

 

객체지향 관점의 정보 요구 사항 상세화

객체지향 방법론에서는 유즈케이스 다이어그램을 중심으로 정보시스템의 기능적 정보 요구 사항을 정의한다. 해당 다이어그램은 사용자와의 의사소통을 원활하게 진행될 수 있도록 도움을 주며, 시스템 영역내의 유즈케이스와 액터, 그리고 그들 간의 관계를 유즈케이스 다이어그램으로 도식화하고 도출된 유즈케이스의 사건 흐름을 상세화한다.

 

  유즈케이스 다이어그램 액터(Actor)

• 정보시스템과 상호작용하는 개인, 그룹, 회사, 조직, 장비 등 정보 서비스를 받는 객체를 말한다.
• 엑터의 이름은 명확하게 액터의 역할을 나타내는 이름으로 정의한다.

  유즈케이스(Usecase)

• 도출된 액터별로 개발 시스템에서 제공해야 하는 기능을 나타낸다.
• 사건 흐름에 대한 개요를 간략하게 기술한다.

  액터(Actor)와 유즈케이스 간의 관계

• 확장(Extend) : 하나의 유즈케이스가 다른 유즈케이스의 행동을 추가함에 따라 나타나는 두 유즈케이스의 관계를 말한다. 하나의 유즈케이스가 다른 유즈케이스를 경우에 따라 선택적으로 수행되는 경우에 사용된다.
• 포함(Include) : 하나의 유즈케이스가 다른 유즈케이스를 사용함을 나타내는 두 유즈케이스의 관계를 말한다. 하나의 유즈케이스가 다른 유즈케이스를 반드시 수행하는 경우에 사용된다.
• Communicates : 행위자가 어떤 유즈케이스에 참가함을 나타낸다. 이것은 행위자와 유즈케이스 사이의 유일한 관계이다.

 

유즈케이스 다이어그램의 예는 [그림 3-3-10]와 같다.

 

 

유즈케이스 상세화

유즈케이스의 사건 흐름을 구조화하는 작업으로 모든 선택 또는 대안 흐름을 기술한다. 유즈케이스의 특별 정보 요구 사항을 정의한다.

유즈케이스에는 관련이 있지만 사건 흐름에는 고려되지 않는 정보 요구 사항을 유즈케이스의 특별 요구 사항으로 정의한다.

이러한 특별한 정보 요구 사항은 비기능적인 정보 요구 사항으로 기술한다. 사건 흐름을 기술할 때 정상적인 흐름에 대해 먼저 기술한 후 예외사항에 대한 사건흐름을 기술한다.

다음과 같은 내용을 기술한다.

• 유즈케이스에 대한 개략적인 설명
• 사건 흐름(Flow or Event)
• 사전, 사후 조건
• 비기능적인 정보 요구 사항
• 주된 사건 흐름에 대체될 수 있는 대안 흐름
• 예외 처리 사항
•  

클래스 다이어그램 작성

1) 엔터티 클래스 도출

유즈케이스 모형을 검토하여 문제 영역 내의 개념을 나타내 엔터티 클래스를 도출하여 정의한다. 식별된 클래스에 이름을 부여하고, 간략한 설명을 기술한다. 클래스 이름은 간결하고 업무적 의미를 함축한 단수형 명사로 부여하며, 은어 및 약어 사용은 배제한다.

• 유즈케이스 다이어그램을 조사하여 명사 및 명사구를 후보 객체로 선정한다.
• 의미가 모호한 것은 제거한다.
• 이음동의어 및 동음이의어를 고려하여 선정한다.
• 문제 영역과 관련이 없는 것은 제거한다.
• 유사한 구조와 행위를 가진 객체들을 클래스로 그룹핑한다.
•  

2) 관계 도출 및 클래스 도출

관계란 의미있고 관심있는 연결을 나타내는 클래스간의 관계를 의미한다. 클래스간의 집단화 관계를 식별하고 명명한다. 집단화 관계란 전체적인 클래스와 부분적인 클래스의 포함 관계를 표현한다.

3) 속성 정의

속성이란 클래스가 나타내는 객체의 특성을 의미한다. 유즈케이스 다이어그램을 검토하여 클래스를 구성하는 속성을 도출한다. 속성에 대한 이름을 부여하고 간략한 설명을 기술한다. 속성의 이음은 성을 가지고 있는 정보를 명확하게 지정하는 명사로 한다.

 

 

(DA가이드 2.3.3) 정보 요구 사항 확인

 

사용자 및 부서로부터 접수해서 최종적으로 작성된 산출물에 대해 정보 요구 사항을 제시한 담당자와 세부 재검토를 통하여 누락 사항 및 보완 사항을 도출하기 위한 계획을 수립하고 재검토를 실시한다.

 

수행 절차

• 분석 결과 도출된 산출물에 대해서 재검토 기준을 정의하고, 재검토 계획을 수립한다.
• 재검토 대상 산출물의 완전성, 정확성, 일관성, 안정성 등 다양한 측면에서 재검토를 실시한다.
• 재검토 결과, 추가 및 보완 사항이 존재하는 경우에 내용을 문서로 정리한 후 해당 산출물에 추가 반영 여부를 확인하고, 미반영시 미반영 사유의 타당성을 검토한다.

 

수행 작업 내용

[표 3-3-2] 정보 요구 사항 확인 수행 작업

수 행 작 업	수 행 작 업 내 용
재검토 계획 수립	- 재검토의 대상이 되는 분석 결과 및 정보 요구 사항 정의서 산출물 확인 - 대상 산출물별로 재검토 기준(체크 리스트) 정의
재검토 실시	- 재검토 계획서 작성 및 승인 - 재검토 대상 산출물 준비 및 배포와 재검토 담당자별 역할 분담 - 업무 영역별로 재검토 대상 산출물을 재검토
보완 결과 확인	- 재검토 결과를 토대로 업무 영역별로 산출물 보완 - 재검토 결과 반영 여부 확인 및 미반영 사유 검토 - 정보 요구 사항 정의서의 안정성 분석 - 재검토 결과를 토대로 보완 목록 수정

 

수행 작업 지침 

 

재검토 계획 수립

재검토의 대상이 되는 분석 결과 산출물을 확인한다. 일반적인 재검토의 대상이 되는 것은 정보 요구 사항 정의서, 정보 항목 목록, 유즈케이스 정의서 , 클래스 다이어그램 등이 있다. 재검토 기준은 해당 작업의 완전성과 정확성 및 안정성을 검증할 수 있는 체크리스트로 작성한다. 재검토 및 검증의 기준을 간략히 요약하면 다음과 같다.

• 완전성: 사용자의 정보 요구 사항이 누락없이 모두 정의되었는지 확인
• 정확성: 사용자의 정보 요구 사항이 정확히 표현되었는지의 여부
• 일관성: 표준화 준수 여부 확인
• 안정성: 추가 정보 요구 사항 변경에 따른 영향도 파악
•  

정보 요구 사항별로 1차 재검토 후 결과를 모델에 반영할 수 있도록 일정을 계획하여야 한다. 재검토를 통해 전체 업무영역에 영향을 미치는 공통사항에 대한 변경과 통합성을 일관되게 추적 관리할 수 있도록 별도의 인원을 재검토팀에 배정하여야 한다.

 

재검토 계획서에 포함되어야 할 사항

• 정보 요구 사항 재검토 개요 및 목적
• 재검토 일자
• 재검토 장소 및 시간 계획
• 재검토 참석 대상 및 재검토 업무
• 참석 대상별 재검토 세부 시간 계획
• 재검토시 준비물
• 재검토 후 산출물
• 재검토 후 지적사항 반영 계획 수립

 

재검토 실시

• 재검토 기준 및 재검토 대상 산출물을 준비하고 재검토에 참여할 대상자에게 배포한다.
• 재검토 관련 장소, 시간, 준비 장비 등 재검토를 실시하기 위한 제반 준비를 수행하며, 재검토 담당자별로 재검토 세션에서 수행해야 할 역할을 충분히 주지시킨다.
• 재검토 세션 실시 이전에 반드시 배포된 산출물을 예습해야 한다. 재검토 세션 이전에 재검토 대상 산출물을 예습하는 것은 아주 중요한 일이다. 실제 재검토 세션에서의 재검토는 재검토한 결과를 토대로 의문사항, 잘못 정의된 사항 등에 대하여 의견을 개진하고 결론을 도출하여 반영 대상을 기준에 따라 반드시 사전에 담당자별로 수행되어야 한다.
• 재검토시 진행자는 제기되는 이슈에 대해서 참석자들간에 결론을 도출하기 위한 토론이 발생하지 않도록 이슈 목록으로 정리하게 하고 정해진 일정 내에 마칠 수 있도록 주의를 기울여야 한다.
• 재검토시에는 통합성 검증을 위하여 해당 업무 영역과 관련 있는 업무 영역 담당자가 참여하여야 한다.
• 재검토는 많은 인원이 함께 작업을 수행하는 경우에, 진행시간이 초과되어 충분한 검증이 이루어지지 못할 수도 있으므로, 진행자는 세션별로 적절한 시간 배분 및 조정의 역할을 충실히 수행하는 것이 중요하다.
• 재검토 세션이 종료되면 세션별로 그 결과를 재검토 결과로 정리한다. 재검토 결과는 [표 3-3-11]과 같은 양식에 정리한다.

 

• 재검토 결과가 정리되면 해당 정보 요구 사항별 보완 사항을 유형에 따라 보완 목록에 작성한다. 보완 목록을 작성시에는 재검토 결과의 지적 사항만을 기록하는 것이 아니라 내용 보완시 해당 분석 결과 산출물의 일관성 유지를 위해, 특정내용이 변경됨으로써 함께 변경되어야 할 대상도 함께 기록한다. 보완 목록은 [그림 3-3-12]과 같은 양식에 작성한다.

• 보완 사항을 반영할 경우에는 정보 요구 사항간의 일관성이 유지되도록 주의한다. 모든 사항의 반영이 완료되면 반영해야 할 사항의 누락은 없는지, 잘못 반영된 사항은 없는지를 전체적으로 검토한다.

  보완 결과 확인

• 재검토 준비와 마찬가지로 보완 결과에 대한 확인 준비를 한다. 재검토 결과, 보완 목록, 보완 사항이 반영된 정보 요구 사항 정의서를 준비하고 배포한다.
• 보완 목록에 준하여 정보 요구 사항 정의서 반영 여부를 확인한다. 반영되지 않은 사항의 미반영 사유가 존재할 경우에는 미반영 사유가 타당성이 있는지를 검토하고 사유가 타당하지 못한 검토 결과 미반영 사유가 업무 규칙이나 정책의 변경을 수반하는 경우에 프로젝트 기간 내에 해결 가능한 것은 개선과제로 정리하여 해당 부서에 의뢰한다.
• 보안 목록에 있는 보완 사항이 모델에 모두 반영된 것을 확인하면 본 작업은 종료된다.

 

수행시 고려사항

• 일관성 있는 기준 및 명확한 일정을 수립함으로써 모든 참여 인력에 공감대를 형성하는 것이 중요하며, 이를 바탕으로 작업을 수행해야 한다.
• 재검토는 한번으로 종료되지 않는 것이 보통이므로 두번 이상을 진행하되 세션마다 재검토 기준을 명확히 하여 해당 기준에 초점을 맞추어 수행하는 것이 바람직하다.
• 재검토 세션을 수행시 세션 진행의 효율성을 감안하여 적정한 참여 대상을 선정해야 한다. 너무 많은 인력이 참여하게 되어 세션의 집중력을 상실하거나 결론에 도달하지 못하는 경우에 주의해야 한다.

 

 

4장. 정보 요구 검증

(DA가이드 2.4.1) 정보 요구 상관분석 기법

 

도출된 정보 요구 사항을 다른 영역(기능, 프로세스, 조직 등)과 비교 분석함으로써 정보 요구 사항의 도출이 완전하게 효과적으로 이루어졌는지를 파악할 수 있다. 이를 기반으로 향후 안정적이고 확장 가 능한 데이터 모델 설계가 가능하다. 이러한 상관분석은 매트릭스 분석 기법을 활용하며, 이 절에서는 정보 요구 사항과 애플리케이션의 기본 프로세스, 비즈니스의 업무 기능, 조직과의 매트릭스 분석 기법 을 소개한다.

정보 요구 사항의 충족도를 파악하기 위한 상관분석 수행의 주체는 다음과 같으며, 아래의 장·단점 을 고려하여 충분한 시간을 가지고 검토한다. 정보 요구 분석가나 품질보증 팀에 의해 상관분석을 진행 한 후, 단계 종료 시점에 외부 인력에 의한 요구 사항의 감리를 통하여 객관성 및 완전성을 증대시킨다.

 

주체별 분류

요구 사항 분석가 수행

정보 요구 사항을 수집하고 분석한 주 담당자를 기준으로 검토 기준 항목을 마련하고 상관분석을 수행하는 방법을 말한다.

• 정보 요구 사항을 도출한 분석가에 의해 수행되므로 자체 분석에 의한 객관성 저하의 문제점이 발생할 수 있다.
• 정보 요구 사항의 도출 절차 및 관련 업무팀과의 의사소통이 원활하므로 상관분석에 추가 인력의 투입 없이 원활하게 진행할 수 있다.
• 요구 사항 분석가의 업무에 대한 이해도가 높으므로 상관분석을 통한 정확한 업무의 분석 가능성이 높다.

품질보증팀 수행

프로젝트팀 내의 통합 검토팀이나 품질보증팀의 협조를 얻어 도출된 정보 요구 사항의 상관분석을 수행한다.

• 요구 사항 분석가보다는 업무에 대한 이해도가 낮으나 상관분석 작업의 수행을 통한 업무 이해도를 높일 수 있으며 전체적인 인터페이스의 검증에 용이하다.
• 낮은 업무의 이해도로 인해 일부 사안에 대한 정확한 분석을 통해 단점을 지적하여 수정하기 어렵다.

 

외부 감리 수행

외부 감리 인력을 이용한 정보 요구 사항 상관분석을 수행한다.

• 업무 파악의 한계가 있으나 제 3자의 시각으로 검토할 수 있다.
• 프로젝트 내부 인력이 효과적으로 지원하지 않을 경우 상황에 맞지 않는 분석 결과를 초래할 수 있다.
• 상관분석의 객관성을 극대화 할 수 있다.

 

정보 요구/애플리케이션 상관분석

정보 요구 사항을 바탕으로 도출된 정보 항목을 애플리케이션 아키텍처에서 정의된 프로세스 모델과 비교하여 상호 간의 일관성을 확보하고 품질 수준을 향상시키는 동시에 누락 혹은 중복된 정보 요구 사항을 점검한다. 이는 다음과 같은 절차를 통해 매트릭스 분석을 진행한다.

• 정보 요구/애플리케이션 상관분석을 위해 정보 요구 사항을 바탕으로 도출된 정보 항목들과 애플리케이션 영역에서 도출한 기본 프로세스를 사용하여 매트릭스를 작성한다.
• 매트릭스 분석은 기본 프로세스와 정보 요구 사항을 기반으로 기본 프로세스의 액션 (C: 생성, R: 조회, U: 수정, D: 삭제)을 빠짐없이 정의한다. 그리고 기본 프로세스/정보 요구 사항 매트릭스를 작성하여 모든 정보 요구 사항들이 기본 프로세스에 의해 충분히 사용되고 있는지 또는 모든 기본 프로세스를 수행하는데 필요한 정보 요구 사항이 도출되어 있는지를 조사함으로써 정보 요구 사항과 기본 프로세스 도출의 완성도 및 일관성을 검증한다.

 

• 매트릭스의 각 셀에는 기본 프로세스가 사용하는 정보 항목에 대한 액션이 생성(C), 조회(R), 수정(U), 삭제(D)로 표현되는데, 복수의 액션이 발생할 경우에는 C > D > U > R의 우선순위에 따라 하나만을 기록한다. 그러나 분석기법의 활용시 CRUD가 복수로 발생할 경우 모두 기록할 수 있으며, 이는 분석기법을 활용하는 분석가의 매트릭스 활용 목적에 따라 선택 가능하다.
• 모든 정보 항목이 모든 기본 프로세스에서 사용되었는지 혹은 모든 정보 항목을 사용하고 있는지를 확인한다.
• 정보 요구/애플리케이션 상관분석 매트릭스는 두 가지 객체 중에서 한가지가 누락되거나 잘못 정의된 경우에는 분석이 가능하지만 정보 항목과 기본 프로세스가 모두 누락된 경우에는 분석이 불가능하다. 따라서 매트릭스가 작성되기 전에 이러한 경우가 있는지를 사전에 확인해야 하며, 매트릭스를 분석하는 경우에도 이러한 사례가 있는지를 파악해야 한다.

정보 요구/업무 기능 상관분석

정보 요구 사항을 바탕으로 도출된 정보 항목을 비즈니스 아키텍처에서 도출된 업무 기능과 비교하여 상호 간의 일관성을 확보하고 품질수준을 향상시키는 동시에 누락 및 중복된 정보 요구 사항을 점검할 수 있다. 비즈니스에서 요구하는 정보 항목은 데이터 모델링의 근간이 되므로 업무 기능별 필요 정보 항목의 누락 여부의 확인은 매우 중요하다.

• 가치 사슬 분석 등의 기법을 통해 도출된 최하위 수준의 전사 업무 기능을 도출하고 이렇게 도출된 업무 기능을 매트릭스의 열에 배치한다.
• 정보 요구 사항에 따라 도출된 정보 항목을 매트릭스의 행에 배치한다.
• 업무 기능과 정보 항목 간의 상호작용을 다음과 같이 정의한다. - 정보 항목의 생성, 수정, 삭제를‘C’로 표시한다.(Create 또는 Change) - 값의 변경 없이 정보 항목을 검색만 하는 경우에는‘U’로 표시한다.(Use) - 아무 관련이 없는 것은 빈칸으로 남겨둔다.

 

정보 요구/조직 기능 상관분석

정보 요구 사항을 바탕으로 도출된 정보 항목을 비즈니스 아키텍처에서 도출된 조직 단위와의 매트릭스 분석을 통해 정보 항목의 생성 주체 및 활용 부서의 매핑이 가능하다. 이를 기반으로 향후 정보 항목에 대한 오너십(Ownership)을 할당하여 관리함으로써 데이터를 효율적으로 관리할 수 있다.

 

• 조직 단위명은 기업의 조직도에 나타난 순서로 입력한다. 만일 기업이 둘 이상의 소재지에서 운영 된다면 조직 단위를 분할하고 소재지 타입에 따라 클러스터링한다. 매트릭스에 소재지 타입(예 : 본사, 영업소, 공장)에 의해 그룹핑된 조직 단위명을 입력한다.
• 정보 요구 사항에 따라 도출된 정보 항목을 매트릭스의 행에 배치한다.
• 조직과 정보 항목 간의 상호작용을 다음과 같이 정의한다. - 정보 항목의 생성, 수정, 삭제를‘C’로 표시한다. (Create 또는 Change) - 값의 변경 없이 정보 항목검색만 하는 경우에는‘U’로 표시한다.(Use) - 아무 관련이 없는 것은 빈칸으로 남겨둔다.

 

 

 

(DA가이드 2.4.2) 추가 및 삭제 정보 요구 사항 도출

 

정보 요구/애플리케이션 상관분석

애플리케이션 충족도 분석 매트릭스

애플리케이션 충족도 분석 매트릭스는 다음 기준에 따라 점검하며 추가되거나 삭제되어야 할 정보 요구 사항을 도출한다.

• 정보 요구 사항에 따라 발생하는 정보 항목을 생성하는 기본 프로세스가 반드시 존재해야 한다.
• 정보 항목의 상태를 종료시키는 기본 프로세스가 존재해야 한다.
• 생성된 정보 항목은 조회, 수정, 삭제 액션 중 하나가 발생해야 한다.
• 하나의 정보 항목을 생성, 수정, 삭제하는 프로세스의 합은 7개를 초과하지 않는 것이 보통이다. 이를 초과하는 경우에는 올바르게 정의되었는지를 확인한다.
• 수작업으로 정의하거나 조회 전용으로 특별히 정의된 기본 프로세스를 제외한 나머지의 기본 프로세스는 반드시 생성, 수정, 삭제 액션 중의 하나를 수행해야 한다.
•  

매트릭스 분석

매트릭스 분석은 다음과 같은 점검 내용을 중심으로 보완한다.

• 매트릭스 분석은 추가 및 삭제되어야 할 정보 요구 사항을 도출한다. 해당 점검 내용의 조치 사항이 애플리케이션과 관련된 것일 경우에는 해당 애플리케이션 팀에 전달하고 협의하여 정의된 정보 요구 사항과 애플리케이션은 프로세스와의 일관성을 가져야 한다.

 

 

[표 3-4-1] 매트릭스 점검 내용

번호	점검 내용	분석 결과	조치 사항
1	기본 프로세스가 사용 (CRUD)하는 정보 항목이 없음	정보 항목의 누락	정보 항목 도출
		기본 프로세스 필요 없음	기본 프로세스 삭제
		기본 프로세스가 분석 대상 업무 영역에 속하지 않음	해당 업무 영역으로 이동
2	정보 항목이 7개 이상의 기본 프로세스에서 사용됨	정보 항목이 너무 큼	정보 항목의 세분화 필요
3	정보 항목을 생성하는 기본 프로세스가 없음	기본 프로세스의 누락 정보 항목이 필요 없음 정보 항목이 분석 대상 업무 영역에 속하지 않음	기본 프로세스의 도출 정보 항목 삭제 해당 업무 영역으로 이동
4	정보 항목을 생성하는 기본 프로세스가 둘 이상 존재	기본 프로세스의 중복	기본 프로세스의 합성
5	엔터티를 삭제하는 기본 프로세스가 없음	기본 프로세스의 누락	기본 프로세스의 도출
		업무에 삭제가 존재하지 않음	전산상의 오류인 경우에 삭제가 필요한지 확인
		기본 프로세스가 분석 대상 업무 영역에 속하지 않음	해당 업무 영역으로 이동
6	정보 항목을 삭제하는 기본 프로세스가 둘 이상 존재	기본 프로세스의 중복	기본 프로세스 합성
7	정보 항목이 생성만 되고 사용되는 곳이 없음	기본 프로세스의 누락	기본 프로세스의 도출
8	기본 프로세스가 정보 항목을 조회만 함	기본 프로세스가 아님	모듈 검토
9	기본 프로세스가 여러 액션을 수행함	정의된 기본 프로세스가 너무 큼	프로세스 추가 분해

 

 

정보 요구/업무 기능 상관분석

■ 매트릭스 분석

매트릭스가 완료된 후 다음 질문을 통해 행과 열을 분석한다.

• 모든 업무 기능은 정보 항목과 연관이 있는가?
• 각 정보 항목은 적어도 한번 이상의‘C’(Create)를 갖는가?
• 생성된 정보 항목은 다른 업무 기능에 의해 사용( ‘U’)되는가? 이것은 정말 단순조회인가?

■ 정보 항목과 연관성이 없는 업무 기능은 관련 팀과의 협의 하에 업무 기능 도출의 적절성이나 관련 정보 항목을 다시 파악해야 하며, 이를 바탕으로 매트릭스를 보완한다.

■ 정보 항목에 매핑이 없는 업무 기능의 경우 관련 팀과 협의하여 정보 요구 사항 보유 여부를 확인한 후 추가적인 정보 요구 사항이 있을 경우 정보 요구 조사 프로세스에 따라 정보 요구 목록에 신규로 추가한다.

 

정보 요구/조직 기능 상관분석

■ 매트릭스 분석

• 모든 업무 기능은 정보 항목과 연관이 있는가?
• 각 정보 항목은 적어도 한번 이상의‘C’(Create)를 갖는가?
• 생성된 정보 항목은 다른 업무 기능에 의해 사용( ‘U’)되는가? 이것은 정말 단순조회인가?

■ 정보 항목의 활용도를 파악할 수 있으며, 정보 항목의 수요가 많은 경우에는 해당 정보 항목의 물리 모델링 단계에 성능/활용 측면의 모델링 기법을 적용함으로써 정보 활용의 효율성을 기한다.

■ 정보 항목을 생성하는 조직 단위가 복수로 존재할 경우 데이터 관리의 복잡성으로 인해 향후 문제가 발생할 수 있으므로 해당 정보 항목에 대한 데이터 관리 주체의 선정에 주의를 기울인다.

 

 

(DA가이드 2.4.3) 정보 요구 보완 및 확정

 

정보 요구 보완

애플리케이션 기본 프로세스 대 정보 요구 사항, 업무 기능 대 정보 요구 사항, 조직 대 정보 요구 사항 매트릭스 분석을 통해 파악된 추가 및 삭제 정보 요구 사항에 대하여 담당자와 구체적인 미팅을 실시하고, 일정 계획시 설정된 반영 계획에 따라 정보 요구 목록을 보완한다.

 

정보 요구 확정

보완된 정보 요구 사항에 대하여 재차 사용자 재검토를 실시하며, 추가 반영 사항에 대한 반영 여 부 의사결정을 실시한 후 최종 정보 요구 목록에 대한 확정을 실시한다. 정보 요구 목록을 통해 향후 데이터 모델과 관련된 모든 산출물을 추적할 수 있으므로 누락된 항목 없이 정확하게 작성한다.

 

DA 가이드·글이 도움이 되셨다면

 

https://bluedata2050.tistory.com/109

DA가이드 3과목 데이터 표준화

 

 

https://bluedata2050.tistory.com/110

DA가이드 1과목 전사이키텍처 이해

 

 

DA가이드 1과목 2과목 3과목 4과목-1 4과목-2 5과목 6과목