1장. 요구사항 확인

#1 현행 시스템 분석

현행 시스템 파악

1. 현행 시스템 파악 개념

 

■ 현행 시스템 파악이란 현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동

(사용하는 SW, HW 무엇인지? 어떻게 되어 있는지 파악하는 것)

 

 

2. 현행 시스템 파악 절차 (현기인 아소하네)

 

■ 1단계 

-시스템 구성 현황 파악 → 기간업무(주요), 지원업무(보조)

-시스템 기능 파악

-시스템 인터페이스 현황 파악 → 데이터형식(XML, 고정가변포맷), 통신규약(TCP/IP, X.25), 연계유형(EAI)

 

■ 2단계

- 아키텍처 파악 →  계층별로 어떤 기술요소 사용중인가 파악

- 소프트웨어 구성 파악 →  설치된 소프트웨어 이름, 용도, 라이선스 등..

 

■ 3단계

- 시스템 하드웨어 현황 파악 → 주요 사양, 이중화 구현 여부

- 네트워크 구성 파악 → 네트워크 장비

 

 

3. 소프트웨어 아키텍처

 

■ 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체를 의미

(소프트웨어를 설계하고 전개하기 위한 지침, 원칙)

 

■ 소프트웨어 아키텍처 프레임워크 

아키텍처가 표현하는 내용, 이들간의 관계를 제공하는 아키텍처 기술 표준

→ 구성요소 : 아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거 

 

■ 소프트웨어 아키텍처 4+1 뷰

고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

(요구사항 충족을 증명하기 위해 유스케이스를 사용)

 

→ 4+1 뷰 구성 요소 (유논프구배)

1. 유스케이스 뷰 

    → 아키텍처 도출, 설계 작업 주도, 다른 뷰 검증 시 사용

2. 논리 뷰

    → 설계 모델의 추상화, 클래스를 식별

3. 프로세스 뷰

    → 런타임시 스레드, 프로세스와 이들 간의 상호작용

4. 구현 뷰

    → 컴포넌트 뷰, 개발자 관점의 구현

5. 배포 뷰

    → 비기능적인 요구사항 고려

 

개발 기술 환경 정의

1. 개발 기술 환경 현행 시스템 분석

 

■ 운영체제(Operating System)

컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램 (사용자가 컴퓨터 쉽게 쓰도록..)

 

→ 운영체제 현행 시스템 분석 시 고려 사항

* 품질 측면 : 신뢰도, 성능(메모리 32, 64 비트, 배치작업)

* 지원 측면 : 기술 지원, 주변 기기, 구축 비용

 

■ OSI 7계층

- 응용 계층(Application Layer) → 사용자, 네트워크 간 연결 서비스

- 표현 계층(Presentation Layer) → 데이터 형식 설정, 암/복호화

- 세션 계층(Session Layer) → 연결 접속 및 동기제어

- 전송 계층(Transport Layer) → 신뢰성 있는 통신 보장

- 네트워크 계층(Network Layer) → 전송을 위한 최적의 경로 제공

- 데이터 링크 계층(Data Link Layer) → 전송, 전송오류 제어

- 물리 계층(Physical Layer) → 0과 1 비트 정보를 전기적 신호전달

 

■ DBMS(Database Management System)

데이터베이스의 가용성, 성능, 기술 지원, 호환성, 구축 비용을 분석한다.

 

→ DBMS 현행 시스템 분석 시 고려 사항

* 성능 측면 : 가용성, 성능, 상호 호환성

* 지원 측면 : 기술 지원, 구축 비용

 

■ 미들웨어(Middleware)의 개념

응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어이다.

 

→ DBMS 현행 시스템 분석 시 고려 사항

* 성능 측면 : 가용성, 성능(가비지 컬렉션)

* 지원 측면 : 기술 지원(오픈 소스), 구축 비용(총 소유 비용)

 

 

2. 개발 기술 환경 요구사항 파악

 

■ CPU 용량 산정

* OLTP/배치/데이터베이스 서버 →  tpmc 보정(계산)

* WEB/WAS 서버 → OPS

 

#2 요구사항 확인

요구사항 

1. 요구사항 개념

 

문제 해결 또는 목적 달성을 위해 고객에 의해 요구되거나, 표준이나 명세 등을 만족하기 위하여 시스템이 가져야 하는 서비스 또는 제약사항

 

■ 요구사항의 분류

→ 기능적 요구사항 (서비스)

→ 비기능적 요구사항 (제약사항)

 

■ 기능적 요구사항 특징 (도분명확)

- 도출 → 의사소통이 중요하다. 요구사항이 어디있고, 어떻게 수집할 것인가? 

  (인터뷰, 설문조사, 브레인스토밍, 워크숍)

- 분석 → 상충되는 요구사항 해결, 요구사항 정제

  (자료 흐름 지향 분석(DFD), 객체지향 분석(UML))

- 명세 → 요구사항 문서화

  (자연어, 정형화 기법)

- 확인 → 요구사항 완전한지 검증

  (동료 검토, 워크 스루, 인스펙션)

 

■ 요구사항 관리 절차 (협기변확)

- 요구사항 협상

- 요구사항 기준선

- 요구사항 변경관리

- 요구사항 확인 및 검증

 

 

2. 요구사항 분석

 

■ 요구사항 분석 기법 (분개할협정)

- 요구사항 분류 (기능, 비기능 인지 구분)

- 개념 모델링

- 요구사항 할당

- 요구사항 협상

- 정형 분석

 

 

3. 요구사항 확인

 

■  요구사항 확인 기법 (요프모인)

- 요구사항 검토

- 프로토 타이핑

- 모델 검증

- 인수 테스트

 

 

4. 요구사항 확인 프로세스

 

■ 요구사항 확인 프로세스 (목정비타)

- 요구사항 목록 확인

- 요구사항 정의서 작성 여부 확인

- 비기능적 요구사항의 확인

- 타 시스템 연계 및 인터페이스 요구사항 확인

 

요구사항의 시스템화 타당성 분석

■ 상호 운용성

다른 목적을 지닌 2개 이상 시스템들이 상호 간 정보 및 서비스를 교환하면서 효과적으로 운용 될 수 있는 시스템의 능력

 

비용산정 모델

■ 상향식 산정방법 (전문가 판단, 델파이 기법)

■ 하향식 산정방법 (Man Month, COCOMO, Putnam, FP(Function Point))

 

#3 분석 모델 확인하기

분석 모델 검증 방법

분석 모델 검증은 요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석 모델에 대해서 확인하는 활동이다.

 

■ 분석 모델 검증 방법 (유개분)

- 유스케이스 모델 검증

- 개념 수준의 분석 클래스 검증

- 분석 클래스 검증

 

분석 모델의 기술적 타당성 검토

■ 분석 모델의 기술적 타당성 검토 (성상아기)

- 성능 및 용량 산정의 적정성

- 시스템 간 상호 운용성

- IT 시장 성숙도 및 트렌드 부합성

- 기술적 위험 분석

 

■ 분석 모델의 시스템화 타당성 분석 프로세스 (컬작검확)

- 타당성 검토의견 컬럼 추가

- 타당성 검토의견 작성

- 타당성 분석 결과 검증

- 타당성 분석 결과 확인 및 배포/공유