[소프트웨어공학] 3장. 요구분석

해당 게시물은 김정욱 교수님의 '소프트웨어공학' 강의를 수강하며
학습한 내용을 개인적으로 정리한 글입니다.

---

📌 목차 - 3장. 요구분석

3-1. 요구분석
3-2. 요구사항 도출, 분석
3-3. 문서화: 요구분석명세서
3-4. 요구사항 검증

---

📌 3-1. 요구분석

* 소프트웨어의 요구
- 무엇(문제)을 구축할 것인가를 나타낸다.

* 요구분석의 목적
- 이해: 소프트웨어가 무엇을 위해 필요한지 정확하게 이해한다.
- 전달: 이해한 것을 다른 개발자에게 정확하게 전달한다.
- 컨트롤: 시스템이 명세에 맞도록 제품 개발을 컨트롤한다.

* 요구분석의 중요성
- 의사소통시간을 절약하고 다음 단계의 기초가 된다.

* 요구분석의 어려움
- 사용자의 계속되는 요구사항 추가, 분석가의 문제 영역 이해 부족, 의사소통 문제

* 요구사항의 종류
- 기능적 요구
- 비기능적 요구
- 요구가 아닌 것

* 요구분석 절차
1. 요구사항 도출
2. 요구사항 분석
3. 문서화: 요구분석명세서
4. 검증

---

📌 3-2. 요구사항 도출, 분석

* 요구사항 도출 방법
- 관찰: 잠재적인 사용자들이 수행하는 일을 관찰한다.
- 설문
- 인터뷰: 가능하면 많은 당사자와 인터뷰, 미리 잘 계획해야 많은 정보를 얻을 수 있다.
- 브레인스토밍: 아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의
- 프로토타이핑: 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램
- 유스케이스 분석

* 유스케이스 다이어그램
- 사용 사례를 통해 개발자와 고객 사이의 요구를 이해하는 수단이 된다.
- 구성
- 시스템, 액터, 유스케이스
- 관계
- 연관 관계, 포함 관계, 확장 관계, 일반화 관계(상속)
- 작성법
- 1. 구성요소 정의
- 2. 관계 정의
- 3. 유스케이스 구조화

---

📌 3-3. 문서화: 요구분석명세서

* 요구분석명세서(SRS, Software Requirements Specification)
- 분석한 요구사항을 모두 빠짐없이 작성한 문서. 사용자가 쉽게 읽고 이해할 수 있도록 작성한다. 개발자가 설계와 코딩에 효과적으로 사용할수 있도록 작성한다. 테스트 기준으로 사용할 수 있도록 정량적으로 작성한다.

---

📌 3-4. 요구사항 검증

* 요구사항 검증
- 요구분석명세서가 정확하고 안전하게 서술되었는지 검토한다.
- 완전성: 모든 요구사항이 반영되었는가
- 일관성: 모순되거나 충돌되는 점은 없는가
- 명확성: 애매모호하지 않은가
- 기능성: "무엇을"에 관점을 두고 서술했는가
- 검증 가능성: 사용자의 요구를 만족하는가
- 추적 가능성: 설계 사양서를 추적할 수 있는가
- 변경 용이성: 요구분석명세서의 내용을 변경하고자 할 때 쉽게 찾아 변경할 수 있도록 작성되었는가

---