[정리노트] DAY3) 요구 사항 확인, 요구 공학 프로세스, 객체 지향 분석

 

[정리노트] 1주차) 개발비용 산정 및 개념 적용 문제풀이

▌ 강의 범위 : 5,6,7강
▌ 해당 강의 리스트
　5강. Chapter 02 요구사항 확인
　6강. (3)요구공학 프로세스 
　7강. 객체지향 분석

💡 연습칸과 답안칸의 경계를 조심해야함! 연습내용이 답안칸을 넘어가면 절!대! 안됨

---

 

Chapter 02 요구사항 확인

크게 하향식 비용 산정기법과 상향식 비용 산정기법으로 나뉜다.
 - 요구분석 기법 :  (기능요구) 사용자가 직접적으로 요구하는 것 
　　 　 　 　 　 (비기능요구) 보안성, 성능 등
 ※ 성능(Performance) : 응답시간이 적게 소요되고, 처리량이 많을수록 성능이 좋다.
 
* 요구분석 기법의 종류
 - 인터뷰(면담조사) VS 설문조사

인터뷰(면담조사)	설문조사
일대일로 자세한 내용파악 가능	면담조사의 물리적 한계를 넘기 위한 조사. 다수로 가능

 ※ JAD (Joint Application Development)란?  사용자와 함께 공동 설계

 
** 요구공학의 개념의 절차 : 추출 → 분석 → 명세 → 검증 → 유지보수
 

(3) 요구공학 프로세스

* 요구공학의 프로세스
 - 도출(추출) : 기능적/비기능적 요구 수집 과정
 - 분석 : 객체지향 분석(UML 모델링) / 구조적 분석(DFD, DD, ...)
 - 명세 : 기술
 - 검증 : 회의
 - 유지보수
　요구사항 명세 기준(속성) //빈칸 문제가 나올 수 있음

구분	내용
정확성(Correctness)	요구사항은 정확해야한 다.
명확성(Clarity)	단 한 가지로 해석되어야 한다. (ex. '배'보다는 '사과')
완전성(Completness)	모든 요구사항(기능, 비기능)이 표현되어야 한다.
일관성( Consistency)	요구사항 간 충돌이 없어야 한다.
수정용이성(Modification)	요구사항의 변경이 가능해야 한다.
추적성(Tracebility)	제안서 등을 통해 추적이 가능해야 한다.

 
** 구조적 분석 도구 : DFD, DD, Mini-Spec
 - 구조적 분석 과정은 위에서 아래로 세분화하여 내려가는 하향식 구조
　(객체지향 구조분석은 상향식)
 ※ 알아두기!
 - 최신의 구조적 분석에서는 세가지 측면에서의 모델링
✔️ 시스템의 기능적 측면을 자료흐름도(DFD, Data Flow Diagram) 로서 모델링
✔️ 데이터 사이의 관련성을 개체 관계도(ERD, Entity Relationship Diagram) 로서 모델링
✔️ 시간 및 행위(상태) 관련성을 상태 전이도(STD, State Transition Diagram) 로서 모델링
 
◎ 자료흐름도(DFD: Data Flow Diagram)

 - 자료흐름도는 각 절차 버블이 한페이지 정도가 적절, 12 버블이상시 곤란
 
◎ 자료 사전(DD: Data Dictionary)
 - 자료사전 기호에는 () 생략, {} 반복, [ | ] 선택 등이 가장 많이 출제
 - DFD의 구성요소들을 사전식으로 표현한 것
 
◎ Mini-Spec(소단위 명세서, 프로세스 명세서)
 - 종류에는 구조적 영어(구조화 영어), 의사결정 테이블, 의사결정도
 - Q. DFD의 어떤 부분을 Mini-spec 으로 작성할까? : DFD의 최하위 처리

 

객체 지향 분석

* Rumbaugh(럼바우)의 OMT 기법 - 3단계
- 객체 모델링 : 객체 다이어그램으로 표시
- 동적 모델링 : 상태 다이어그램으로 작성
- 기능 모델링 : 변화하는 과정(자료흐름도-DFD)을 나타냄

* Booch(부치)의 OOAD
- 럼바우와 비교, 부치는 설계 중심 / 럼바우는 분석 중심

* Coad/Yourdom(코드유아든) 방법
- E-R 다이어그램 사용
- 객체의 행위를 모델링하는데 초점을 둔 방법