DAsP - 정보 요구사항 분석 [정보 요구사항 상세화]

정보 요구사항 상세화

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

n  비기능적 정보 요구사항

•       시스템이 만족시켜야 하는 제약 조건(기술적 제약 조건, H/W, S/W와 관련된 제약 조건)

•       시스템이 반드시 만족시켜야 하는 주요 성능 척도(반응 시간, 저장 능력, 동시 처리 능력)

•       신뢰성, 확장성, 이식성, 보안

 

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

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

- 프로세스는 업무를 어떻게 수행하는지 보다는 어떤 업무가 수행되는지를 나타낸다.

- 따라서 입력(Input)과 출력(output)이 있으며 입력을 출력으로 바꾸는 변환 과정을 포함한다.

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

 

가.  수행 절차

n  프로세스 중심으로 정리된 프로세스 목록, 프로세스의 업무 흐름도 내용을 수반하는 업무 조사서를 바탕으로 프로세스 계층도, 프로세스 정의서를 작성한다.

n  도출된 기본 프로세스를 기준으로 기본 프로세스에서 필요로 하는 정보 항목과 산출되는 정보 항목을 정리하고, 산출되는 정보 항목 중 기본 로직이 필요한 경우 기본 로직을 정리한다.

n  표준화 과정을 통하여 해당 정보 항목에 대해서 통합성/분리성 여부를 검토한 후 최종적으로 사용자의 정보 요구사항을 충족하는 정보 항목 목록을 정의한다.

 

나.  수행 작업 내용

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

 

다.  수행 작업 지침

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

가)   프로세스의 분해

n  프로세스의 분해는 단위 업무 기능으로부터 출발하여 점진적으로 수행한다. 단위 업무 기능은 하위에 더 이상 업무 기능을 포함하지 않고, 프로세스만으로 구성된 업무 기능을 의미한다.

n  단위 업무 기능별로 상세하게 프로세스를 분해하지 않고, 해당 업무 영역의 전체 단위 업무 기능에 대하여 프로세스의 분해 수준을 맞추어 점진적으로 분해한다.

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

나)   프로세스 분해 깊이

n  프로세스 분해 시 업무적인 특성을 고려하여 분해의 수준은 3차 수준까지 분해한다.

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

n  그러나 초기 작업에서는 도출된 프로세스가 기본 프로세스인지는 중점을 두지는 않으며, 대상 범위의 모든 프로세스를 균형 있게 분해하는 데에 주의를 기울인다.

n  도출한 프로세스의 대상은 일반적으로 데이터의 상태를 변화시키는(생성, 수정, 삭제) 것만을 프로세스로 정의한다. 하지만 업무적으로 중요한 의미를 가지는 조회용 프로세스 또는 수작업 프로세스는 필요에 따라 명명 규칙을 달리하여 도출하는 것도 바람직하다.

다)   프로세스 명칭

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

라)   프로세스 계층도

n  작성하는 목적이 기본 프로세스의 도출에 있으며, 추후 업무적으로 기술한 프로세스 정의서를 바탕으로 작업을 수행하게 되므로 이에 대한 상세한 내용이 반영된다.

n  높은 응집도(Cohesion) 및 낮은 결합도(Coupling)를 유지하도록 모듈성을 확보하는 것이 중요하다. 이러한 원칙에 따라 분석하면 분석이 복잡도와 모호성이 감소되고 분석의 집중력이 향상되어 프로젝트 관리 및 프로세스 유지보수가 용이하다. 일반적으로 상위 프로세스에 포함되는 하위프로세스가 7개를 초과하면 상위 프로세스를 분리하는 것을 고려한다.

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

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

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

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

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

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

n  도출한 정보 항목은 명명 규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하며, 명사형으로 기술한다.

n  해당 도출된 정보 항목에 대해서 그룹핑하여 정보 항목군으로 구분하고, 정보항목 목록을 작성한다.

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

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

n  동일한 정보 항목에 대해서 통합 시 다음과 같은 장점이 존재한다.

• 통합 정보 항목으로 도출 시 정보 항목의 관리가 용이함

• 동일한 유형의 정보 항목이 존재 시 통합 정보 유형으로 수용 가능

n  단, 아래와 같은 단점도 존재한다.

• 무리한 통합 작업으로 인한 정보 항목의 애매모호성 존재

• 통합 정보 항목에 대한 관리 부족으로 통합의 의미 상실 가능성 존재

 

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

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

- 해당 다이어그램은 사용자와의 의사소통이 원활하게 진행될 수 있도록 도움을 주며, 시스템 영역 내의 유즈케이스와 액터, 그리고 그들 간의 관계를 유즈케이스 다이어그램으로 도식화하고 도출된 유즈케이스의 사건 흐름을 상세화한다.

 

가.  유즈케이스 다이어그램

- 액터(Actor)

• 정보시스템과 상호 작용하는 개인, 그룹, 회사, 조직, 장비 등 정보 서비스를 받는 객체를 말한다.

• 액터의 이름은 명확하게 액터의 역할을 나타내는 이름으로 정의한다.

- 유즈케이스(Usecase)

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

 • 사건 흐름에 대한 개요를 간략하게 기술한다.

- 액터와 유즈케이스 간의 관계

• 확장(Extend): 하나의 유즈케이스가 다른 유즈케이스의 행동을 추가함에 따라 나타나는 두 유즈케이스의 관계를 말하낟. 하나의 유즈케이스가 다른 유즈케이스를 경우에 따라 선택적으로 수행하는 경우에 사용된다.

• 포함(Include): 하나의 유즈케이스가 다른 유즈케이스를 사용함을 나타내는 두 유즈케이스의 관계를 말한다. 하나의 유즈케이스가 다른 유즈케이스를 반드시 수행하는 경우에 사용된다.

• Communicates: 행위자가 어떤 유즈케이스에 참가함을 나타낸다. 이것은 해위자와 유즈케이스 사이의 유일한 관계이다.

나.  유즈케이스 상세화

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

 

•       유즈케이스에 대한 개략적인 설명

•       사건 흐름(Flow or Event)

•       사전, 사후 조건

•       비기능적인 정보 요구사항

•       주된 사건 흐름에 대체될 수 있는 대안 흐름

•       예외 처리 사항

 

다.  클래스 다이어그램 작성

1)     엔티티 클래스 도출

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

• 유즈케이스 다이어 그램을 조사하여 명사 및 명사구를 후보 객체로 선정한다.

• 의미가 모호한 것은 제거한다.

• 이음동의어 및 동음이의어를 고려하여 선정한다.

• 문제 영역과 관련이 없는 것은 제거한다.

• 유사한 구조와 행위를 가진 객체들을 클래스로 그룹핑한다.

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

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

3)     속성 정의

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