정보처리기사 실기 2장 요구사항 확인 요점 정리

1. 개발 기술 환경 파악

● 정의 : 개발하고자 하는 SW와 관련된 OS, DBMS, MW 등을 선정 시 고려해야 할 사항들을 기술하고, 오픈 소스 사용 시 주의해야 할 내용 제시

● OS(운영체제) : 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 관리할 수 있도록 환경을 제공하는 SW

- 고려사항 : 가용성(재가동), 성능, 기술 지원, 주변 기기(설치 가능한 HW, 여러 주변기기 지원 여부), 구축 비용

● DBMS : 사용자와 DB사이에서 사용자의 요구에 따라 정보를 생성해 주고, DB를 관리해 주는 SW

- 기존 파일 시스템의 종속성과 중복성 문제 해결

- 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성(설치 가능한 OS 종류, JDBC ODBC와 호환 여부), 구축 비용

● WAS(Web Application Server) : 사용자의 요구에 따라 변하는 동적인 콘텐츠 처리하기 위해 사용되는 MW

- 주로 DB와 연동해서 사용

- 고려사항 : 가용성, 성능, 기술 지원, 구축 비용

● 오픈 소스 사용에 따른 고려사항 : 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 것으로 오픈 소스 라이브러리를 만족하는 SW

- 고려사항 : 라이선스의 종류, 사용자 수, 기술의 지속 가능성

 

2. 요구사항 정의

- 개념 : SW가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타냄

- 기준과 근거 제공, 의사소통 원활히 해줌

- 기술하는 내용에 따라 ┌ 기능 요구사항 : 무엇을 하는지, 어떻게 하는지 ex) 결정, 수정, 조회

                               └ 비기능 요구사항(성능) : 품질이나 제약사항 ex) 확장성, 가용성, 보안성, 신뢰성, 호환성

- 기술관점, 대상의 범위에 따라 ┌ 사용자 요구사항 : 사용자 관점

                                         └ 시스템 요구사항 : 개발자 관점

- 요구사항 개발 프로세스(타당성 조사 선행)

①. 도출 : 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정   

개발자 고객 사이 관계 형성, 이해관계자 식별, 지속적 반복, 효율적인 의사소통 중요 

ex) 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스 케이스

②. 분석 : 사용자의 요구사항 중 명확하지 않거나 모호한 부분 걸러내는 과정

사용자 요구사항 타당성 조사, 비용과 일정의 제약 설정, SW 범위 파악

┌ 요구사항 분류 : 분류(기능, 비기능으로 분류)

├ 개념 모델링(핵심) : 현실 세계의 상황을 단순화하여 표현하는 과정, 다양하게 표현, 종속성 반영, UML 사용

├ 요구사항 할당 : 구성요소 식별

├ 요구사항 협상 : 충돌 해결 => 우선순위 부여

└ 정형 분석 : 구문(Syntax), 의미(Sementics)를 갖는 정형화된 언어 이용하여 요구사항을 수학적 기호로 표현 후 분석

③. 명세 : 요구사항 체계적 분석 후 승인될 수 있도록 문서화한 것

기능 요구사항 빠짐없이 기술, 비기능 요구사항 필요한 것만 기술, 추적 가능

④. 확인 : 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전히 작성되었는지 검증

요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법

검토 활동, 형상 관리

┌ 요구사항 검토 : 문서화된 요구사항 훑어보면서 확인하는 가장 일반적인 방법

├ 프로토타이핑 : 요구사항 반영하면서 지속적인 프로토타입 재작성(단점 : 프로토타입에만 집중될 가능성, 과대평가,                                            비용 부담)

├ 모델 검증 : 분석 단계에서 개발된 모델이 요구사항 충족하는지 검증, 정적 분석 수행

└ 인수 테스트 : 실 사용 환경에서 요구사항들 모두 충족되는지 사용자 입장에서 확인, 계획 세우고 테스트

 

3. UML(Unified Modeling Language)

● 개요 : 시스템 개발 과정에서 시스템 개발자와 고객 or 개발자 상호 간의 의사소통이 원활하게 이뤄지도록 표준화한 대표적인 객체지향 모델링 언어

● 사물 : 모델 구성하는 가장 중요한 기본 요소 -> 구조, 행동, 그룹, 주해

● 관계 : 사물과 사물 사이 연관성 표현

UML

● 다이어그램

- 구조적 다이어그램 : 정적 모델링에서 쓰임

┌ 클래스 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현, 시스템 구조 파악하고 구조상 문제 도출 가능

├ 객체 : 클래스에 속한 사물(객체)들 즉 인스턴스를 특정 시점의 객체와 객ㅊ 사이의 관계로 표현

├ 컴포넌트(구현 단계) : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스 표현

├ 배치(구현 단계) : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현

├ 복합체 구조 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현

└ 패키지 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

- 행위 다이어그램 : 동적 모델링에서 쓰임

┌ 유스케이스 : 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용, 사용자와 사용사례(여러 형태의 관계로 이루어짐)로 구성

├ 시퀀스 : 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현

├ 커뮤니케이션 : 시퀀스와 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데 객체들간의 연관까지 표현

├ 상태 : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변하는지 표현

├ 활동 : 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

├ 상호작용 : 상호작용 다이어그램 간의 제어 흐름을 표현

└ 타이밍 : 객체 상태 변화와 시간 제약을 명시적으로 표현

 

4. 클래스 다이어그램

● 정적 모델링의 개념 : 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것

- 구조적 관점에서 표현, 객체들을 클래스로 추상화하여 표현

● 클래스 다이어그램의 개념 : 시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션, 오퍼레이션에 대한 제약조건, 클래스 사이의 관계를 표현한 것

- 구조적 다이어그램이며 문서화, 시스템 모델링하는 데 사용, 

● 클래스 : 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현

- 3개의 구획으로 나눠 클래스 이름(반드시 명시), 속성, 오퍼레이션을 표기

- 속성 및 오퍼레이션 생략될 시 구획선 그리지 않아도 됨

- 속성 : 클래스의 상태나 정보 표현

  * 형식 : [접근제어자] 속성명 : 자료형 [다중성][=초기값] // 대괄호는 생략 가능

- 오퍼레이션 : 클래스가 수행할 수 있는 동작, 함수(메소드)라고도 함

  * 형식 : [접근제어자] 오퍼레이션명(매개변수1 : 자료형1, 매개변수2 : 자료형2, ···) : 반환자료형

● 제약조건 : 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 수행

- 주석 도형 안에 제약조건 적은 후 적용될 속성, 오퍼레이션을 점선으로 연결, 클래스 안에 제약조건 명세 시 중괄호 이용

● 관계 : 클래스와 클래스 사이의 연관성 표현, 연관 관계 기본

- 연관, 집합, 포함, 일반화, 의존 관계

 

5. 시퀀스(Sequence) 다이어그램

● 동적 모델링의 개념 : 시스템의 내부 구성 요소들의 상태가 시간의 흐름에 따라 변화하는 과정과 변화하는 과정에서 발생하는 상호 작용을 표현한 것

- 동작이라는 관점에서 표현, 구성 요소들 간의 메시지 호출 즉 오퍼레이션을 통한 상호 작용에 초점

● 시퀀스 다이어그램의 개념 : 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을

액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현한 것

- 상호 작용 과정에서 주고받는 메시지를 표현, 시스템이나 객체들의 수행 기간 확인 가능

● 구성 요소

- 액터(Actor) : 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미

- 객체(Object) : 메시지를 주고받는 주체, 콜론(:)을 기준으로 앞쪽에는 객체명 뒤쪽은 클래스명

- 라이프라인(Lifeline) : 객체가 메모리에 존재하는 기간, 객체 아래쪽 점선으로 표현, 객체 소멸(X) 표시된 기간까지 존재

- 활성 상자(Activation Box) : 객체가 메시지 주고받으며 구동되고 있음을 표현, 라이프라인 상에 겹쳐 직사각형 형태

- 메시지(Message) : 객체가 상호작용을 위해 주고받는 메시지, 전달 순서는 메시지 위치에 따라 묵시적으로 결정되지만, 번호를 표기하여 전달 순서 표현 가능, 

메시지 종류

- 객체 소멸 : 라이프라인 상에서 객체 소멸 표시를 만나면 해당 객체는 더 이상 메모리에 존재 X 함을 의미, X로 표현

- 프레임 : 다이어그램의 전체 또는 일부를 묶어 표현, 전체, 복합적인 부분, 반복 구조, 선택 구조 등이 프레임 안에  표현됨, 프레임의 왼쪽 위에 다이어그램의 종류와 제목을 표기

 

6. 커뮤니케이션(Communication) 다이어그램

● 개념 : 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 링크, 메시지 등의 요소를 사용하여 그림으로 표현

- 시퀀스 다이어그램 같이 동작에 참여하는 객체들이 주고받는메시지를 표현하는데, 메시지뿐만 아닌 관계까지 표현 및 파악 가능

- 관계 제대로 표현됐는지 점검하는 용도로 사용 가능, 초기에는 협업 다이어그램이라고 불림

● 구성 요소

- 액터 : 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미

- 객체 : 메시지 주고받는 주체

- 링크 : 객체들 간의 관계를 표현하는 데 사용, 액터와 객체, 객체와 객체 간에 실선을 그어 표현, 링크에 메시지 표현

- 메시지 : 객체가 상호 작용을 위해 주고받는 메시지, 종류는 시퀀스 다이어그램에서 표현하는 방법과 동일

 

7. 상태(State) 다이어그램

● 개념 : 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것

- 시스템에서 상태 변환 이벤트를 확인할 필요가 있는 객체만을 대상으로 그림

● 구성 요소

- 상태 : 객체의 상태 표현, 둥근 사각형 안에 기술

- 시작 상태 : 상태의 시작을 표현, 속이 채워진 원(●)으로 표현

- 종료 상태 : 상태의 종료를 표현, 속이 채워진 원을 둘러싼 원으로 표현

- 상태 전환 : 상태 사이의 흐름, 변화를 화살표로 표현, 화살표에 이벤트 표시

- 이벤트 : 상태에 변화를 주는 현상, 이벤트에는 조건, 외부 신호, 시간의 흐름 등이 있다

- 프레임 : 상태 다이어그램의 범위를 표현

 

8. 유스 케이스(Use Case) 다이어그램

● 기능 모델링의 개념 : 사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능들을 정리한 후 사용자와 함께 정리한 내용을 공유하기 위해 표현하는 것을 말함

● 유스케이스 다이어그램 개념 : 개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자 관점에서 표현한 것

- 외부 요소와 시스템 간의 상호 작용 확인 가능

- 사용자의 요구사항을 분석하기 위한 도구로 사용, 시스템의 범위 파악 가능

● 구성 요소

- 시스템 / 시스템 범위 : 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스 케이스들을 사각형으로 묶어 시스템의 범위 표현, 사각형 안쪽 상단에 시스템 명칭 기술

- 액터 : 시스템에 대해 수행할 수 있는 역할을 의미하기도 함, 액터 이름 구체적이면 X, 주액터와 부액터로 나뉨

- 주액터 : 시스템을 사용함으로써 이득을 얻는 대상(주로 사람), 사람 형태 간략화하여 표현, 주로 시스템의 안쪽에 배치

- 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템, 조직이나 기관, 시스템의 오른쪽에 배치하며 시스템명을 사각형으로 묶은 후 상단에<<ACTOR>>라고 표기

- 유스 케이스 : 사용자가 보는 관점에서 시스템이 액터에게 제공한느 서비스 또는 기능을 표현한 것

* 타원으로 표현, 타원 안쪽이나 아래쪽에 유스케이스 이름 기술

* 이름은 액터와 시스템 사이에서 이뤄지는 상호 작용의 목적을 내포하되 단순 명료하게 기술

* 기능적 요소를 중심으로 기술하지만 비기능적 요소 포함 가능

* 더 이상 분할되지 않는 기능의 단위, 액터에 의해 수행되며 액터가 관찰할 수 있는 결과 산출

* 하나의 유스케이스 안에서 수행되는 동작은 유스케이스 수행 시 모두 수행되어야 하며, 부분적인 수행 허용 X

* 분석, 설계, 테스트 등 개발 전 과정에서 이용 가능

- 관계 : 액터와 유스 케이스 유스케이스와 유스케이스 사이에서 나타남

* 포함, 확장, 일반화 관계있음

●유스 케이스 명세서(기술서)

: 유스케이스 안에서의 액터와 시스템 간의 상호 작용 과정을 글로 자세히 표현한 것, 모든 유스 케이스에 대해 개별적으로 작성, 사건의 흐름을 참고하여 활동 다이어그램을 작성, 유스케이스 다이어그램의 구성 요소는 아님

 

9. 활동(Activity) 다이어그램

● 개념 : 자료 흐름도와 유사한 것으로, 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것

● 구성 요소

- 액션 / 액티비티 : 액션은 더 이상 분해할 수 없는 단일 작업, 액티비티는 몇 개의 액션으로 분리 가능한 작업

* 테두리가 있는 둥근 사각형으로 표현, 둥근 사각형 안에 액션이나 액티비티의 명칭을 기술

- 제어 흐름 : 실행의 흐름 표현, 화살표로 표현

- 시작 노드 : 액션이나 액티비티가 시작됨을 의미, 하나의 다이어그램 안에는 하나의 시작점만 존재, 검은색 원으로 표현

- 종료 노드 : 모든 흐름 종료 의미, 하나 다이어그램 안에 여러 개의 종료 노드 존재 가능하나 일반적으로 하나만 표현, 검은색 원을 포함한 원으로 표현

- 조건 노드 : 조건에 따라 제어의 흐름이 분리됨을 표현, 마름모로 표현, 들어오는 제어 흐름은 한 개이고 나가는 제어 흐름은 여러 개

- 병합 노드 : 여러 경로의 흐름이 하나로 합쳐짐을 표현, 마름모로 표현, 들어오는 제어 흐름 여러 개, 나가는 제어 흐름 한 개

- 포크 노드 : 액티비티의 흐름이 분리되어 수행됨을 표현, 굵은 가로선으로 표현, 들어오는 액티비티 흐름은 한 개, 나가는 흐름은 여러 개

- 조인 노드 : 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현, 굵은 가로선으로 표현하며 들어오는 흐름 여러 개 나가는 흐름 한 개

- 스윔 레인 : 액티비티 수행을 담당하는 주체 구분, 가로 또는 세로 실선을 그어 구분