[DAP] 과목 2 정보 요구 사항 개요 - 제 3장, 제 2절 정보 요구 사항 상세화

DAP(Data Archtecture Professional) 책을 통해 내가 공부한 내용을 요약한 것 

 

제 3장 - 정보 요구 사항 분석

---

제1장 정보 요구 사항 개요

제 2장 정보 요구 사항 조사

제 3장 정보 요구 사항 분석

제 4장 정보 요구 사항 명세화

제 3장 정보 요구 사항 검증 및 변경 관리

---

제 1절 분석 대상 정의

제 2절 정보 요구 사항 상세화

제 3절 정보 요구 사항 확인

---

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

  프로세스는 실제로 업무가 수행되는 행위를 뜻한다.

프로세스는 시작 지점과 종료 시점이 명확하고 실행 횟수를 셀 수 있는 업무 활동을 의미한다.

프로세스는 입력(Input)과 출력(Output)이 있으며, 입력을 출력으로 바꾸는 변환 과정을 포함한다.

프로세스를 분해하다보면 더이상 분해되지 않는 최소 단위의 업무를 찾게되는데, 이를 기본프로세스 라고 한다.

 

* 수행 절차

1) 프로세스 중심으로 정리된 업무 조사서를 바탕으로 프로세스 계층도, 프로세스 정의서를 작성한다.

2) 도출된 기본 프로세스를 기준으로 기본 로직이 필요한 경우 기본 로직을 정리한다.

3) 표준화 과정을 통하여 사용자의 정보 요구 사항을 충족하는 정보 항목 목록을 정의한다.

 

* 수행 작업 지침

 

* 프로세스 분해 상세화

1) 프로세스 분해의 분해

  - 프로세스의 분해는 단위 업무 기능으로부터 출발하여 점진적으로 수행한다.

  - 업무 기능 계층도가 단위 업무 기능 수준까지 분해되지 않았을 경우에는 단위 업무 기능 수준까지 더 분해한 후 프로세스를 도출한다.

 

2) 프로세스 분해 깊이

  - 3차 수준까지 프로세스를 도출하며, 그 과정에서 기본 프로세스까지 도출될 수 있다., 업무 활동 분해의 근본적인 목적은 최종적으로 기본 프로세스 도출에 있다.

  - 도출할 프로세스의 대상은 일반적으로 데이터의 상태를 변화시키는(생성, 수정, 삭제) 것만으로 한다.

  - 대상 범위의 모든 프로세스를 균형있게 분해하는 데에 주의를 기울인다.

 

3) 프로세스 명칭

  - 명명 규칙을 준수하며, 이름만으로도 개략적인 수행 내용의 파악이 가능하도록 함축적이며 유일한 이름을 부여 한다.

 

4) 프로세스 계층도

   - 목적은 기본 프로세스 도출에 있으며, 높은 응집도와 낮은 결합도를 유지하도록 모듈성을 확보하는 것이 중요하다.

  - 일반적으로 상위 프로세스에 포함되는 하위 프로세스가 7개를 초과하면 상위 프로세스를 분리하는 것을 고려한다.

  - 프로세스 별 정의(설명)은 업무를 구체적으로 이해할 수 있는 수준으로 상세하게 작성한다.

 

  예) 프로세스 계층도의 예

1차 기능	2차 기능	3차 기능	4차 기능
여신관리	여신 기획 관리	여신 요율 책정
		연간 여신 운용 지침 수립
	여신 상담 관리	거래처 정보 관리	거래처 정보 등록
			신용 정보 관리
		여신 상담	대상 거래 파악
			상담 결과 보고
			신용 조사 의뢰
		대출 의향서 발급	대출 의향서 발급 신청
			대출 의향서 발급 승인

 

  예) 프로세스 정의서의 예

2차 업무 기능	3차 업무 기능	설명
지점 관리		지점의 신설, 이전, 폐쇄 등에 따른 처리와 지점이 보유한 채권철의 관리
	등기 등록 관리	지점 신설, 지점 이전, 인장 등에 관한 등기, 등록 업무
	채권철 관리	채권철 보존, 관리, 폐기 등에 관한 업무 처리 과정
안전 관리 기획		보안, 소방, 경비 업무에 대한 계획 수립
	계획 수립	비상 계획, 보안, 소방, 경비 업무의 계획 수립
	규정 관리	보안, 소방, 경비 규정 및 기계 경비 운영 요령 관리

 

 

* 정보 항목 도출 및 표준화

1) 프로세스 분해 및 상세화에서 도출한 기본 프로세스별로 등록(C), 조회(R), 변경(U), 삭제(D) 기능을 구분하여 기술한다.

2) 기능에 따라 구분된 프로세스별로 정보 요구 분석에서 정의된 정보 요구 사항 정의서 및 업무 조사서상의 내용을 파악하여 관리하고자 하는 정보 항목을 도출한다.

3) 도출한 정보 항목은 명명 규칙을 준수하여 명명하며, 명사형으로 기술

 

* 정보 항목별 통합성 검증

정보 유형별 및 정보 항목별 전사 관점에서 통합/분리 여부 검토한다.

2) 장점 : 통합 정보 항목으로 도출 시 정보 항목의 관리가 용이

3) 단점 : 무리한 통합 작업으로 인한 정보 항목의 애매모호성 존재

 

---

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

  객체지향 방법론에서는 유스케이스 다이어그램을 중심으로 정보시스템의 기능적 정보 요구 사항을 정의한다.

 

* 유스케이스 다이어그램

1) 액터(Actor)

  - 정보시스템과 상호 작용하는 개인, 그룹, 회사, 조직, 장비 등 정보 서비스를 받는 객체를 의미

2) 유스케이스 (Usecase)

  - 도출된 액터별로 개발 시스템에서 제공해야 하는 기능을 나타낸다.

  - 사건 흐름에 대한 개요

3) 액터와 유스케이스 간의 관계

  - 확장(Extend) : 하나의 유스케이스가 다른 유스케이스의 행동을 추가함에 따라 나타나는 두 유스케이스의 관계를 말한다.

  - 포함(Include) : 하나의 유스케이스가 다른 유스케이스를 사용함을 나타내는 두 유스케이스의 관계를 말한다.

  - Commuicates : 행위자가 어떤 유스케이스에 참가함을 나타낸다.

 

* 유스케이스 다이어그램 예시

출처 : 깃마인드 ( https://gitmind.com/kr/use-case-diagram.html)

* 유스케이스 상세화

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

 

* 클래스 다이어그램 작성

  1) 엔터티 클래스 도출

    - 유스케이스 모형을 검토하여 문제 영역 내의 개념을 나타내 엔터티 클래스를 도출하여 정의한다.

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

    - 관계란 의미 있고 관심 있는 연결을 나타내는 클래스 간의 관계를 의미

  3) 속성정의

    - 속성이란 클래스가 나타내는 객체의 특성을 의미한다.