2022-10-02 소프트웨어공학_5

 

1. 요구사항 개발

 

개발에 있어서 고객의 요구사항을 잘 파악하는 것만큼 중요한 것이 없다.

 

요구사항 개발은 발주자나 고객으로부터 구현될 소프트웨어 제품의 사양을 정확히 도출하여 요구사항을 명세하고, 이를 분석한 결과를 개발자들이 이해할 수 있는 형식으로 기술하는 작업이다.

 

---

1.1 요구사항의 분류

 

• 기능적 요구사항
  : 목표로 하는 제품의 구현을 위해 소프트웨어가 가져야 하는 기능적 속성
  (ex. 파일 저장 기능, 편집 기능, 보기 기능 등)

 

• 비기능적 요구사항
  : 제품의 품질 기준 등을 만족시키기 위해 소프트웨어가 가져야 하는 성능, 안정성과 같은 행위적 특성
  (ex. 성능(응답시간, 처리량), 사용의 용이성, 신뢰도, 보안성, 운영상의 제약, 안전성 등)

 

---

1.2 요구사항 개발 프로세스

 

 

---

1.3 요구사항 추출 단계

 

고객의 요구사항 수집하는 단계

 

보통 고객의 최초 요구사항은 추상적이다.

 

이에 수주자는 고객의 정확한 요구사항을 파악해야 한다.

 

요구사항 추출 기법

• 인터뷰
  • 프로젝트 참여자들과 직접적인 대화를 통해서 추출
  • 제품이 사용될 조직 내 작업 수행 과정에 대한 정보
  • 사용자들에 관한 정보 등
• 시나리오
  • 시스템과 사용자 간 상호작용을 시나리오로 작성하여 추출
  • 정상적인 사건의 흐름
  • 비정상적인 사건의 흐름

 

---

1.4 요구사항 분석 단계

 

추출된 요구사항을 이해하고 분석 기법을 이용해서 문제점을 식별.

 

추상적인 요구사항을 구체적이고 구현 가능한 요구사항으로 정리.

 

시스템을 계층적이고 구조적으로 표현해야 한다.

 

구성요소 간의 인터페이스 분석.

 

요구사항 분석 기법

• 구조적 분석
  • 시스템의 기능을 정의하기 위해 프로세스를 도출하고 도출된 프로세서 간 데이터 흐름 정의
• 객체지향 분석
  • 요구사항을 사용자 중심의 시나리오 분석을 통해 유스케이스 모델 구축

 

---

1.5 요구사항 명세 단계

 

분석된 요구사항을 명확하고 완전하게 기록하는 것.

 

모든 기능과 시스템에 관련된 구현상의 제약사항 및 개발자와 사용자가 합의한 성능에 관한 사항 등 명세.

 

요구사항 명세서 (SRS : Software Requirement Specification)

 

프로젝트 산출물 중 가장 중요한 문서.

 

관련자 모두에게 공동의 목표 제시.

 

시스템이 어떻게 수행될 것인지가 아닌 무엇을 수행할 것인가에 대해 기술.

 

목표를 달성하기 위한 해결 방법은 기술하지 않는다.

 

IEEE-std-830 명세 표준

 

 

요구사항 명세서 작성

• 시스템이 수행할 모든 기능과 시스템에 영향을 미치는 제약사항을 명확히 기술
• 명세 내용은 고객과 개발자 모두가 이해하기 쉽고 간결하게 작성
• 기술된 모든 요구사항은 검증이 가능하기 때문에 원하는 품질, 상대적 중요도, 품질의 측정, 검증 방법 및 기준 등 명시
• 요구사항 명세서는 시스템의 외부 행위를 기술하는 것으로, 특정 구조나 알고리즘을 사용하여 설계하지 않도록 함
• 시스템 기능의 이해와 변경 영향 분석 등을 위해서 계층적으로 구성
• 요구사항을 쉽게 참조할 수 있도록 고유의 식별자를 갖도록 번호로 나타내고 요구사항의 우선순위 부여

 

---

1.6 요구사항 검증 단계

 

 사용자의 요구가 요구사항 명세서에 올바르게 기술되었는지 검토하는 단계.

 

• software V&V
  • Validation : 올바른 제품을 만들고 있는가?
  • Verification : 제품을 올바르게 만들고 있는가?

 

요구사항 타당성 검증

• 명세된 요구사항의 구현 가능성
• 명세 표현의 정확성 및 완전성
• 표준과의 일치성
• 요구사항 간 충돌
• 기술적 결함 등

 

 

타당성 검증 외에도 명세 구조 및 공통 용어 검증이 있다.

 

---

2. UML

 

Unified Modeling Language.

 

이전 포스트 확인 : https://ramen4598.tistory.com/103

2022-05-22 소프트웨어_분석_및_설계_17

 

2.1 시스템 구축 시 UML의 역할

• 가시화
• 명세화
• 구축
• 문서화

 

2.2 유스케이스 다이어그램

 

Use case diagram.

 

사용자의 관점에서 시스템의 서비스와 기능 및 그와 관련한 외부 요소를 보여주는 다이어그램.

 

유스케이스 다이어그램 구성요소

 

• 시스템 : 만들고자 하는 시스템의 범위
• 액터 : 시스템의 외부에 위치하며 시스템과 상호작용하는 사람 또는 다른 시스템
• 유스케이스 : 시스템이 액터에게 제공해야 하는 기능의 집합 (시스템 요구사항)
• 관계 : 액터와 유스케이스, 유스케이스와 유스케이스 간 의미 있는 관련성

 

 

관계의 종류

 

1. 연관 관계 (association)
   : 액터와 유스케이스 간 상호작용이 있음을 나타냄.
   : 실선
2. 의존 관계 (dependency)
   1. 포함 관계 (include)
      : 하나의 기능이 실행되려면 반드시 실행되어야 하는 다른 기능.
      : 점선 화살표 위에 <> 표시.
      : 선택 → 필수(포함)
   2. 확장 관계 (extend)
      : 특정 조건에 따라 확장 가능한 다른 유스케이스.
      : 점선 화살표 위에 <> 표시.
      : 선택(확장) → 필수
3. 일반화 관계 (generalization)
   : 구체적인 유스케이스와 추상적인 유스케이스 간을 연결.
   : 실선 삼각형 화살표.

 

아래 실습의 결과물을 보면서 이해하자.

 

유스케이스 다이어그램 작성 순서

 

액터 식별 → Use case 식별 → 관계 정의

 

---

Usecase 실습

 

게시판 유스케이스 다이어그램 작성

 

 

 

---