(1) 1단계
현행 시스템의 구성, 기능, 인터페이스 현황을 파악하는 단계
(2) 2단계
현행 시스템의 아키텍처 및 소프트웨어 구성 현황을 파악하는 단계
(3) 3단계
현행 시스템의 하드웨어 및 네트워크 구성 현황을 파악하는 단계
공통 기반 계층
실행 환경 서비스 간에 공통적으로 사용되는 기능을 제공
화면 처리 계층
업무 처리 서비스와 사용자 간의 인터페이스를 담당하는 서비스로 사용자 화면 구성 및 사용자 입력 정보 검증 등의 기능을 지원
업무 처리 계층
업무 프로그램의 업무 로직을 담당하는 서비스로 업무 흐름 제어, 트랙잭션 관리, 에러 처리 등의 기능을 제공
데이터 처리 계층
업무 프로그램에서 사용할 수 있도록 데이터에 대한 CRUD 기능을 지원
연계 통합 계층
타 시스템과의 연동 기능을 지원한다.
다양한 하드웨어 및 운영체제에서 자바 언어롤 작성된 애플리케이션을 수행하기 위한 사양의 구현체를 의미한다.
구분 | 내용 |
---|---|
신뢰도 | 장기간 시스템을 운영할 때 운영체제 고유의 장애 발생 가능성 특정 응용프로그램의 메모리 누수로 인한 성능 저하 및 재가동 운영체제의 보안상 허점으로 인한 반복적인 패치 설치를 위한 재기동 운영체제의 버그 등으로 인한 패치 설치를 위한 재가동 |
성능 | 대규모 동시 사용자 요청 처리 대규모 및 대량 파일 작업 처리 지원 가능한 메모리 크기(32bit, 64bit) |
기술 지원 | 공급 벤더들의 안정적인 기술 지원 다수의 사용자들 간의 정보 공유 오픈 소스 여부(Linux) |
주변 기기 | 설치 가능한 하드웨어 다수의 주변 기기 지원 여부 |
구축 비용 | 지원 가능한 하드웨어 비용 설치할 응용프로그램의 라이선스 정책 및 비용 유지 및 관리 비용 총 소유 비용(TCO) |
요구사항 속성 | 검토 내용 |
---|---|
ID | 명명 규칙에 따라 유일성이 확보되는 식별자가 부여되었는지 확인한다 |
이름 | 요구사항 내용을 요약하고, 중복되지 않았는지 확인한다. |
우선순위 | 요구사항의 우선순위가 얼마나 높은지, 필수, 선택, 희망 사항 등으로 구분되어 있는지 확인한다. |
중요도 | 요구사항의 중요도가 작성 규칙에 따라 적절한 점수가 부여되어 있는지 확인한다. |
출처 | 요구사항을 낸 이해관계자의 이름이나 관련 문서명이 기술되어 있는지 확인한다. |
관련 부서 | 요구사항과 관련된 조직의 부서명이 기술되어 있는지 확인한다. |
전제 조건 | 요구사항과 관련된 전제 조건이 적절한지 확인한다. |
내용 | 요구사항의 내용이 명확하고 이해하기 쉽게 기술되어 있는지 확인한다. |
유스케이스 모델 검증
-액터
-유스케이스
-유스케이스 명세서
개념수준 분석 클래스 검증
-클래스 도출
-클래스 명과 속성
-클래스들 간 관계
분석 클래스 검증
-스테레오 타입
-경계 및 제어 클래스 도출
-관계 및 상세화 정도
점검 대상 | 점검 내용 |
---|---|
액터 | 기능 구현에 관계되는 액터가 모두 도출되었는가? 액터 목록에서 액터명이 역할 중심으로 명명되었는가? 요구사항 정의서, 요구사항 기술서에 외부/내부 액터가 모두 도출되었는가? 액터 목록과 액터 명세서에 기록된 엑터가 타당한지 확인 |
유스케이스 | 요구기능 구현에 필요한 유스케이스가 모두 도출되었는가? 도출된 유스케이스를 논리적으로 연결하여 누락된 기능을 파악 도출된 유스케이스가 유스케이스 목록과 유스케이스 명세서에 반영되었는지 확인 도출된 유스케이스의 논리적인 합이 과업 범위와 일치하는지 비교 도출된 유스케이스들이 논리적으로 그룹화되었는지 확인(그룹화는 액터 기준, 연관 관계 기준, 동시성 기준이 가능) 유스케이스 기능 범위가 다른 유스케이스 기능 범위와 중복되는 지 확인 |
유스케이스 명세서 | 유스케이스 명세서 형식에 중요 항목이 누락되지 않았는지 확인 (사전 및 사후 조건, 주요 흐름, 서브 흐름, 예외 흐름 등) 유스케이스의 주요 이벤트 흐름이 모두 도출되고 논리적으로 타당한지 확인 유스케이스를 구현하기 위하여 필요한 입출력 항목이 모두 도출되었는지 확인 |
검토 분야 | 검토 내용 |
---|---|
성능 및 용량 | 요구사항을 만족시키기 위한 분석모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원을 식별한다. 분석 클래스에서 불필요하고 지나치게 많고 속성들을 포함시키게 되면 객체 생성 시 시스템의 메모리 자원을 많이 요구하게 되며, 이로 인한 JVM에서 과도한 가비지 컬렉션이 발생하여 전체 시스템의 성능 저하가 빈번히 발생한다. |
시스템 간 상호 운용성 | 분석모델을 이용하여 보다 구체적으로, 시스템 간 상호 정보 및 서비스를 교환 가능한지 검토한다. 분석모델에서 정의한 구체적인 정보의 존재 여부, 생성 가능성, 교환 방식 지원 등에 대해서 확인한다. |
시장 성숙도 및 트렌드 부합성 | 분석 모델이 과거의 문제를 해결하고 많이 사용되는 트렌드에 부합하는지 확인한다. 예를 들어, 시스템에서 중요하고 빈번하게 사용되는 클래스를 Spring의 프로토타입 빈으로 사용할 것을 가정하고 분석모델이 작성되지 않았는지 검토한다. |
기술적 위험 분석 | 분석모델이 시스템의 기술 구조, 프레임워크, 사용되는 하드웨어 및 소프트웨어와 부합되는지 확인한다. 분석모델이 검증되지 않은 기술의 사용을 가정으로 하고 있어 추가적인 비용발생 가능성이 있는지 확인한다. 분석모델을 구현하기 위하여 특정 업체 기술, 특허, 라이선스에 의존해야 하는지 확인한다. |