[데이터 아키텍처 준전문가(DAsP)] 과목 2. 데이터 요건 분석 (2)

[3장] 정보 요구사항 분석

1. 분석 대상 정의

1) 현행 업무 분석 대상 정의

항목	내용
분석 대상 자료	• 현행 업무 흐름도 • 현행 업무 설명서 • 현행 업무 분장 기술서
분석 대상 업무 영역 선정	• 분류 기준에 따라 현행 업무 목록 작성 • 분류 기준 : 통상적으로 현행 업무 기능 분해도의 단위 업무 또는 업무 분장상의 구분 등을 의미

 

2) 현행 시스템 분석 대상 정의

항목	내용
분석 대상 현행 시스템 선정	• 업무 분석 프로젝트의 수행범위를 정확히 파악하는 것이 선행되어야 함 • 업무 영역x현행 시스템 매트릭스를 바탕으로 업무 영역별 분석 대상 시스템 목록 작성
분석 대상 현행 시스템 관련 자료	[자료 항목] • 현행 시스템 구성도 • 현행 시스템의 분석, 설계 및 개발 보고서 • 화면, 장표 및 보고서 레이아웃 • 현행 시스템 테이블 목록 및 테이블 정의서 • 프로그램 목록 • 사용자 및 운영자 지침서 • 시스템 지원 및 유지보수 이력 • 시스템 개선 요구사항 등 [수집된 문서 평가 기준] • 유용성 : 문서 활용 가능성 여부 • 완전성 : 문서 내용에 누락된 부분이 없는지의 여부 • 정확성 : 문서 내용이 현재 시스템과 일치하는지의 여부 • 유효성 : 문서가 최신의 내용을 반영하고 있는지의 여부
추가적인 분석 대상	• 데이터 뷰는 전체적인 정보 중에서 일부를 바라보는 관점을 나타냄 • 사용자 뷰가 종합되어 나타나는 것이 화면, 수작업 파일, 수작업/전산 양식, 보고서 등의 레이아웃
분석 단계	• 현재 상태 파악 및 요구 정의 • 문제 해결과 구현될 시스템의 목표 도출
명세서 작성 과정	• 완성될 소프트웨어가 어떤 기능을 가져야 하는지 정확히 기술 • 기술적 요구와 구현/운영 측면에 있어서 제약 조건 명시 • 개발자와 사용자각 합의한 성능에 관한 사항 명시 • 명세서는 사용자와 개발자의 계약을 나열한 문서

 

2. 정보 요구사항 상세화

• 현행 업무 영역 및 시스템 관련 자료에 대해 분석하고 사용자의 정보 요구사항을 보완
• 비기능적 정보 요구사항을 포함하여 정보 요구사항 정의서 보완

 

1) 기능적 정보 요구사항

• 외부 요소가 직접적 상호작용을 통해 시스템에 요구하는 기능 또는 서비스
• 시스템이 외부의 데이터나 명령을 받아들여 어떤 반응을 하는지 기술해야 함

 

2) 비기능적 정보 요구사항

• 시스템이 수행하는 기능 이외의 사항
• 시스템이 만족시켜야 하는 제약 조건 (기술적 제약 조건, H/W, S/W와 관련된 제약 조건)
• 시스템이 반드시 만족시켜야 하는 주요 성능 척도 : 반응 시간, 저장 능력, 동시 처리 능력 등
• 요구분석 이후 설계 단계에서 결정해야 할 언어나 플랫폼, 구현의 선택을 까다롭게 할 수 있음
• 비기능적 요구가 만족되지 못하면 시스템 자체가 쓸모없게 될 수 있기에 기능적 요구보다 중요
• 신뢰성, 확장성, 이식성, 보안 중요

 

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

 

✔️수행 절차

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

 

 

✔️ 프로세스 분해/상세화

항목	설명
프로세스 분해	• 하위에 더 이상 업무 기능을 포함하지 않는 단위 업무 기능으로부터 점진적으로 수행 • 단위 업무 기능별로 상세하게 분해하지 않고, 업무 전체 단위에 대해 프로세스 분해 수준에 맞춤 • 업무 기능 계층도를 단위 업무 기능 수준까지 분해한 후 프로세스 도출
프로세스 분해 정도	• 업무적인 특성을 고려하여 3차 수준까지 분해 • 업무 활동 분해의 근본 목적은 최종적으로 기본 프로세스의 도출에 있음 • 초기 작업에는 도출된 프로세스를 균형있게 분해하는데 주의함
프로세스 명칭	• 명명규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하고 이름만으로 파악할 수 있어야 함
프로세스 계층도 ✅	• 기본 프로세스를 도출하기 위해 작성하는 것임 • 프로세스 계층도의 모듈성이 확보되기 위한 분해 기준은 응집도가 높을수록, 결합도가 낮을수록 분석의 복잡도와 모호성이 감소됨 • 높은 응집도 (Cohesion), 낮은 결합도 (Coupling)를 유지하도록 모듈성 확보가 중요 • 일반적으로 상위 프로세스를 포함하며, 하위 프로세스가 7개를 초과하면 상위 프로세스를 분리하는 것을 고려 • 프로세스 정의서 : 프로세스와 기본 프로세스를 함께 기술하는 양식    (데이터 사용 항목은 기본 프로세스에서는 반드시 작성해야 함) • 이미 작성된 계층도를 재검토하여 모든 업무 요건과 규칙이 반영되었는지 확인하고 조정 • 현 수준의 프로세스 계층도를 더욱 상세하게 분해하여 업무 최소 단위인 기본 프로세스까지 도출해냄
정보 항목 도출 및 표준화	• 도출한 기본 프로세스 별로 등록(C), 조회(R), 변경(U), 삭제(D)로 구분 • 기능에 따라 구분된 프로세스별로 정보 요구사항 정의서 및 업무 조사서 상의 내용을 파악하여 관리하고자 하는 항목 도출 • 서술식 자료에서 명사형 단어를 파악하면 정보 항목의 대상이 되는 경우가 많음 • 명명 규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하며, 명사형으로 기술 • 도출된 정보 항목에 대해 그룹화하여 정보 항목 군으로 구분하고 정보 항목 목록 작성
정보 항목별 통합성/분리성 여부 검토	• 정보 유형/항목별로 전사 관점에서의 통합/분리 여부 검토 • 동일한 정보 통합 시, 정보 항목의 관리가 용이하고 통합 정보 유형으로 수용 가능함 • 무리한 통합으로 인한 모호성 존재와 관리 부족으로 통합의 의미 상실 • 통합 작업 후 정보 항목 목록에 대한 통합성 여부를 기재하고 최종 정보 항목 목록 작성

 

 

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

항목	내용
유스케이스 (Use Case) 다이어그램 ✅	• 시스템에서 제공해야 하는 기능이나 서비스를 상세하게 그린 다이어그램 • 사용자와 시스템 사이의 상호작용을 중심으로 나타냄 • 실제 내부의 비즈니스 로직이 아닌 사용자가 수행하는 기능을 파악하고 싶을 때 작성 • 프로젝트를 시작할 때나 제품의 요구사항 명세서를 작성하는 요구분석 단계에서 주로 그림 • 액터(Actor): 시스템과 상호작용하는 외부 엔티티(사람이나 시스템, 하드웨어), 이름과 설명 필요 • 유스케이스(Use case): 액터에게 보이는 시스템의 기능과 외부 동작    - 지식이 없는 사용자와도 쉽게 의사 전달을 위해 자연어로 씀    - 유스케이스 이름, 참여 Actor, 시작 조건, 사건 흐름, 종료 조건 포함 • 액터, 유스케이스, 시스템 범위가 표현됨 (클래스 간의 관계 표현x)
액터와 유스케이스 간의 관계	• 확장(Extend) : 하나의 유스케이스가 다른 유스케이스의 행동을 추가함에 따라 나타나는 관계    - 표현) 점선 화살표, <<extend>> • 포함(Include) : 하나의 유스케이스가 다른 유스케이스를 사용하는 것을 나타내는 관계    - 표현) 점선 화살표, <<include>> • 참가(Commuicate) : 액터가 어떤 유스케이스에 참가함을 나타내며, 액터와 유스케이스 사이의 유일한 관계    - 유스케이스 안에서 일어나는 이벤트를 순서대로 기술하면 시스템 내부에서 일어나는 작업을 더 잘 이해할 수 있음
확장/포함 관계의 차이점	• 확장 관계 : 도움말, 오류, 기타 예외적인 조건 처리 • 포함 관계 : 한정된 개수의 유스케이스들이 공통으로 가지는 기능을 유스케이스로 나타낼 때
유스케이스 상세화	• 사건 흐름을 구조화하는 작업으로 모든 선택 및 대안 흐름을 기술 • 관련은 있지만 사건 흐름에 고려되지 않는 정보 요구사항을 특별요구사항으로 정의 • 정상적인 흐름 기술 후 예외 사항에 대한 사건 흐름을 기술하며 아래의 내용 기술    - 개략적인 설명    - 사건 흐름    - 사전/사후 조건    - 비기능적인 정보 요구사항    - 주된 사건 흐름에 대체될 수 있는 흐름    - 예외 처리 사항
클래스 다이어그램 작성	• 정의 :시스템을 구성하는 클래스의 구조를 나타내고 객체들의 공통 구조와 동작을 추상화 • 목적 : 시스템 구현 시, 어떤 클래스가 필요한지 파악하고 클래스 사이의 관계를 나타냄 • 구성 요소 : 객체, 클래스, 속성, 오퍼레이션, 연관 관계 • 의미 : 객체지향 프로그램의 골격 (클래스 정의)을 나타냄 [엔터티 클래스 도출] • 명사 및 명삭구를 후보 객체로 선정하고 모호한 의미 제거 • 이음동의어/동음이의어를 고려하고 문제 영역과 관련 없는 것을 제거 • 유사한 구조와 행위를 가진 객체들을 그룹화 [관계 및 클래스 도출] • 관계 : 관심 있는 연결을 나타내는 클래스 간의 관계 • 클래스 간의 집단화 관계를 식별하고 명명함 [속성 정의] • 클래스가 나타내는 객체의 특성을 의미 • 속성 이름은 속성이 가지고 있는 정보를 명확하게 지정하는 명사로 해야 함 [클래스 간의 관계] • 연관관계(association) : 클래스 사이의 관계는 링크로 나타냄 (선) • 역할(role) : 연관관계 표시 선분 끝에 역할 표시 (has, exist, rent) • 다중도(multiplicity) : 숫자로 표현, 연관된 링크 갯수, *는 다수를 의미 • 전체/부분 관계(aggregation)    - 전체 개념의 클래스 : Dictionary    - 부분 개념의 클래스 : File    - 일대다인 경우가 많으며, 다이아몬드로 표시 [일반화] • 일반화된 개념의 클래스와 더 구체적인 개념의 클래스 사이의 관계 • 공통 속성과 오퍼레이션을 사용하기 위해 상속 개념으로 클래스를 구성
순서 다이어그램	• 정의 : 시스템 동작을 정형화하고 객체들의 메시지 교환을 시각화 • 목적 : 참여 객체(participating object)를 추가로 찾아내고, 객체 사이의 상호작용 파악 • 구성 요소 : 액터(왼쪽), 객체, 메시지(이름 있는 화살표), 수직선(시간의 흐름) • 의미    - 클래스가 가져야 할 오퍼레이션을 파악하는데 사용    - 객체들 사이의 통신 패턴이며, 사용 사례의 이벤트 흐름을 나타냄
상태 다이어그램	• 정의 : 객체가 갖는 여러 상태와 상태 사이의 전환을 표현 (상태 : 객체가 만족하는 조건) • 목적    - 단일 객체의 동작을 나타냄    - 객체의 상태 변화를 점검하며 빠진 오퍼레이션 점검    - 솔루션 도메인 객체 표현 • 구성 요소 : 원 - 객체의 상태 / 화살표 - 전환(transition) • 의미 : 외부 사건의 결과로 일어나는 단일 객체의 상태 변화에 초점을 둠 (객체의 동작을 구체화)
액티비티 다이어그램	• 액티비티 : 시스템에서 수행되는 작업(오퍼레이션의 집합), 클래스의 메소드 • 정의    - 시스템을 액티비티로 표현    - 액션 상태인 상태 다이어그램    - 액티비티와 전환(transition) 사이의 제어 흐름 • 구성 요소    - 둥근 사각형 : 액티비티    - 화살표 : 다른 액티비티로 전환    - 동기 막대 : 제어 흐름 동기화    - 다이아몬드 : 선택 분기    - 시작, 종료

 

 

3. 정보 요구사항 확인

1) 수행 절차

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

 

2) 수행 작업 내용

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

 

 

3) 수행 작업 지침

항목	내용
재검토 계획 수립	[재검토 대상] • 정보 요구사항 정의서, 정보 항목 목록, 유스케이스 정의서, 클래스 다이어그램 등 [재검토 기준] • 완전성 : 사용자의 정보 요구사항 누락 여부 확인 • 정확성 : 요구사항이 정확히 표현되었는지 확인 • 일관성 : 표준화 준수 여부 확인 • 안정성 : 추가 요구사항 변경에 따른 영향도 파악 [재검토 계획서에 포함되어야 하는 사항] • 정보 요구사항 재검토 개요 및 목적, 재검토 일자, 재검토 장소 및 시간 계획 • 재검토 참석 대상 및 재검토 업무, 참석 대상별 재검토 세부 시간 계획 • 재검토 시 준비물, 재검토 후 산출물, 지적 사항 반영 계획 수립
재검토 실시
보완 결과 확인

 

 

4) 수행 시 고려 사항

• 일관성 있는 기준 및 일정 수립 → 공감대 형성 중요
• 세션별로 해당 기준에 초점을 맞추어 수행하며, 효율성을 고려하여 참여 대상 수 선정

 

4. 정보 요구 분석 방법

1) 구조적 분석 방법

항목	내용
구조적 분석 관점	• 시스템을 기능적 관점에서 다룸 • 소프트웨어 시스템을 거시적 관점에서 데이터와 데이터를 처리하는 프로세스로 봄 • 데이터보다 처리, 기능을 위주로 분석 • 문제를 기능적 관점의 프로세스로 나누고, 프로세스에 어떤 입력자료와 출력자료가 필요한지 나중에 고려 • 프로세스는 추상적인 개념부터 점차적으로 세분화함
구조적 분석 방법	• 전통적인 데이터 처리 시스템을 개발하는데 적절한 기법 • 목표 : 개발될 시스템의 모형을 만드는 것    - 프로세스와 사이의 데이터 흐름 파악 중요    - 자료 흐름과 가고오 절차를 그림 중심으로 표현    - 시스템을 구성하는 요소들의 상호 작용과 기능을 나타냄
구조적 분석 방법의 가정	시스템의 기능 및 프로세스가 무엇인지 생각 • 시스템이 무엇을 하는지 • 기능이나 프로세스는 입력 자료 흐름을 출력 자료 흐름으로 변환하는 액티비티 하향식으로 문제를 다룸 • 외부 인터페이스를 먼저 분석 → 상위층 기능 → 하위층 기능 순서로 문제 분할
구조적 분석 방법의 작업 순서	배경도 작성 → 상위 자료 흐름도 작성 → 하위 자료 흐름도 작성 → 자료 사전 작성 → 소단위 명세서 작성
구성요소	• 프로세스 : 프로세스는 대부분 원 또는 둥근 사각형으로 표기    - 프로세스의 이름을 안에 씀 • 자료 흐름 : 두 프로세스 사이의 자료 경로는 화살표로 표기    - 화살표 위에 자료의 이름을 씀 • 파일 또는 저장소 : 정보의 저장소는 한쪽이 열린 직사각형으로 표시    - 파일에 접근하는 프로세스는 선으로 연결하여 표시    - 파일의 이름을 안에 표시 • 자료 출처와 도착지 : 직사각형 안에 이름 기재
최상위 자료 흐름도 (배경도)	• 작업은 시스템 경계의 입출력 식별로부터 시작    - 최상위 단계의 입출력은 시스템 경계를 정의하는 것으로 분석의 대상이 무엇인가를 결정 • 최상위 흐름도를 여러 부 프로세스들로 구체화    - 자료원과 도착지 나타낼 필요 없음    - 각 프로세스는 고유 번호가 붙여짐 • 상위 자료 흐름도 구체화    - 하위 계층 자료 흐름도에서 프로세스 번호는 바로 위 계층의 프로세스 번호에 고유 번호를 붙이면 됨
프로세스	• 원으로 표현, 입력 자료 흐름을 출력 자료 흐름으로 변환 • 처리 이름 : 하는 일을 의미하는 단어나 간단한 문장으로 동사구문 사용    - 동사형 명사와 단일 직접 목적어 • 레벨별 고유번호 주어짐    - 최하위 프로세스는 차후 소단위 명세의 대상

• •  

 

✔️ 자료 흐름도의 작성 원칙

항목	내용
자료 보존의 원칙 (Conservation Rule)	• 출력 자료 흐름은 반드시 입력 자료 흐름을 이용해 생성된 것이어야 함 ex) 사과가 주스에 들어가면 사과주스가 나와야 함
최소 자료 입력의 원칙 (Parsimony Rule)	• 출력 자료 흐름을 산출하는데 반드시 필요로 하는 최소의 자료 흐름만 입력해야 함
독립성의 원칙  (Independence Rule)	• 자신의 입력 자료와 출력 자료 자체에 대해서만 알면 됨 • 그 자료들이 어디에서 와서 어디로 가는지 알 필요 없음
지속성의 원칙  (Persistence Rule)	• 처리는 항상 수행하고 있어야 하며 일시적으로 어떤 자료 흐름을 기다릴 때를 제외하고는 다시 시작하거나 멈춰서는 안됨
순차 처리의 원칙 (Ordering Rule)	• 입력 자료 흐름의 순서는 출력되는 자료 흐름에서도 지켜야 함
영구성의 원칙  (Permanence Rule)	• 자료 흐름의 자료 항목은 처리된 후에 제거되지만, 자료 저장소의 자료는 입력으로 사용해도 제거되지 않음
자료 변환의 원칙  (Nature of Change)	• 자료 본질의 변환 : 입력 자료 흐름에 편집, 계산 등을 해 출력 자료 흐름을 산출 • 자료 합성의 변환 : 여러 입력을 처리하여 하나의 출력되는 자료 흐름을 산출

 

• 과도하게 세분화된 프로세스 → 적당한 세분화 필요
• 자료 흐름의 올바른 이름 표기

 

2) 객체 지향 분석 방법

• 데이터와 데이터에 적용될 기능을 함께 추상화하는 방법
• 시스템에 존재하는 객체를 먼저 찾아내고, 객체 안에 어떤 자료와 오퍼레이션이 필요한지 알아내야 함
• 객체 사이에 존재하는 여러 가지 관계들의 파악이 중요

 

3) 요구 분석 명세서

항목	내용
요구 분석서가 갖추어야 할 사항	• 사용자, 개발자가 모두 쉽게 이해해야 함 • 기술된 조건은 쌍방이 모두 동의한 것이어야 함 • 제안된 시스템에서 수행될 모든 기능을 정확히 기술하고 모든 제약 조건을 명시    - 반응 시간, 목표 하드웨어, 비용 한계, 사용자 특성, 언어 • 시스템 인수를 위한 테스트 기준이 있어야 함 • 시스템 품질 측정 방법이 있어야 함
요구 분석의 문제점	• 사용자의 부정확한 요구 표명 • 잦은 요구 변경 • 커뮤니케이션상의 장애 • 시스템의 복잡도
명세서의 평가	[평가 기준] • 무결성과 완벽성 • 일관성 • 명확성 • 기능적 • 검증 가능성 • 추적 가능성 및 변경 용이성 [평가 방법] • 검토 회의 • 테스트 사례 작성 • 프로토타이핑 도구나 CASE 도구 사용

 

 

[4장] 정보 요구 검증

1. 정보 요구 상관관계 기법

도출된 정보 요구사항을 다른 영역 (기능, 프로세스, 조직 등)과 비교, 분석함으로써 정보 요구사항의 도출이 효과적으로 이루어졌는지 파악할 수 있음

 

1) 주체별 분류

항목	내용
요구사항 분석가 수행	• 요구를 수집/분석한 주 담당자를 기준으로 검토 기준 항목을 마련 후 분석 수행 • 정보 요구사항을 도출한 분석가에 의해 수행되므로 객관성 저하의 문제점이 발생할 수 있음 • 도출 절차 및 업무팀과의 의사소통이 원활하므로 상관분석이 원활하게 진행될 수 있음 • 요구 사항 분석가의 업무 이해도가 높으므로 정확한 분석 가능성이 높음
품질보증 팀 수행	• 요구사항 분석가보다 업무 이해도가 낮으나 상관분석 작업의 수행을 통한 업무 이해도를 높일 수 있으며, 전체적인 인터페이스 검증에 용이 • 낮은 업무 이해도로 인해 분석을 통한 단점을 지적하여 수정하기 어려움
외부 감리 수행	• 업무 파악에 한계가 있으나 제3자의 시각으로 검토 가능 • 상관분석의 객관성을 극대화할 수 있음 • 프로젝트 내부 인력 지원이 효과적이지 않을 경우, 잘못된 분석 결과를 초래할 수 있음
정보 요구/어플리케이션 상관분석 ✅	• 정보 요구사항에서 도출된 항목과 어플리케이션 영역에서 도출된 항목으로 매트릭스 작성 • 기본 프로세스의 액션 (C:생성, R:조회, U:수정, D:삭제) 정의 • 여러 개의 액션 발생 시, '우선순위 ‘C>D>U>R’에 따라 하나만 기록 • 모든 정보 항목이 모든 기본 프로세스에서 사용되었는지, 또는 모든 정보 항목을 사용하는지 확인 • 2가지 객체 중 하나의 누락은 분석이 가능하지만, 정보 항목과 기본 프로세스가 모두 누락인 경우 분석 불가
정보 요구/업무 기능 상관분석	• 정보 요구사항과 비즈니스 아키텍처에서 도출된 업무 기능을 비교하여 분석 • 업무 기능별 필요 정보 항목의 누락 여부의 확인 중요 • 행 : 정보 요구사항에서 도출된 내용 • 열 : 가치 사슬 분석 등 기법을 통해 도출된최하위 수준의 전사 업무 기능 • 생성/수정/삭제 : C로 표시 • 검색 : U로 표시 • 아무 관련 없는 것은 빈칸

 

 

2. 추가 및 삭제 정보 요구사항 도출

1) 정보 요구/어플리케이션 상관분석

• 어플리케이션 충족도 분석 매트릭스
  • 정보 항목을 생성하는 기본 프로세스가 반드시 존재해야 함
  • 상태를 종료시키는 기본 프로세스가 존재해야 함
  • 생성된 항목은 조회, 수정, 삭제 액션 중 하나가 발생해야 함
  • 하나의 정보 항목의 프로세스의 합은 7개를 초과하지 않아야 함
  • 수작업 정의나 조회 전용의 특별 정의된 기본 프로세스 외에는 반드시 생성, 수정, 삭제 액션 중 하나를 수행해야 함
• 매트릭스 분석 ✅
  

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

 

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

• 매트릭스 분석
  • 모든 업무 기능은 정보 항목과 연관이 있는지?
  • 각 정보 항목은 한 번 이상의 ‘C(Create)’를 갖는지?
  • 생성된 정보 항목은 다른 업무 기능에 의해 ‘U(Update)’가 사용되는가?
  • 단순 조회인지?
• 정보 항목과 연관성이 없는 업무 기능은 기능 도출에 대해 재검토 필요
• 정보 항목에 매핑되지 않는 업무 기능은 협의하여 추가사항이 있을 경우 신규로 추가

 

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

• 매트릭스 분석
  • 모든 조직은 정보 항목과 연관이 있는지?
  • 각 정보 항목은 한 번 이상의 ‘C(Create)’를 갖는지?
  • 생성된 정보 항목은 다른 조직 기능에 의해 ‘U(Update)’가 사용되는가?
  • 단순 조회인지?
• 정보 항목의 활용도를 파악할 수 있으며, 항목의 수가 많은 경우 물리 모델링 단계에서 성능/활용 측면의 모델링 기법을 적용함으로써 정보 활용의 효율성을 기해야 함
• 정보 항목을 생성하는 조직이 여러 개일 경우, 관리의 복잡성 때문에 향후 문제 발생의 소지가 있으므로 데이터 관리 주체 선정에 주의해야 함

 

3. 정보 요구사항 보완 및 확정

• 정보 요구 보완
  • 분석을 통해 파악된 추가 및 삭제 요구사항에 대해 담당자와 미팅을 통해 정보 요구 목록 보완
• 정보 요구 확정
  • 보완된 사항에 따라 재검토를 하며 추가 반영사항에 대해 최종 정보 요구 목록에 대해 확정