[소프트웨어공학] 요구사항 개발 및 관리 - 요구사항, 유스케이스 다이어그램

Github로 보기

---

요구사항 개발

요구사항의 중요성

• 개발되는 SW 제품을 전체적으로 파악하도록 하여 의사소통 시간을 절약하게 해줌
• 상세한 요구사항이 있어야만 산정이 가능하고, 이를 기반으로 계획을 세울 수 있음

요구사항의 분류

기능적 요구사항

• 수행될 기능과 관련된 입출력 및 그들 사이의 처리과정
• 제품 구현을 위해 SW가 가져야하는 기능적 속성

비기능적 요구사항

• 제품의 품질 기준 등을 만족시키기 위해 SW가 가져야하는 행위적 특성
• ex) 성능(응답 시간, 처리량), 사용의 용이성, 신뢰도, 보안성, 운용상의 제약 등

요구사항 개발 프로세스

요구사항 개발

• 고객으로부터 구현될 SW 제품의 사양을 정확히 도출하여 요구사항 명세, 이를 분석하여 개발자들이 이해할 수 있는 형식으로 기술하는 작업

요구사항 개발 단계

요구사항 추출 - 요구사항 분석 - 요구사항 명세 - 요구사항 검증

요구사항 추출

• 고객이 원하는 요구사항 수집

중요성

• 고객의 최초 요구사항은 추상적임
• 요구사항은 계약 및 최초 산정의 기본이 됨

요구사항 추출 기법의 종류

• 인터뷰
  • 프로젝트 참여자들과 직접적인 대화를 통해 정보를 추출하는 기법
  • 요구사항 분석가는 인터뷰 전략을 세우고 목표를 달성해야 함
• 시나리오
  • 시스템과 사용자간에 상호 작용을 시나리오로 작성하여 시스템 요구사항을 추출
  • 시나리오에 포함해야 할 필수 정보
    • 시나리오 들어가기 전 시스템 상태
    • 정상적인 사건의 흐름
    • 정상적인 사건의 흐름에 대한 예외 흐름
    • 동시에 수행되어야 할 다른 행위의 정보
    • 시나리오의 완료 후에 시스템 상태

요구사항 분석

• 요구사항을 분석 기법을 이용하여 식별 가능한 문제들을 도출하고 요구사항을 이해하는 과정

분석의 기준

• 시스템을 계층적이고 구조적으로 표현해야함
• 외부 사용자와의 인터페이스 및 내부 시스템 구성요소 간의 인터페이스를 정확히 분석
• 설계와 구현단계에 필요한 정보를 제공

분석 기법의 종류

• 구조적 분석 (Structured Analysis)

  • 기능을 정의하기 위해 프로세스 도출, 도출된 프로세스 간의 데이터 흐름 정의

• 객체지향 분석 (Object-Oriented Analysis)

  • 사용자 중심의 시나리오 분석을 통해 유스케이스 모델 (Usecase Model)로 구축
  • 유스케이스의 실체화 과정을 통해 추출된 요구사항을 분석

요구사항 명세

의미

• 분석된 요구사항을 명확하고 완전하게(C&C: Complete & Consistant충돌X) 기록하는 것

최종 결과물: 요구사항 명세서(SRS: Software Requirement Specification)

• 프로젝트 산출물 중 가장 중요한 문서
• 개발에 참여하는 모든 사람 (사용자, 분석가, 개발자 및 테스터) 에게 공동의 목표를 제시
• (명세서에는 WHAT을 넣을 것. HOW는 넣지 않는다. WHAT에 대한 디테일을 살릴것.)
  • 개발에 대한 구체적인 기술은 설계 단계에 넣음.
  • 요구사항은 한 번 만들고 바꾸기 힘들지만 HOW는 바뀔 가능성이 높음.

요구사항 명세서 작성 방법

• 모든 기능과 제약 조건을 명확하게 기술
• 고객과 개발자 사이에서 모두가 이해할 수 있도록 작성
• 요구사항이 명시적으로 검증 가능하도록 기술. (수치나 yes no 성공여부를 쉽게 파악 가능하도록 기술)
• HOW는 기술하지 않는다 - 특정한 구조나 알고리즘 기술 X
• 계층적으로 구성 - 참여자들이 시스템의 기능을 이해 분석할 수 있도록
• 고유의 식별자를 가지고 번호화 - 요구사항을 쉽게 참조할 수 있도록.

요구사항 검증

검증 내용

• 내부적 일치성과 완전성 (C&C)이 있는지
• 문서 표준을 따르는지
• 사용자나 고객의 목적을 완전하게 기술했는지
• 기술된 요구사항이 참여자의 기대에 일치하는지

요구사항 타당성 검증

• 요구사항의 구현 가능성 검증
• 정확성 및 완전성 검증 (C&C)
• 표준과의 일치성
• 충돌 검증
• 기술적 결함에 대한 검증 (C&C)

요구사항 타당성 검증 사항

검증 사항	설명
무결성(correctness) 및 완전성(completeness)	사용자의 요구를 에러 없이 완전하게 반영하고 있는가?
일관성(consistency)	요구사항이 서로간에 모순되지 않는가?
명확성(unambiguous)	요구분석의 내용이 모호함 없이 모든 참여자들에 의해 명확하게 이해될 수 있는가?
기능성(functional)	요구사항 명세서가 “어떻게” 보다 “무엇을”에 관점을 두고 기술되었는가?
검증 가능성(verifiable)	요구사항 명세서에 기술된 내용이 사용자의 요구를 만족하는가? 개발된 시스템이 요구사항 분석 내용과 일치하는지를 검증할 수 있는가?
추적 가능성(traceable)	시스템 요구사항과 시스템 설계 문서를 추적할 수 있는가?

요구사항 명세 구조 검증

• 검증 항목
  • 명세 요건들이 완전하고 정확한지
  • 요구 명세서가 내부적으로 일관성을 가지는지

요구사항 공통 어휘 검증

• 참여자들 간에 어휘에 대한 혼동이 없도록. 용어에 대한 모호성 제거

유스케이스 기반의 요구사항 분석

UML - Unified Modeling Language

시스템에 대한 뷰 제공 - 가시화, 명세화, 구축, 문서화

유스케이스 다이어그램

구성요소

• 액터 : 시스템과 상호작용 하는 사람 또는 다른 시스템 (사용자, 관리자, DB 등..)

  • 

• 유스케이스 : 기능

  • 

• 시스템 : 유스케이스를 포함함, 만들고자 하는 애플리케이션

  • 

• 관계 : 액터와 유스케이스 간의 관계

  • 연관 관계(association) : 유스케이스와 액터간의 상호작용
  • 의존 관계(dependency)
    • 포함 관계(include) : 글을 등록한다 -> 로그인한다 (전제)
    • 확장 관계(extend) : 글을 등록한다 <- 파일을 첨부한다 (추가 기능)
  • 일반화 관계(generalization) : 글을 검색한다 (추상적) <- 날짜로 검색한다 / 글쓴이로 검색한다 (구체적)

  

  

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

유스케이스 기술서

유스케이스 다이어그램을 보완하기 위한 산출물

---

reference

• 상명대학교 한종대교수님 소프트웨어공학 수업