software engineering #4 requirements analysis

16
2012 년년 N4tech ¼ 년년 년년년 이이이 2012.01.20( 이 )

Upload: o-joun-lee

Post on 23-Jun-2015

258 views

Category:

Engineering


2 download

DESCRIPTION

Software engineering

TRANSCRIPT

Page 1: Software engineering #4 requirements analysis

2012 년도 N4tech ¼ 분기 세미나

이오준2012.01.20( 금 )

Page 2: Software engineering #4 requirements analysis

Schedule 소프트웨어 공학

1st weak - chapter 01. 소개

2nd weak - chapter 02. 프로세스

3rd weak - chapter 03. 계획

4th weak - chapter 04. 요구 분석

5th weak - chapter 05. 설계원리와 아키텍처

6th weak - chapter 06. 객체지향 설계

7th weak - chapter 07. 상세 설계와 UI 설계

8th weak - chapter 08. 코딩

9th weak - chapter 09. 테스팅

10th weak - chapter 10. 유지 보수

11th weak - chapter 11. 품질

12th weak - chapter 12. 첨단 소프트웨어 공학 기술

Page 3: Software engineering #4 requirements analysis

요구 분석 – 요구의 범위와 성격을 이해하고 , 제약 사항을 알고 , 해법을 결정

문제 분석 문제 정의 프로토타이핑 , 시험

문서화와 검토

요구 추출과 분석 요구 정의 및 명세화

사용자의 요구를 모두 찾았는가 ?

올바른 기법과 관점을 사용하고 있나 ?

기능이 타당한가 ? 사용자가 요구하는바로 그것인가 ?

Page 4: Software engineering #4 requirements analysis

요구를 찾는 법

Page 5: Software engineering #4 requirements analysis

요구 추출

현재의 기관이나 시스템

발주자의 요구

도메인 모델

현재 상황에 대한 모델현존하는 문서

제안된 요구 유형재사용 가능한

요구

요구 템플릿 재사용 라이브러리

관찰 , 인터뷰 , 브레인스토밍 , 프로토타이핑

Page 6: Software engineering #4 requirements analysis

구조적 분석

Page 7: Software engineering #4 requirements analysis

구조적 분석

시스템을 기능적인 관점에서 다루는 방법 .

현재 시스템과 개발될 시스템의 모델을 만드는 것을 목표로 함 .

1) 배경도 작성

2) 상위 자료 흐름도 작성

3) 하위 자료 흐름도 작성

4) 자료 사전 작성

5) 소단위 명세서 작성

Page 8: Software engineering #4 requirements analysis

자료 흐름도

1) 시스템 경계의 입 / 출력을 식별 .2) 주요자료가 어떤 주요 과정을 거쳐 변형되는가를 파악하고 , 하향식으로 분할 .3) 입 / 출력 자료가 더 분할되지 않으며 , 한 계층이 한 입력자료의 흐름만을 갖을 때 , 중단4) 정확성 검사 , 완벽성 검사 , 일관성 검사 .

Page 9: Software engineering #4 requirements analysis

자료 사전

표제어 ‘ 가나다’순으로 정렬

자료 흐름도의 자료 항목에 대한 정의를 모은 것 .

설명 부분 표제어의 의미

정의부분 자료를 이루는 요소가 무엇인지 수식 형태로 나타냄

Page 10: Software engineering #4 requirements analysis

소단위 명세서자료 흐름도의 최하위 프로세스가 어떤 기능을 하는가를 기술한 것 .

Page 11: Software engineering #4 requirements analysis

객체지향 분석

Page 12: Software engineering #4 requirements analysis

객체지향 분석

- 문제 도메인을 쉽게 이해하고 설명할 수 있음 .

- 변화에 쉽게 대처할 수 있음 .

- 재사용이 용이함 .

1) 엑터 찾기

2) 사용 사례 찾기

3) 재사용이 용이함

Page 13: Software engineering #4 requirements analysis

사용 사례 다이어그램

확장 관계 – 예외적이며 , 선택적인 경우에 이용

포함 관계 – 두 개 이상의 사용 사례가 공유하는 동작

Page 14: Software engineering #4 requirements analysis

엑터 찾기

- 어떤 사용자 그룹이 작업을 수행하기 위해 시스템의 지원을 받는가 ?

- 어떤 사용자 그룹이 시스템의 주요 기능을 사용하는가 ?

- 어떤 사용자 그룹이 유지 보수나 관리 등의 부수적인 기능을

사용하는가 ?

- 시스템이 다른 외부 하드웨어 / 소프트웨어 시스템과 동작하는가 ?

Page 15: Software engineering #4 requirements analysis

사용 사례 찾기

- 시스템이 어떤 작업을 수행하기를 엑터가 원하는가 ?

- 엑터가 원하는 정보는 무엇인가 ? 누가 데이터를 생성하는가 ?

데이터는 조작 삭제할 수 있는가 ? 이런 작업이 누구에 의하여

행해지는가 ?

- 엑터가 시스템에 정보를 알리기 위해 필요한 것은 ?

- 얼마나 자주 , 언제 작업이 일어나는가 ?

- 엑터가 시스템으로 부터 정보를 알아내는데 필요한 이벤트는 ? 이런

사건의 빈도는 ?

Page 16: Software engineering #4 requirements analysis

감사합니다 .

질문 & 답변