1. 소프트웨어 설계 - 요구사항 확인(요구사항 정의 ~ 주요 UML 다이어그램)

6. 요구사항 정의

1) 요구사항

: 문제 해결을 위해 제공하는 서비스에 대한 설명과 서비스가 정상 운영되기 위해 필요한 제약 조건을 요구하는 것

• 소프트웨어 개발 및 유지보수 과정에서 필요한 기준과 근거 제공
• 개발에 참여하는 이해관계자들 간의 의사소통 원활화
• 정의된 요구사항을 토대로 이후 소프트웨어 개발 과정의 목표와 계획을 수립

 

2) 요구사항의 유형

- 기술하는 내용에 따라

기능 요구사항 (Functional Requirements)	- 시스템이 수행하여 사용자가 제공받아야하는 기능 - 시스템의 입출력에 포함되는 요소, 저장하는 데이터, 수행하는 연산 등
비기능 요구사항 (Non-functional Requirements)	- 시스템 장비 구성, 성능 (처리 속도, 처리량 etc), 인터페이스, 데이터, 테스트, 보안, 품질, 제약사항 등에 대한 요구사항 - 프로젝트 관리와 지원에 대한 요구사항

- 기술 관점과 대상의 범위에 따라

사용자 요구사항 (User Requirements)	- 사용자 관점의 시스템 요구사항 - 사용자를 위해 이해하기 쉽게 작성
시스템 요구사항/ 소프트웨어 요구사항 (System Requirements)	- 개발자 관점의 시스템 요구사항 - 전문적이고 기술적인 용어로 작성

 

3) 요구사항 개발 프로세스

: 개발 대상에 대한 요구사항을 쳬계적으로 도출하고 분석하여, 그 분석 결과를 명세서에 정리한 후 이를 확인 및 검증하는 활동

• 요구사항 개발 프로세스의 진행 전에 개발 프로세스에 대한 타당성 조사(Feasibility Study)를 진행함
• 요구사항 개발은 요구 공학의 한 요소

※ 요구 공학 (Requirements Engineering) : 요구사항을 정의, 분석, 관리하는 프로세스를 연구하는 학문

- 요구사항 변경의 원인과 처리방법의 이해, 요구사항 관리 프로세스 품질 개선을 통해 프로젝트 실패를 최소화하는 것을 목표로 함

도출 (Elicitation)

▶

분석 (Analysis)

▶

명세 (Specification)

▶

확인 (Validation)

1. 요구사항 도출 (Requirements Elicitation, 요구사항 수집)

: 개발의 이해관계자들이 의견 교환을 통해 요구사항을 식별하고 이해하는 과정

• 소프트웨어가 해결해야하는 문제를 이해하는 첫 단계
• 개발자와 고객 사이의 관계가 만들어지고 이해관계자를 식별
• 도출과정은 소프트웨어 개발 생명 주기 동안 지속적으로 반복
• ex) 청취/인터뷰, 설문, 브레인 스토밍, 워크샵, 프로토타이핑(Prototyping), 유스케이스 etc

 

2. 요구사항 분석 (Requirements Analysis)

: 사용자의 요구사항 중 명확하지 않거나 이해되지 않는 부분을 발견하여 걸러내는 과정

• 사용자 요구사항의 타당성 조사, 비용 및 일정에 대한 제약 설정
• 중복되거나 상충되는 요구사항 중재
• 도출된 요구사항을 토대로 소프트웨어의 범위와 상호작용 방식 파악
• ex) 자료 흐름도 (DFD), 자료 사전(DD) etc

 

3. 요구사항 명세 (Requirements Specification)

: 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 과정

• 기능 요구사항은 완전하고 명확하게 기술, 비기능 요구사항은 필요한 부분만 기술
• 사용자가 이해하귀 쉽고 개발자에게 효과적일 수 있도록 작성
• 구체적인 명세를 위해 소단위 명세서 (Mini-spec)을 사용하기도 함
• 소프트웨어 요구사항 명세서 (SRS; Software Requirements Specificaiton) 작성 : 소프트웨어가 제공하는 기능, 특징, 제약 조건 + 성능, 보안, 사용성

 

※ 요구사항 명세 기법

정형 명세 기법		비정형 명세 기법
수학적 원리 기반, 모델 기반	기법	상태/기능/객체 중심
수학적 기호, 정형화된 표기법	작성 방법	자연어 기반 or 다이어그램
- 요구사항을 정확하고 간결하게 표현 - 일관성이 있어 완전성 검증 가능 - 사용자가 이해하기에 어려움	특징	- 자연어 사용으로 일관성 저하, 여러 해석 가능 - 내용이 이해하기 쉽고 의사소통에 용이
VDM, Z, Petri-net, CSP etc.	종류	FSM, Decision Table, ER 모델링, State Chart(SADT) etc.

 

4. 요구사항 확인 (Requirements Validation, 요구사항 검증)

: 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토하는 과정

• 이해관계자들은 요구사항이 실제 요구를 반영하는지, 상충되는 요구사항은 없는지 점검 및 검토
• 재작업 비용을 줄이기 위해 중요한 단계
• 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리 수행

※ 형상 : 소프트웨어 개발 과정에서 만들어지는 프로그램, 프로그램 설명 문서, 데이터 etc

 

---

7. 요구사항 분석

: 소프트웨어 개발의 실제적인 첫 단계. 사용자의 요구사항을 이해하고 문서화하는 활동

• 소프트웨어 분석가에 의해 수행
• 사용자 요구의 타당성 조사, 비용 및 일정에 대한 제약 설정
• 요구를 추출하여 목표를 정하고 문제 해결 방식을 결정
• 분석 결과는 소프트웨어 설계 단계의 기본적인 자료가 됨

 

1) 구조적 분석 기법

: 자료의 흐름과 처리를 중심으로 요구사항을 분석하는 방법

• 도형 중심의 도구 사용 : 분석가와 사용자 간의 대화 용이
• 하향식 방법 사용 : 시스템 세분화 가능, 분석의 중복 배제
• 전체 시스템에 대한 일관성 있는 이해가 가능함
• ex) 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-spec.), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 etc.

 

1. 자료 흐름도 (DFD; Data Flow Diagram)

: 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술 (자료 흐름 그래프, 버블 차트)

자료 흐름도의 예시

• 프로세스와 자료 저장소 사이의 자료의 흐름과 기능을 기술
• 자료의 흐름과 기능을 프로세스(Process), 자료 흐름(Data Flow), 자료 저장소 (Data Store), 단말 (Termiator)의 네 가지 기본 기호로 표시

기호	의미
프로세스	- 자료를 변환시키는 시스템의 한 부분을 나타냄 (처리, 기능, 변환, 버블) - 원이나 둥근 사각형으로 표시
자료 흐름	- 자료의 이동이나 연관관계를 나타냄 - 화살표로 표시
자료 저장소	- 시스템의 자료 저장소 (파일, 데이터베이스...)를 나타냄
단말	- 시스템과 교신하는 외부 개체, 입력 데이터가 만들어지고 출력 데이터를 받는 곳 - 정보의 생산자 및 소비자 역할

자료흐름도의 표기법 중 하나인 Yourdon/DeMacro 표기법

 

2. 자료 사전(DD; Data Dictionary)

: DFD의 자료를 더 자세히 정의하고 기록한 것. 데이터를 설명하는 데이터인 메타 데이터

자료 사전의 예시

• 자료 흐름도에 표시된 자료를 기호를 통해 체계적, 조직적으로 모은 것
• 개발자와 사용자 모두 편리하게 사용

기호	정의
=	정의 : ~ 로 구성되어 있다 (is composed of)
+	연결 : 그리고 (and)
( )	생략 : 생략가능 (optional)
[ | ]	선택 : 또는 (or)
{ }	반복 : n회 반복 (iteration)
* *	설명 : 주석 (comment)

---

8. CASE/HIPO

1) CASE (Computer Aided Software Engineering, 자동화 도구)

: 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구

 

- 요구사항 분석 시 자동화 도구 사용의 이점

• 표준화 및 문서화 품질 개선
• 분석자들 간 적절한 조정 가능
• 결함, 생략, 불일치 등의 발견 용이
• 변경으로 인한 영향 추척이 용이
• 명세에 대한 유지보수 비용 축소

 

- 요구사항 분석을 위한 자동화 도구의 종류

1. SADT (Structured Analysis and Design Technique) 
   • SoftTech 사의 구조적 분석 및 설계 도구
   • 구조적 요구 분석을 위해 블록 다이어그램 사용
2. SREM (Software Requirements Engineering Methodology) = RSL/REVS
   • TRW 사가 실시간 처리 소프트웨어 시스템의 요구사항을 기술하기 위해 개발. RSV와 REVS 사용
   • RSL (Requirements Statement Language) : 요소, 속성, 관계, 구조를 기술하는 요구사항 기술 언어
   • REVS (Requirements Engineering and Validation System) : RSL로 기술된 요구사항을 자동으로 분석하여 명세서 출력
3. PSL/PSA
   • 미시간 대학의 자동화 도구. PSL과 PSA를 사용
   • PSL (Problem Statement Language) : 문제(요구사항) 기술 언어
   • PSA (Problem Statement Analyzer) : PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서 출력
4. TAGS (Technology for Automated Generation of Systems)
   • 개발 주기 전 과정에 이용 가능한 통합 자동화 도구
   • IORL(Input Output Requirements Language, 요구사항 명세 언어) 이용
   • IORL, 요구사항 분석 및 IORL 처리 도구, 기초저직인 TAGS 방법론으로 구성
5. EPOS

 

2) HIPO (Hierarchy Input Process Output)

: 시스템의 분석, 설계, 문서화에 사용되는 기법. 입력, 처리, 출력의 각 기능을 나타냄

• 기본 시스템 모델은 입력, 처리, 출력으로 구성됨
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표 등을 사용해 이해가 쉬움
• 기능과 자료의 의존 관계를 동시에 표현 가능
• 변경과 유지보수가 용이

 

- HIPO Chart : 시스템의 기능을 여러 모듈로 분할하여 모듈 간의 인터페이스를 계층 구조로 표현한 것

• 가시적 도표(Visual Table of Contents) : 시스템의 전체적인 기능과 흐름을 보여주는 계층 구조도(Tree)
• 총체적 도표(Overview Diagram, 총괄 도표, 개요 도표) : 프로그램을 구성하는 기능을 기술. 입력, 처리, 출력에 대한 전반적 정보 제공
• 세부적 도표(Detail Diagram, 상세 도표) : 총체적 도표의 기능을 구성하는 기본 요소들을 상세히 기술

---

9. UML (Unified Modeling Language)

: 시스템 개발 과정에서 원활한 의사소통을 위해 표준화한 객체지향 모델링 언어

• Rumbaugh, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합, OMG에서 표준으로 지정
• 6개의 구조 다이어그램과 7개의 행위 다이어그램 작성 가능
• 각각의 다이어그램은 사물과 사물 간의 관계를 다이어그램의 용도에 맞게 표현함

- UML 구성 요소

1. 사물(Things) : 모델을 구성하는 중요한 기본 요소, 관계가 형셩될 수 있는 대상

• 구조 사물(Structural Things) : 시스템의 개념적, 물리적 요소. ex) 클래스, 유스케이스, 컴포넌트, 노드 etc.
• 행동 사물(Behavioral Things) : 시간 및 공간에 따른 요소들의 행위 ex) 상호작용, 상태 머신 etc.
• 그룹 사물(Grouping Things) : 요소들을 그룹으로 묶어서 표현 ex) 패키지 etc.
• 주해 사물(Annotation Things) : 부가적 설명이나 제약 조건 ex) 노트 etc.

 

2. 관계(Relationships) : 사물과 사물 사이의 연관성

• 연관 관계 (Association) : 2개 이상의 사물이 서로 관련되어 있음을 표시
  • 사물 사이를 실선으로 연결하여 표현, 방향성은 화살표로 표시
  • 양방향 연관 관계의 경우 화살표를 생락
  • 연관에 참여하는 객체의 개수를 의미하는 다중도(Multiplicity)를 선 위에 표시

연관 관계의 예시. 수업에는 1명 이상의 교사와 1명 이상의 학생이 연관된다

• 집합 관계 (Aggregation) : 하나의 사물이 다른 사물에 포함되는 관계
  • 포함하는 쪽(Whole)과 포함되는 쪽(Part)는 서로 독립적
  • 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결하여 표시

집합 관계의 예시. 바퀴와 엔진은 차에 포함되지만 독립적으로도 존재할 수 있다.

• 포함 관계 (Composition) : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 집합 관계의 특수한 형태
  • 포함하는 쪽(Whole)과 포함되는 쪽(Part)는 서로 독립될 수 없고 생명 주기를 함께 한다
  • 포함되는 쪽에서 포함하는 쪽으로 검은 마름모를 연결하여 표시

포함 관계의 예시. 손과 다리는 사람에 포함되며 사람과 생명주기를 함께한다.

• 일반화 관계 (Generalization) : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
  • 더 일반적 개념을 상위/부모, 더 구체적인 개념을 하위/자식으로 부른다
  • 하위에서 상위로 속이 빈 화살표를 연결하여 표시

일반화 관계의 예시. 계좌의 구체적 개념으로 당좌 예금 계좌, 일반 예금 계좌, 신용 계좌가 있다.

• 의존 관계 (Dependency) : 필요에 의해 서로 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
  • 소유 관계 없이 한 사물이 다른 사물에 영향을 미치는 관계
  • 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계
  • 영향을 주는 사물(이용자)에서 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표시

의존 관계의 예시. 사람은 책을 읽는 동안 짧게 책과 관계를 유지한다.

• 실체화 관계 (Realization) : 기능으로 사물을 그룹화할 수 있는 관계를 표현
  • 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
  • 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표시

실체화 관계의 예시. 비행기와 새를 "날 수 있다" 라는 기능으로 그룹화 할 수 있다

 

3. 다이어그램 (Diagram) : 사물과 관계를 도형으로 표현한 것

• 여러 관점에서 시스템을 가시화한 뷰를 제공하여 의사소통에 도움을 줌
• 주로 정적 모델링에서는 구조적 다이어그램을, 동적 모델링에서는 행위 다이어그램을 사용
• 구조적 다이어그램 (Structural Diagram)

클래스 다이어그램 (Class Diagram)	- 클래스, 클래스의 속성, 클래스 사이의 관계를 표현 - 사스템의 구조 파악과 구조의 문제점 파악에 용이
객체 다이어그램 (Object Diagram)	- 클래스에 속한 인스턴스를 객체들 사이의 관계로 표현
컴포넌트 다이어그램 (Component Diagram)	- 실제 구현 모듈인 컴포넌트 간의 관계와 인터페이스 표현 - 구현 단계에서 이용
배치 다이어그램 (Deployment Diagram)	- 물리적 요소(결과물, 프로세스, 컴포넌트)들의 위치 표현 - 구현 단계에서 이용
복합체 구조 다이어그램 (Composite Structure DIagram)	- 복합 구조를 갖는 클래스나 컴포넌트의 내부 구조 표현
패키지 다이어그램 (Package Diagram)	- 모델 요소들을 그룹화한 패키지들 간의 관계 표현

• 행위 다이어그램 (Behavioral Diagram)

유스케이스 다이어그램 (Use Case Diagram)	- 사용자(액터)와 사용 사례(유스케이스)로 구성. 사용 사례 간의 관계로 표현
시퀀스 다이어그램 (Sequence Diagram)	- 상호작용하는 시스템이나 객체들이 주고받는 메세지를 표현
커뮤니케이션 다이어그램 (Communication Diagram)	- 동작에 참여하는 객체들이 주고받는 메세지와 객체들 간의 연관성 표현
상태 다이어그램 (State Diagram)	- 클래스의 상태 변화나 다른 객체와의 상호 작용에 따른 객체의 상태 변화 표현
활동 다이어그램 (Activity DIagram)	- 시스템의 기능을 객체의 처리 로직이나 처리 흐름 순서에 따라 표현
상화작용 개요 다이어그램 (Interaction Overview Diagram)	- 상호작용 다이어그램 간의 제어 흐름 표현
타이밍 다이어그램 (Timing Diagram)	- 객체 상태의 변화를 시간 제약에 따라 표현

※ 스테레오 타입 : UML의 기본 기능 외 추가적인 기능을 표현하기 위해 사용. ≪≫를 사용하여 표현

• ≪include≫ : 포함 관계
• ≪extend≫ : 확장 관계
• ≪interface≫ : 인터페이스 정의
• ≪exception≫ : 예외 정의
• ≪constructor≫ : 생성자

---

 

 

 

 

 

 

 

10. 주요 UML 다이어그램

1) 유스케이스 다이어그램

: 시스템의 외부 요소(사용자, 외부 시스템)이 시스템을 이용해 수행할 수 있는 기능을 사용자 관점에서 표현한 것

• 외부 요소와 시스템 간 상호 작용 확인 가능
• 시스템의 범위 파악 가능
• 사용자의 요구사항을 분석하는 도구

유스케이스 다이어그램의 예시

- 유스케이스 다이어그램의 구성 요소

• 시스템/시스템 범위 : 외부 시스템과 구분되는 시스템 내부의 기능들을 유스케이스로 묶어 시스템의 범위 표현
• 액터 : 시스템과 상호작용하는 모든 외부 요소
  • 주액터 : 시스템 사용으로 이득을 보는 대상. 주로 고객이나 사람
  • 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템. 조직이나 기관
• 유스케이스 : 사용자 관점에서 시스템이 액터에 제공하는 서비스나 기능을 표현한 것
• 관계 : 액터와 유스케이스, 유스케이스와 유스케이스 간의 관계 (포함 관계, 확장 관계, 일반화 관계)

 

2) 클래스 다이어그램

: 시스템을 구성하는 클래스, 클래스의 속성과 오퍼레이션, 제약 조건과 클래스 간의 관계를 표현한 것

• 시스템 구성요소를 문서화하는데 이용
• 시스템 모델링에도 주로 이용

클래스 다이어그램의 예시

 

- 클래스 다이어그램의 구성 요소

• 클래스 : 각 객체들이 갖는 속성(Attribute)와 오퍼레이션(Operation)을 표현. 속성과 오퍼레이션은 접근 제어자를 가짐
  • 속성 : 클래스가 가지는 상태나 정보
  • 오퍼레이션 : 클래스가 수행할 수 있는 동작, 메서드, 함수
• 제약 조건 : 속성에 입력될 값에 대한 제약조건, 오퍼레이션 수행 전후에 지정해야할 조건
• 관계 : 클래스 간의 연관성 (연관, 집합, 포함, 일반화, 의존)

※ 접근 제어자

• public (+) : 모든 클래스에서 접근 가능
• private (-) : 해당 클래스 내부에서만 접근 가능
• protected (#) : 동일 패키지 내의 클래스, 해당 클래스를 상속받은 외부 패키지의 클래스에서 접근 가능
• package (~) : 동일 패키지 내의 클래스에서만 접근 가능

 

3) 시퀀스 다이어그램

: 시스템이나 객체들이 시간 흐름에 따라 메시지를 주고받으며 상호작용하는 과정을 표현한 것

• 각 동작에 참여하는 시스템이나 객체들의 수행 기간 확인 가능
• 시퀀스 다이어그램은 클래스 내부의 객체들을 기본 단위로 해당 객체들의 상호작용을 표현

시퀀스 다이어그램의 예시

- 시퀀스 다이어그램의 구성 요소

• 액터 : 시스템에 서비스를 요청하는 외부 요소. 사람이나 외부 시스템
• 객체 : 메시지를 주고받는 객체
• 생명선 : 객체가 메모리에 존재하는 기간. 객체 아래쪽에 점선을 그어 표현
• 실행 상자 : 객체가 메시지를 주고받으며 구동되고 있음을 표현
• 메시지 : 객체가 상호작용을 위해 주고받는 메시지