DB엔지니어링(1)

728x90

데이터 요구사항

업무의 개선 사항이나 신규 개발 사항
시스템을 통해 기능상의 목적을 달성하기 위하여 필요한 데이터에 관한 모든 사항을 요청하는 내용

1. 데이터 요구사항 수집 원천
- 발주자의 제안요청서
- 사업자의 제안서
- 제안 평가 및 사업자 선정과 계약 후에 사업수행계획서
- 현행 시스템 관련 문서
- 이해관계자와의 인터뷰
- 워크숍 등
2. 데이터 요구사항 프로세스(추출 → 분석 → 명세 → 검증)
- 수집된 데이터의 요구사항을 분석, 상세화
- 이를 바탕으로 요구사항 명세서를 작성
- 명확성, 정확성, 추적 가능성 등 기준에 적합한지 검증하는 절차
- 사업 종료 시까지 WBS의 기초가 된다.
- (1) 데이터 요구사항 추출
  - 고객이 현재 가지고 있는 문제점과 시스템이 수행하기를 원하는 데이터 요구사항을 정확하게 추출
  - (가) 요구사항 식별 및 수집
    - 개발할 시스템에 대한 사용자 요구와 시스템 제약 사항을 식별
    - 이 중에서 데이터와 관련된 데이터 요구사항을 수집하는 과정
  - (나) 대상 도메인 조사 분석
    - 해당 조직의 비즈니스 목표와 이를 달성 하기 위한 데이터 요구사항을 추출
- (2) 데이터 요구사항 분석
  - 이해관계자로부터 추출된 비정형적이고 불완전한 추상적 요구사항을 요구사항 명세서가 생성되기 이전에 완전하고 일관성 있는 요구사항으로 만들기 위한 단계
  - 올바른 요구사항을 획득하기 위한 과정이다.
  - (가) 문제 영역 분석
    - 시스템 이해관계자들 사이에 불일치하는 문제 영역을 이해관계자별로 정리하고 이를 통합·조정
  - (나) 요구사항 구조화
    - 추상적 요구사항을 상세한 요구사항으로 분해
    - 큰 기능을 세부적으로 분해하면서 각 세부 기능에 필요한 데이터 요구사항이 무엇인지 추출
  - (다) 요구사항 모델링
    - 기능 흐름도(DFD)를 이용하는 구조적 분석 방법
    - UML을 이용하여 분석하는 객체 지향 분석 방법
    - E-R 다이어그램을 이용하는 분석 방법
- (3) 데이터 요구사항 명세
  - 요구사항을 정확하고 완전하게 작성하는 것
  - 요구사항을 적정한 수준으로 상세하게 또는 구체적으로 표현
  - 모든 시스템 이해관계자가 이해 할 수 있도록 작성
  - (가) 데이터 요구사항 명세 장점
    - 1) 고객과 개발자 간의 프로젝트 수행 목적에 대하여 공유
    - 2) 개발 일정과 비용 산출의 근거를 제공
    - 3) 오류 검증과 확인을 위한 기본적인 자료를 제공
  - (나) 데이터 요구사항 명세 원리
    - 요구사항 명세서는 사용자와 개발자 사이의 의사소통 수단
    - 명세서에 표현된 내용이 모호하면 해석의 차이가 발생할 수 있으므로 정확하게 기술하는 것이 중요
    - 요구사항 명세서가 가져야 하는 품질 속성
      - 명확성, 정확성, 완전성, 검증 가능성, 일관성, 수정용이성, 추적 가능성, 개발 후 이용성 등
- (4) 데이터 요구사항 검증
  - 사용자 요구가 요구사항 명세서에 올바르게 기술되었는가를 검토하는 활동
  - 요구사항을 확정하여 이후 설계 및 개발, 테스트 단계의 기준을 만드는 단계
  - (가) 타당성 검증
    - 정의된 요구사항의 실현 가능성,
    - 요구사항 표현의 정확성, 완전성, 표준과의 일치성,
    - 요구사항의 충돌, 기술적 결함 등에 대한 검증을 수행
  - (나) 구조 검증
    - 사용자의 요구와 목표를 만족하는가에 대한 확인
    - 각 단계별 명세 요건들이 정확하고 완전하게 정의되었는가를 조사
    - 요구사항들 간에 정확성과 완전성 및 일치성을 확립

데이터 요구사항 분석 및 정제

1. 구조적 분석

1. 자료 흐름도(DFD, Data Flow Diagram)
- 기능을 중심으로 이에 필요한 자료와 흐름 및 변화 과정을 정해진 도형을 사용하여 기술
- 자료 흐름도는 기능과 자료의 흐름을 큰 기능부터 시작하여 단계별로 세부적인 기능과 자료의 흐름을 하향식으로 기술
- 자료 흐름과 기능을 동시에 모델링하는 데 적합
2. 자료 사전(DD, Data Dictionary)
- 자료 흐름도에 있는 자료를 정해진 표기법에 따라 체계적으로 정의 및 설명을 작성
- 시스템 관련자가 쉽게 이해할 수 있도록

3. 소단위 명세서(Mini-Specification)
- 단계적으로 상세화된 자료 흐름도에서 최하위 단계 프로세스의 처리 절차를 기술
  - 자료 흐름도(DFD)를 지원하기 위하여 구조적 언어, 의사 결정표(판단 표) 등을 이용하여 기술
    - 구조적 언어는 자연어의 일부분
      - 한정된 단어와 문형, 제한된 구조를 사용하여 명세서를 작성하는 데 이용
    - 의사 결정표(Decision Table)는 복잡한 의사 결정 논리를 기술하는 데 사용
      - 주로 자료 처리 분야에서 이용

2. 객체 지향 분석

1. 기능 모델링
- 시스템의 기능적인 측면을 시스템을 사용하는 액터(Actor)와 시스템의 유스케이스(Usecase)로 나누어 요구사항을 분석하는 기법
- (1) 유스케이스 모델 구성 요소
- (2) 유스케이스 모델 관계
2. 객체 모델링
- 문서 및 현행 시스템 분석을 통해 수집한 요구사항으로부터 시스템에 필요한 객체를 추출
- 객체를 추상화하여 클래스(Class)의 속성과 오퍼레이션(Operation), 클래스 간의 관계를 표시하는 기법
- 클래스 다이어그램 개념
  - 객체 지향 소프트웨어 시스템의 기본 단위인 클래스를 식별
  - 클래스 간의 정적인 협력 관계를 정의하여 시스템을 이해하기 위한 기법
  - 요구사항 분석 단계와 설계 단계에서 여러 번 클래스 다이어그램을 작성하면서 구체화
- 클래스 정의
  - 현실 세계에 존재하는 사물, 개념 등을 추상화하여 개별적인 속성과 상태를 가진 객체를 생성하는 틀
- 클래스 관계 정의
  - 일반적인 의미의 연관 관계
  - 한 클래스가 다른 클래스에 영향을 미치는 의존 관계,
  - 전체와 부분을 나타내는 집합 관계,
  - 다른 클래스의 속성과 오퍼레이션을 물려받는 상속 관계
3. 동적 모델링
- 시스템 내부 관점에서 객체들의 상호 작용을 시간, 동작의 순서대로 또는 상태의 변화로 동적인 측면을 표시하는 모델링
- (1) 순서 다이어그램(Sequence Diagram)
  - 유스케이스가 어떻게 사용되는가를 객체 간의 상호 작용을 통해 시간의 순서에 맞는 메시지의 흐름으로 표시하는 동적인 다이어그램
- (2) 상태 다이어그램(State Diagram)
  - 클래스의 상태 변화를 이벤트에 대한 반응으로 해석하여 상태 간 이동을 통해 내부 동적인 내용을 표시하는 다이어그램