[정보처리기사_실기] Chapter 1. 요구사항 확인

 

■ 현행 시스템 파악 절차  [ 구기 / 아소 / 하네 ]

구성/기능/인터페이스  --> 아키텍쳐 및 소프트웨어 구성 --> 하드웨어 및 네트워크 구성 파악 

 

■ 소프트웨어 구성 파악 

- 단위 업무 시스템의 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용방식, 라이선스 수를 명시 한것 

 

■ 요구공학  (Requirements Engineering) 

시스템 요구사항을 도출, 분석, 명세, 확인하기 위해 수행되는 구조화된 활동의 집합. 

 

■ 요구사항 유형 

기능 요구사항 / 비기능 요구사항 / 사용자 요구사항 / 시스템 요구사항

 

■ 요구사항 프로세스 [ 도 분 명 확 ] 

도출 -> 분석 -> 명세 -> 확인(검증) 

 

■ SWEBOK 

IEEE Computer Society 에서 Software Engineering 분야의 지식을 정리한 체계 

 

■ 요구사항 도출 기법 

핵심 그룹 / 심층 워크숍 / 인터뷰(가장 고전적이지만 효율성 측면에서 가장 많이 사용한다.) / 집단 창의력기법(브레인스토밍, 델파이, 마인드맵, 명목그룹비법) / 설문조사 / 사용자 업무관찰기법 / 프로토타이핑(시제품을 통해 요구사항 정보 수집) / 집단의사 결정기법 

* 프로토타이핑: 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정 

* 인수 테스트 (Acceptance Test) : 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정 

 

■ 요구사항 분류에 따른 추출방법

- 기능 : 기능 / 자료 / 인터페이스 / 사용자 

- 비기능 : 자원 / 성능 / 보안 / 품질 

 

■ 요구사항 분석기법

요구사항 분류 / 개념 모델링 / 요구사항 할당 / 요구사항 협상 / 정형 분석 

* 개념모델링 (Conceptual Modeling) :  현실 세계의 상황을 단순화하여 개념적으로 표현한 것 / 이러한 모델을 만드는 과정을 모델링이라고함. 

* 정형 분석 (Formal Analysis) : 구문(Syntax)과 의미(Semantics)를 갖는 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 기법 / 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 기법 

 

■ DFD (Data Flow Diagram)  = 버블 차트 

요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법 

[ 구성 ]

- 프로세스 Process : 자료를 변환시키는 시스템의 한 부분(처리과정)을 나타내며 처리, 기능, 변환, 버블이라고 한다.

원이나 둥근 사각형으로 표시하고 그 안에 프로스세 이름을 기입 

- 자료흐름 Data Flow : 자료의 이동(흐름)이나 연관관계를 나타낸다. 화살표 위에 자료의 이름을 기입한다. 

- 자료 저장소 Data Store : 시스템에서의 자료 저장소(파일, 데이터 베이스)를 나타낸다. 평행선 안에 자료 저장소 이름을 기입한다. 

- 단말 Terminator : 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받는다 (정보의 생산자와 소비자), 사각형 안에 이름을 기입한다. 

 

■ UML (Unified Modeling Language) 

객체 기술에 관한 국제 표준기구에서 정의한 표준으로 시스템 분석, 설계, 구현 등 개발자와 사용자간 의사소통이 원활하게 이루어지도록 표준화한 객체지향 모델링 언어

 

■ UML 특징 [ 가 구 명 문 ] 

가시화 언어 / 구축언어 / 명세화 언어 / 문서화언어

 

■ UML의 구성요소 - 사물 [ 그 구 행 주 ]

그룹 사물 / 구조사물 / 행동사물 / 주해사물 (부가적인 설명이나 제약조건 등을 표현) 

 

■ UML의 구성요소 - 관계 

연관 / 집합(포함된 관계) / 포함(포함된 사물에게 영향을 미치는관계) / 일반화 / 의존 / 실체화 관계(사물이 할 수 있거나 해야하는 기능-행위, 인터페이스-으로 서로를 그룹화 할 수 있는 관계를 표현 

 

 

■ UML 4+1 View Model (소프트웨어 아키텍쳐 뷰) 

(고객 요구사항을 중심으로 설계자, 시스템 통합자, 개발자, 시스템 엔지니어의 관점으로 SW Architecture를 구축하는 설계 방법) 

- Use-case View : 사용자 관점 / 아래 4가지 뷰를 모두 검증하고 통합 (소프트웨어 아키텍쳐에 속하지 않음) 

- Logical View : 설계자 관점 / 논리 뷰 / 시스템의 기능적인 요구사항 지원 

- Process View : 시스템 통합 관점 / 프로세스뷰 / 실제 구동 환경을 살펴보는 형태 

- Implementation View : 개발자 관점 / 구현 뷰 / 개발 환경 내 정적인 소프트웨어 모듈(소스코드, 데이터파일, 컴포넌트, 실행 파일 등) 구성을 나타낸 뷰 

- Deployment View : 시스템 엔지니어 관점 / 배치 뷰 / 시스템이 실제로 설치되고, 배치되는 모습을 표현  

 

■ UML의 정적/ 동적 다이어그램 

정적 다이어그램 

- 클래스 다이어그램 : 클래스와 클래스 간의 관계를 기술 / 흔히 제일 잘 보이는 다이어그램 / ERD 모양 / 일반적으로 가장 많이 사용하는 다이어그램 종류

- 객체 다이어그램 : (클래스에 속한 사물,객체라는 단어, 인스턴스, 객체와 객체사이의 관계로 표현하는 다이어그램) 

- 컴포넌트 다이어그램 : 컴포넌트의 구조와 연관관계를 기술 

- 배포 다이어그램 

 

동적 다이어그램 

- 시퀀스 다이어그램 : 객체들 간의 상호작용을 순서의 초점에 맞춰 기술 

- 협업 다이어그램 

- 활동 다이어그램 : 절차적이고 병렬적인 행위를 기술 

- 상태 다이어그램 

 

이외 

- 유스케이스 다이어그램 (Use-case Diagram) : 사용자가 상호작용하는 시스템의 모습을 기술 

 

■ SRS (Software Requirement Specification) 

요구분석 단계의 요구사항과 스펙을 정리한 산출물 

소프트웨어 프로젝트의 중심이 되는 SW 요구사항 명세문서 

 

■ 요구사항 확인 기법 

요구사항 검토 / 프로토타이핑 / 모델 검증 / 인수테스트 

 

■ 유스케이스 모델 검증 점검 대상 

액터 / 유스케이스 / 유스케이스 명세서 

 

■ 다이어그램 종류 

- Class (클래스간의 관계기술)

- Component (컴포넌트의 구조와 연관관계 기술)

- Object (특정 시점의 객체의 snapshot 기술) 

- Composite Structure (하나의 클래스 실행시 내부구조 기술) 

- Deployment (시스템의 물리적 배치를 기술) 

- Package(컴파일 시의 계층적인 구조를 기술) 

- Activity (절차적이고 병렬적인 행위를 기술) 

- Use Case (사용자가 상호작용하는 시스템의 모습을 기술) 

- State(객체의 상태에 따른) 

- Sequence (객체들간의 상호작용 순서에 초점) 

- Interaction  Overview (Sequence + Activity Diagram)

- Communication (객체들간의 상호작용을 연결의 초점) 

- Timing (객체들간의 상호작용을 시간 제약에 초점에 맞춰 기술)