2020 정보처리기사 실기 : Chapter 01

Chapter 01 : 요구사항 확인

---

1. 현행 시스템 파악

• 소프트웨어뿐만 아니라 하드웨어, 네트워크 등 관련 인프라를 확인하고 어떤 기술 요소를 적용할 것인지를 판단하기 위한 사전 지식 습득 과정

---

2. 현행 시스템 파악 절차

• 구성, 기능, 인터페이스 파악
• 아키텍처, 소프트웨어 구성 파악
• 하드웨어, 네트워크 구성 파악

---

3. 요구공학

• 시스템의 개발, 변경의 목적(what)을 식별하기 위해, 이해관계자들의 요구를 이해 및 조정하여 체계적으로 수집, 분석, 명세화, 확인하는 공정 또는 이에 관한 학문
• 요구공학을 통해, 프로젝트의 과제 범위를 산정한다. 
• 요구공학은, 향후 프로젝트 종료 시 감사 수행에 있어서 감사 범위의 기준이 된다. 

---

4. SWEBOK

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

---

5. 요구사항 개발 프로세스

순서	프로세스	내용
1	도출	정보 수집을 하는 활동 개발팀과 고객 사이의 관계 형성 효율적인 의사소통이 중요
2	분석	요구사항들 간의 상충되는 것을 해결 소프트웨어가 환경과 어떻게 상호 작용하는지 이해함 소프트웨어 요구사항을 도출
3	명세	문서로 작성 소프트웨어 요구사항을 작성
4	확인 (검증)	제대로 이해했는지 확인 일관성과 완전성이 충족되었는지 확인

---

6. 요구사항 도출의 필요성

• 범위의 기준선을 제공한다.
• 일정, 원가에 영향을 미친다.
• 추적성을 제공한다. 

 

 

** 추적성 : 요구사항과 산출물 간의 관계를 검증할 수 있는 속성

---

7. 요구사항 도출 기법

기법	내용
핵심그룹	해당 주제 전문가 집단을,  project sponsor과 project owner를 구분한다.
심층워크숍	1박 이상을 통해, 심층적인 분석을 한다.  장시간 워크숍을 통해, 내부 심리 등을 파악한다.
인터뷰	1:1, 1:N 등 다양한 방식으로 인터뷰한다.  가장 고전적이지만, 효율적이다.
집단창의력기법	다양한 이해관계자들이 토론한다.  형식에 구애 없이 진행한다. (델파이 기법)
집단의사결정기법	다양한 이해관계자들이 토론한다.  다양한 환경, 시나리오를 이용한다.
사용자업무관찰기법	실사용자의 환경 등 가까운 곳에 위치하여 분석한다
설문지 및 설문조사	일관성 보장이 어렵다.
프로토타입	시제품을 제공하여, 요구사항 도출 효율성을 극대화한다.

---

8. 요구사항 분류의 종류

• 기능적 요구사항
  • 기능
  • 자료
  • 인터페이스
  • 사용자

• 비기능적 요구사항
  • 자원
  • 성능
  • 보안
  • 품질

---

9. 요구사항 분석의 필요성

• snowball effect 방지
• gold plate 방지
• 프로젝트 과제의 범위 명확화

 

 

** snowball effect : 요구사항 분석 불명확 등으로 인해, 시간이 지날수록 비용이 기하급수적으로 증가하는 현상

---

10. 요구사항 분석 기법

기법	내용
요구사항 분류	기능과 비기능, 요구사항 범위 등의 기준으로 분류한다.
개념 모델링
요구사항 할당
요구사항 협상
정형 분석	형식적으로 정의된 시멘틱을 지닌 언어로 요구사항을 표현한다.  정확하고 명확한 표현을 통해, 오해의 소지를 최소화한다.  마지막 단계에서 수행한다.

---

11-1. UML (Unified Modeling Language)

• 소프트웨어 집약 시스템의 시각적 모델을 만들기 위해 도안 표기법을 사용하고, 객체 관리를 위해 표준화 된 범용 모델링 언어이다. 

 

 

11-2. UML의 특징

• 가시화 언어
  • 개념 모델 작성
  • 오류없이 전달
  • 의사소통 용이
  • Graphic 언어

• 명세화 언어
  • 정확한 모델 제시
  • 완전한 모델 작성
  • 분석 및 설계의 결정 표현

• 구축 언어
  • 다양한 Prog 언어와 연결
  • 왕복 공학 가능 (순공학, 역공학)
  • 실행 시스템 예측 가능

• 문서화 언어 
  • 시스템에 대한 통제, 평가, 의사소통의 문서

 

 

11-3. UML 4 + 1 Model

• 고객 요구사항을 중심으로, 설계자, 시스템 통합자, 개발자, 시스템 엔지니어의 관점으로 SW Architecture를 구축하는 설계 방법이다.
• De-fecto 표준이다.
• 기존의 view model의 한계를 극복할 수 있다.
• 기능적, 비기능적 요구사항을 동시에 만족시킨다.

 

구분	설명	응용 도구
Use-case View	사용자 관점이다. (end-user) 시스템 기능을 명세한다.	Use-case Diagram User Story
Logical View	설계자 관점이다. (Designer) 전체 레이어를 구성한다.	Class Diagram Sequence Diagram
Implementation View	개발자 관점이다. (Programmer) 컴포넌트 간의 상호관계를 정의한다.	Package Diagram
Process View	시스템 통합 관점이다. (Integrator) 비기능적 요구사항을 기술한다.	Activity Diagram
Deployment View	시스템 엔지니어 관점이다. (System Engineer) 물리적 노드 프로세스의 분산 및 배치를 한다.	Deployment Diagram

 

 

 

** De-fecto 표준 : 공식적으로 표준화 하지는 않았지만, 업계나 시장에서 사실상의 표준으로 받아들이고 사용하는 기술 및 방법 

---

12. SRS

• 요구사항 분석 단계의 요구사항과 스팩을 정리한 산출물이다. 
• 소프트웨어 프로젝트의 중심이 되는 SW 요구사항명세문서이다.
• 개발 목적, 다양한 계층 사용, 여러 개발 산물 문서의 출발점이다.  

---

13. 요구사항 명세서

• 시스템의 목표를 기술한다. 
• 기능 요구사항과 비기능 요구사항을 작성한다. 

---

14-1. 요구사항 확인 (검증, Validation)

• 요구사항의 명확화와 분할 발주를 통해, 개발 단계에서 요구 변경을 최소화하고, 최초 정의된 요구사항에 맞게 구현되었는지 감ㄹ리 시행을 통해 품질을 보장하는 활동이다. 

 

 

14-2. 요구사항 확인 기법

기법	설명
요구사항 검토	명세서의 완성 시점에서 진행한다.
프로토타이핑	사전에 모의 형식의 테스트베드 타입으로 구성한다.
모델 검증	분석 단계에서 개발된 모델의 품질을 검증할 필요
인수 테스트

 

---

15. 분석모델 검증 과정

순서	단계	설명
1	유스케이스 모델 검증	액터 유스케이스 유스케이스 명세서
2	개념 수준 분석 클래스 검증	클래스 도출 클래스명과 속성 클래스들 간 관계
3	분석 클래스 검증	스테레오 타입 경계 및 제어 클래스 도출 관계 및 상세화 정ㄷ

---

15. 다이어그램 종류

이름	설명
Class	클래스 간 관계를 기술
Component	컴포넌트 간 관계를 기술
Object	특정 시점의 객체의 snapshot을 기술
Composite Structure	하나의 클래스의 내부 구조를 기술
Deployment	물리적인 배치를 기술
Package	계층적인 구조를 기술
Activity	절차적이고 병렬적인 행위를 기술
Use Case	user가 상호작용하는 시스템을 기술
State Machine	객체의 상태에 따른 작업과, event에 따른 상태 변화를 기술
Sequence	상호작용의 순서를 기술
Interaction Overview	Sequence와 Activity를 결합
Communication	객체 간의 상호작용을 연결에 초점을 맞추어 기술
Timing	객체 간의 상호작용을 시간 제약에 초점을 맞추어 기술