정보처리기사 필기 소프트웨어 설계 - 요구사항 확인(NCS학습모듈) (3)

3. 분석모델 확인하기

3-1. 분석모델 검증

• 사업유형이 시스템 개발, 감리 시점이 요구 분석, 감리 영역이 응용시스템인 경우 유스케이스 모형 상세화 수준 및 적정성과 개념 수준의 분석클래스 도출에 관한 점검 항목을 기준으로 검증하고 감리 시점이 분석 설계, 감리 영역이 응용시스템인 경우 유스케이스로부터 분석 클래스 도출 및 상세화에 관한 점검항목을 기준으로 검증한다.

분석모델 검증 절차

• 유스케이스 모델 검증

점검 대상	점검 내용
액터	- 기능 구현에 관계되는 액터가 모두 도출되었는가? - 액터 목록에서 액터명이 역할 중심으로 명명되었는가? - 요구사항 정의서, 요구사항 기술서에 외부/내부 액터가 모두 도출되었는가? - 액터 목록과 액터 명세서에 기록된 액터가 타당한지 확인
유스케이스	- 요구기능 구현에 필요한 유스케이스가 모두 도출되었는가? - 도출된 유스케이스를 논리적으로 연결하여 누락된 기능을 파악 - 도출된 유스케이스가 유스케이스 목록과 유스케이스 명세서에 반영되었는지 확인 - 도출된 유스케이스의 논리적인 합이 과업 범위와 일치하는지 비교 - 도출된 유스케이스들이 논리적으로 그룹화되었는지 확인(그룹화는 액터 기준, 연관 관계 기준, 동시성 기준이 가능) - 유스케이스 기능 범위가 다른 유스케이스 기능 범위와 중복되는지 확인
유스케이스 명세서	- 유스케이스 명세서 형식에 중요 항목이 누락되지 않았는지 확인 (사전 및 사후 조건, 주요 흐름, 서브 흐름, 예외 흐름 등) - 유스케이스의 주요 이벤트 흐름이 모두 도출되고 논리적으로 타당한지 확인 - 유스케이스를 구현하기 위하여 필요한 입출력 항목이 모두 도출되었는지 확인

• 개념 수준의 분석 클래스 검증 : 시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념 수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검해야 한다. 주요 점검 항목은 다음과 같다.

- 개별 유스케이스 단위로 작성하지 않고 시스템 전체를 대상으로 작성하였는가? - 중요도가 높은 요구사항 또는 유스케이스에 필요한 엔터티 클래스가 도출되었는가? - 도출된 클래스 이름과 설명이 이해관계자 간에 이견이 발생하지 않도록 명확한가? - 클래스의 속성은 도출하였는가? 도출된 속성의 이름과 설명이 명확한가? - 클래스들 간에 순환적 관계가 불필요하게 정의되어 있는가? - 클래스 간의 관계에서 다중성(Multiplicity)이 정의되었는가?

클래스 간 다중성(Multiplicity) 예시

• 분석 클래스 검증 : 유스케이스마다 분석 클래스가 적절히 도출되었고, 제어 클래스의 도출 등이 충분하고 상세하게 도출되어 클래스의 역할, 클래스 간의 관계, 메시지 흐름 등을 확인할 수 있는지 검토한다.
• 유스케이스 실현(Realization)에 필요한 분석 클래스 도출 확인

- 하나의 유스케이스를 실현하기 위하여 3개 이상의 클래스가 역할(Role) 기준으로 도출되어야 하며, 유스케이스 별로 실현에 필요한 클래스가 추적 가능해야 클래스 누락 여부를 확인할 수 있다. - 유스케이스 별로 도출된 분석 클래스들이 역할(Role) 기준으로 경계(Boundary), 엔터티(Entity), 제어(Control) 클래스가 도출되어 스테레오 타입으로 표시되었는지 확인한다.

분석 클래스의 스테레오 타입

• 유스케이스 이벤트 흐름에 따라 다르지만 일반적으로 유스케이스 당 1개의 제어 클래스가 존재하고, 연결된 액터마다 1개의 경계 클래스가 존재하는지 확인한다.

분석 클래스 다이어그램 예시

• 경계(Boundary)와 제어(Control) 클래스의 도출 여부 및 상세화 정도 확인 : 유스케이스 실현에 필요한 분석 클래스들이 도출되었는지 확인하기 위하여, 유스 케이스 단위로 분석 클래스를 확인한다.
• 경계 및 제어 클래스 도출 및 상세화 정도 확인

역할 구분	검토 사항
경계	- 유스케이스와 연결된 액터가 있고, 액터의 유형이 시스템 또는 장비인 경우, 해당 액터를 위한 경계 클래스가 도출되었는지 확인하고, 유스케이스의 이벤트 흐름을 참조하여 관련 기능을 처리하기 위한 연산이 도출되었는지 확인한다. - 유스케이스 명세서의 이벤트 흐름을 확인하여, 유스케이스에서 필요한 UI를 위한 경계 클래스가 도출되었는지 확인한다. - UI를 위한 경계 클래스인 경우, 사용자에게 제공할 항목이 속성으로 도출되었는지 확인하고, 화면, 보고서 상의 데이터 타입, 길이가 경계 클래스 속성 정의와 일치하는지 확인한다.
제어	- 유스케이스 별로 제어 클래스가 1개 이상 도출되었는지 확인한다. - 제어 클래스의 연산에 대응하는 엔터티 클래스가 있는지 확인한다. - 유스케이스 명세서 기술된 이벤트 흐름을 처리하기 위한 연산이 제어 클래스에 정의되어 있는지 확인한다.

• 클래스 간의 관계, 클래스 정보의 상세화 정도 확인

역할 구분	검토 사항
관계	- 유스케이스 명세서를 바탕으로 각 클래스 사이의 관계를 정의하였는지 확인한다. - 관계의 다중성이 정확하고 모순이 없는지 확인한다. - 2개의 클래스 간에 1개 이상의 관계가 존재하면, 관계 명 또는 역할명이 정의되었는지 확인한다.
연산 및 속성 상세화	- 유스케이스 명세서를 바탕으로 클래스의 속성 및 연산이 도출되었는지 확인한다. - 도출된 연산의 매개 변수(명, 타입, 길이)와 리턴 타입이 정의되었는지 확인한다. - 도출된 클래스의 속성(명, 타입, 길이)이 이해관계자 간에 이견이 없도록 명확하게 정의되었는지 확인한다. - 경계 클래스의 속성과 화면/보고서의 항목, 엔터티 클래스의 속성 정보가 일관성을 가지는지 확인한다.

분석 클래스 다이어그램 예시

3-2. 분석모델의 시스템화 타당성 분석

• 유스케이스 모델의 개별 유스케이스에 대한 분석모델을 작성한 이후, 해당 분석모델로 시스템을 개발하는 경우에 어떠한 영향을 미치는지 필요한 자원, 상호 운용성, 시장 성숙도, 기술적 위험 분석 측면에서 타당성을 조사한다.

검토 분야	검토 내용
성능 및 용량	- 요구사항을 만족시키기 위한 분석모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원을 식별한다. - 분석 클래스에서 불필요하고 지나치게 많고 속성들을 포함시키게 되면 객체 생성 시 시스템의 메모리 자원을 많이 요구하게 되며, 이로 인한 JVM에서 과도한 가비지 컬렉션(Garbage Collection)이 발생하여 전체 시스템의 성능 저하가 빈번히 발생한다.
시스템 간 상호 운용성	- 분석모델을 이용하여 보다 구체적으로, 시스템 간 상호 정보 및 서비스를 교환 가능한지 검토한다. - 분석모델에서 정의한 구체적인 정보의 존재 여부, 생성 가능성, 교환 방식 지원 등에 대해서 확인한다.
시장 성숙도 및 트렌드 부합성	- 분석모델이 과거의 문제를 해결하고 많이 사용되는 트렌드에 부합하는지 확인한다. - 예를 들어, 시스템에서 중요하고 빈번하게 사용되는 클래스를 Spring의 프로토타입 빈(Prototype Bean)으로 사용할 것을 가정하고 분석모델이 작성되지 않았는지 검토한다.
기술적 위험 분석	- 분석모델이 시스템의 기술 구조, 프레임워크, 사용되는 하드웨어 및 소프트웨어와 부합되는지 확인한다. - 분석모델이 검증되지 않은 기술의 사용을 가정으로 하고 있어 추가적인 비용 발생 가능성이 있는지 확인한다. - 분석모델을 구현하기 위하여 특정 업체 기술, 특허, 라이선스에 의존해야 하는지 확인한다.

---

※ 자료 출처 : 국가직무능력표준 ☞ ncs.go.kr