▶소프트웨어 개발 과정
- (도메인 분석) → 계획 → (요구)분석 → 설계 → 구현 → 테스트 → 유지보수
- 소프트웨어를 만들기 위해 계획 단계에서 유지보수 단계까지 이르기까지 일어나는 일련의 과정
- 소프트웨어 개발 생명주기라고 함
▶2단계: 요구분석
- 무엇을 개발할지 결정하는 것
- 기존 시스템의 문제점을 파악하고, 사용자 인터뷰를 통해 새로운 요구 사항을 도출하여 수집
- 이 요구사항을 최적화된 상태로 정리한 후 특정 표현 도구를 사용하여 다이어그램 등으로 나타냄
- 요구 사항을 표현하는 도구는 소트트웨어 개발론에 따라 다름
- 구조적 방법론에서는 자료흐름도(DFD, Data Flow Diagram), 자료 사전(DD, Data Dictionary), 소단위 명세서를 사용
- 정보공학 방법론에서는 개체-관계 다이어그램을 데이터베이스 설계를 표현하는 데 사용
- 객체지향 방법론에서는 UML 표기법을 사용, UML 표기법은 다양한 다이어그램으로 구성되어 있는데 요구 사항은 유스케이스 다이어그램을 사용해 표현
- 어떻게(how)보다는 무엇을(what)에 관점을 둠 (무엇을 하는 시스템을 개발할지 정하는 것)
▷요구분석 단계의 주요 작업 : 요구 추출 → 요구 분석 및 명세화( 요구 분석 명세서 작성) → 검토 및 수정
▷소프트웨어 개발 목적
- 소프트웨어 개발의 궁극적인 목적은 개발된 소프트웨어를 사용하는 고객이 만족하도록 하는 것
- 고객 만족을 위해서는 원하는 품질의 제품을 정해진 개발 기간과 주어진 예산 범위 안에서 개발해야 함
- 그러려면 먼저 사용자 요구 사항을 정확히 파악하고 분석하는 작업 필요
사용자 요구를 만족시키기 위해서는 다음과 같은 특성 만족시켜야 함
- 적시성(time of market) :사용자는 매우 복잡한 업무라도 빠른 시간에 만들기를 원한다
- 유연성(flexibility) :급변하는 환경에도 잘 적응할 수 있는 시스템을 원하고 있다
- 통합(intergration) :기존의 시스템과도 쉽게 통합할 수 있어야 한다.
▶요구 추출
- 문제를 이해하기 위해 정보를 수집하고 사용자에게 무엇이 필요한지를 찾아내는 것
▷요구(사항)의 정의
- 제안된 시스템이 무엇을 하는가를 나타낸 문장
- 소프트웨어 개발에서 요구 사항은 사용자와 개발자 간에 합의한 개발 범위에서 시스템이 제공해야 하는 기능 (기능 요구 사항)
- 사용자 요구 사항에는 기능적 요구 사항, 비기능적 요구사항 존재
- 개발 초기에 사용자의 요구 사항을 추출하여 정리한 문서를 '요구 분석 명세서'라고 함
- 요구 분석 명세서에는 시스템의 기능이 '무엇'(what)인지에만 초점을 두어 정리하고 어떻게(how)구현할지는 기술하지 않음
- '어떻게'는 구현 관점으로 설계에서 자세히 표현함
▷요구(사항)의 특징
● 요구는 문장이다
- 요구는 어떤 사실을 짧고 간결한 정보로 표현한 것으로 단순 명료한 문장이나 그림으로 표현할 수 있음
- 이러한 요구들을 모아놓은 것을 요구 문서라고 부름
● 시스템이 무엇을 하는가를 나타낸다
- 시스템이 완수할 것으로 예상되는 작업에 대해 기술한 것
- 도메인을 설명한 것도 아니고, 시스템이 어떤 방법으로 구현될지를 나타낸 것도 아님
● 관련자 모두가 동의한 것이다
- 시스템에 대한 정의를 모든 관련자(사용자, 고객, 개발자, 관리자)가 검토하고 수정이 필요하면 타협하여 합법적으로 정리한 것
- 따라서 관련자 모두가 동의하기 전까지는 공식 요구로 선언하지 않는다
● 고객의 문제를 적절히 해결하기 위한 것이다
- 고객의 문제를 해결하는 데 도움이 될 때 존재하는 것
- 소프트웨어 공학이 다루는 여러 가지는 고객이 안고 있는 문제의 해결과 직결됨
▷요구(사항)의 유형
- 기능적 요구와 비기능적 요구로 나뉨
- 또는 사용자 요구 사항와 시스템 요구 사항으로 나뉨
● 기능적 요구 :시스템이 외향적으로 나타내는 기능, 사용자가 원하는 기능
ex)
-현금인출기의 외형적인 기능: 현금 인출, 잔금 조회, 계좌 이체, 현금 서비스 등
-입력, 출력, 저장, 컴퓨팅, 타이밍과 동기화
● 비기능적 요구 :기능이 아닌 성능이나 품 질, 제약 사항, 효율, 환경 등
ex)
- 품질 특성 :반응 시간, 처리량, 자원 사용량, 신뢰도, 가용성, 장애에서의 회복, 유지보수와 확장의 허용, 재사용성의 허용
- 시스템의 환경과 기술 :플랫폼, 사용 기술
- 프로젝트 개발 방법 :사용하는 개발 프로세스(방법론), 비용과 납기일
▷요구 추출 방법
| 요구 추출 방법 | 작업 방법 | 특징 |
| 관찰 | 사용자의 업무를 관찰하며 기록 | 감추어진 문제를 잘 드러냄 |
| 인터뷰 | 여러 관련 당사자를 만나 질문하고 대답을 기록 | 정확한 요구 추출이 가능하며 요구에 대한 오해를 줄일 수 있음 |
| 브레인스토밍 | 여러 사람이 모인 그룹에서 아이디어를 쏟아놓음 | 효과적인 정보 추출이 가능함 |
| 프로토타이핑 | 시범적으로 시스템을 구현 | 요구에 대한 빠른 피드백이 가능함 |
| 사용 사례 분석 | 시스템의 외부 기능 파악 | 체계적인 요구 구성이 가능함 |
▷요구 사항의 표현
- 요구 사항이 정리되면 어떠한 형태로든 정리된 내용을 한눈에 파악할 수 있도로 기록하거나 표현해야함(모델링 언어를 통해 요구 사항을 표현)
- 소프트웨어 개발에서는 UML의 다양한 다이어그램을 통해 개발하려는 소프트웨어의 범위나 개략적인 구조와 기능을 이해할 수 있음
- 이해 당사자들이 그들만의 관점에서 필요한 다이어그램들을 보며 개발될 소프트에어를 이해할 수 있음
- 이와 같이 UML의 수많은 다이어그램들이 소프트웨어 개발 과정에서 하나의 모델로 사용됨
●모델링 언어
- 요구 사항 정의 및 분석 · 설계의 결과물을 다양한 다이어그램으로 표현하는 표기법
●모델링 언어의 종류
-여러 다이어그램과 다이어그램을 그리기 위한 일련의 규칙들로 이루어져 있는데, 개발 방법론에 따라 사용하는 도구가 다름
- 구조적 방법론에서는 자료흐름도(DFD, Data Flow Diagram), 자료 사전(DD, Data Dictionary), 소단위 명세서를 사용
- 정보공학 방법론에서는 개체-관계 다이어그램을 데이터베이스 설계를 표현하는 데 사용
- 객체지향 방법론에서는 UML 표기법을 사용, UML 표기법은 다양한 다이어그램으로 구성되어 있는데 요구 사항은 유스케이스 다이어그램을 사용해 표현
○ DFD(Data Flow Diagram)
○ 개체-관계 다이어그램(ERD: Entity-Relationship Diagram)
○ 유스케이스 다이어그램
▶요구 분석 및 명세화(요구 분석 명세서 작성)
- 요구 분석 명세서는 요구 분석 과정의 최종 산출물
- 사용자와 개발자를 연결하는 중요한 문서
- 설계 및 구현에서 참조할 사항, 전반적으로 알아야 할 사항을 포함하는 문서
- 사용자와 개발자 간의 계약서
▷요구 분석 명세서 구조
▶검토 및 수정
- 여러 방법을 통해 추출하고 정리한 사용자의 요구 분석 명세서가 정확하고 완전하게 서술되었는지 검토하는 활동
- 사용자의 요구 사항이 완전하게 서술되었는지 검증하고, 요구 분석 명세서를 작성할 때 문서 표준을 따랐는지 확인
▷검토 사항
- 완전성 :사용자의 모든 요구 사항이 누락되지 않고 완전하게 반영되고 있는가?
- 일관성 :요구 사항이 서로 간에 모순되거나 충돌되는 점은 없는가, 산출물 또는 요구사항의 내용이 일관성을 유지하고 있는가?
- 명확성 :서술된 명세서의 내용이 애매모호하지 않고 모든 참여자가 명확히 이해할 수 있는가?
- 기능성 :서술된 명세서의 내용이 '어떻게'보다 '무엇을'에 관점을 두고 서술되었는가?
- 검증 가능성 :서술된 명세서의 내용이 사용자의 요구를 만족하는가? 개발된 소프트웨어가 사용자가 요구하는 내용과 일치하는지를 검증할 수 있는가?
- 추적 가능성 :사용자 요구 분석 명세서와 설계서를 추적할 수 있는가?
- 변경 용이성 :요구 분석 명세서의 내용을 변경하고자 할 때 쉽게 찾아 변경할 수 있도록 작성되었는가?
'[SW 공학]' 카테고리의 다른 글
| [SW 공학] 설계 (0) | 2023.10.11 |
|---|---|
| [SW 공학] 계획-2 (0) | 2023.09.27 |
| [SW 공학] 계획-1 (1) | 2023.09.25 |
| [SW 공학] 개요 (0) | 2023.09.24 |
댓글