[DAP 전문가 가이드] 2.3.2 정보 요구 사항 상세화

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

수행 절차

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

수행 작업 내용

<프로세스 관점의 정보 요구 상세화>

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

 

수행 작업 지침

1. 프로세스 분해 / 상세화
   • 프로세스의 분해
     • 프로세스의 분해는 단위 업무 기능으로부터 출발하여 점진적으로 수행한다.
     • 단위 업무 기능별로 상세하게 프로세스를 분해하지 않고, 해당 업무 영역의 전체 단위 업무 기능에 대하여 프로세스의 분해 수준을 맞추어 점진적으로 분해한다.
     • 업무 기능 계층도가 단위 업무 기능 수준까지 분해되지 않았을 경우에는 단위 업무 기능 수준까지 더 분해한 후 프로세스를 도출한다.
   • 프로세스 분해 깊이
     • 프로세스 분해 시 업무적인 특성을 고려하여 분해의 수준은 3차 수준까지 분해한다.
     • 3차 수준까지 프로세스를 도출하는 과정에서 기본 프로세스 수준까지 도출되는 경우도 있으며 업무 활동 분해의 근본적인 목적은 최종적으로 기본 프로세스의 도출에 있다.
     • 그러나 초기 작업에서는 도출된 프로세스가 기본 프로세스인지는 중점을 두지는 않으며, 대상 범위의 모든 프로세스를 균형 있게 분해하는 데에 주의를 기울인다.
     • 도출한 프로세스의 대상은 일반적으로 데이터의 상태를 변화시키는(생성, 수정, 삭제) 것만을 프로세스로 정의한다. 하지만 업무적으로 중요한 의미를 가지는 조회용 프로세스 또는 수작업 프로세스는 필요에 따라 명명 규칙을 달리하여 도출하는 것도 바람직하다.
   • 프로세스 명칭
     • 명명 규칙을 준수하여 명명하되 업무 용어를 그대로 사용하고 이름만으로도 개략적인 수행 내용의 파악이 가능하도록 함축적이며 유일한 이름을 부여하는 것이 중요하다.
   • 프로세스 계층도
     • 프로세스 계층도를 작성하는 목적이 기본 프로세스의 도출에 있으며, 추후 업무적으로 기술한 프로세스 정의서를 바탕으로 작업을 수행하게 되므로 이에 대한 상세한 내용이 반영된다.
     • 프로세스 계층도는 높은 응집도 및 낮은 결합도를 유지하도록 모듈성을 확보하는 것이 중요하다. 이러한 원칙에 따라 분석하면 분석의 복잡도와 모호성이 감소되고 분석의 집중력이 향상되어 프로젝트 관리 및 프로세스 유지 보수가 용이하다.
     • 프로세스별 정의(설명)는 업무를 구체적으로 이해할 수 있는 수준으로 상세하게 작성한다.
     • 이미 작성된 프로세스 계층도를 재검토해 해당 업무 영역에 포함되는 모든 업무 요건 및 업무 규칙이 반영되었는지를 확인하고, 프로세스 계층도를 조정한다.
     • 현 수준의 프로세스 계층도를 더욱 상세하게 분해하여 업무의 최소 단위인 기본 프로세스까지 도출한다.
2. 정보 항목 도출 및 표준화
   • 프로세스 분해 및 상세화에서 도출한 기본 프로세스별로 등록(C), 조회(R), 변경(U), 삭제(D) 기능을 구분하여 기술한다.
   • 기능에 따라 구분된 프로세스별로 정보 요구 분석에서 정의된 정보 요구 사항 정의서 및 업무 조사서 상의 내용을 파악하여 관리하고자 하는 정보 항목을 도출한다.
   • 도출한 정보 항목은 명명 규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하며, 명사형으로 기술한다.
3. 정보 항목별 통합성 검증
   • 정보 유형별 및 정보 항목별로 전사 관점에서의 통합/분리 여부를 검토한다.
   • 통합 작업 후 해당 정보 항목 목록에 대한 통합성 여부를 기재하고 최종 정보 항목 목록을 작성한다.

 

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

유즈케이스 다이어그램

• 액터
  • 정보시스템과 상호 작용하는 개인, 그룹, 회사, 조직, 장비 등 정보 서비스를 받는 객체를 말한다.
  • 액터의 이름은 명확하게 액터의 역할을 나타내는 이름으로 정의한다.
• 유즈케이스
  • 도출된 액터별로 개발 시스템에서 제공해야 하는 기능을 나타낸다.
  • 사건 흐름에 대한 개요를 간략하게 기술한다.
• 액터와 유즈케이스 간의 관계
  • 확장(Extend) : 하나의 유즈케이스가 다른 유즈케이스의 행동을 추가함에 따라 나타나는 두 유즈케이스의 관계를 말한다. 하나의 유즈케이스가 다른 유즈케이스를 경우에 따라 선택적으로 수행하는 경우에 사용된다.
  • 포함(Include) : 하나의 유즈케이스가 다른 유즈케이스를 사용함을 나타내는 두 유즈케이스의 관계를 말한다. 하나의 유즈케이스가 다른 유즈케이스를 반드시 수행하는 경우에 사용된다.
  • Communicates : 행위자가 어떤 유즈케이스에 참가함을 나타낸다. 이것은 행위자와 유즈케이스 사이의 유일한 관계이다.

 

유즈케이스 상세화

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

- 사건 흐름을 기술할 때 정상적인 흐름에 대해 먼저 기술한 후 예외 사항에 대한 사건 흐름을 기술한다.

 

기술 내용

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

 

클래스 다이어그램 작성

1. 엔터티 클래스 도출
   • 유즈케이스 모형을 검토하여 문제 영역 내의 개념을 나타내 엔터티 클래스를 도출하여 정의한다.
   • 식별된 클래스에 이름을 부여하고, 간략한 설명을 기술한다.
   • 클래스 이름은 간결하고 업무적 의미를 함축한 단수형 명사로 부여하며, 은어 및 약어 사용은 배제한다.
2. 관계 도출 및 클래스 도출
   • 관계란 의미 있고 관심 있는 연결을 나타내는 클래스 간의 관계를 의미한다. 클래스 간의 집단화 관계를 식별하고 명명한다.
3. 속성 정의
   • 유즈케이스 다이어그램을 검토하여 클래스를 구성하는 속성을 도출한다. 속성에 대한 이름을 부여하고 간략한 설명을 기술한다. 속성의 이음은 속성을 가지고 있는 정보를 명확하게 지정하는 명사로 한다.